Segurança e VPN : Public Key Infrastructure (PKI)

Pesquise defeitos 404 erros recebidos do Cisco IOS CA para distribuições em larga escala

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve uma situação de falha com um desenvolvimento do Public Key Infrastructure (PKI) do servidor certificado do ® do Cisco IOS da larga escala e sua mitigação potencial corretamente ajustando as configurações do temporizador do evento PKI.

Contribuído por Atri Basi, por Raja Periyasamy, e por Wen Zhang, engenheiros de TAC da Cisco.

Problema

Sintomas do usuário

Este problema pode ser considerado em um ambiente em grande escala PKI onde um registration authority (RA autoridade de registro) do Cisco IOS seja configurado para prestar serviços de manutenção a centenas e às vezes a milhares de dispositivos do cliente PKI. Quando esta falha particular ocorre, o certificado de registro dos clientes PKI pôde falhar intermitentemente ou consistentemente.

Nos clientes PKI é provável que estes mensagens de registro puderam ser considerados:

*Dec 30 15:37:46.996: CRYPTO_PKI: Socket timeout
*Dec 30 15:40:47.929: %PKI-3-SOCKETSEND: Failed to send out message to CA server.

Depois que você permite este o PKI debuga:

debug crypto pki message
debug crypto pki validation

vê-se que os pedidos do cliente o certificado do derrubamento do server do Certificate Authority (CA), mas recebem pelo contrário “um Mensagem de Erro não encontrado HTTP 404” do server de CA.

Dec 31 03:14:19.184: PKI: Shadow state for GETVPN now
GET_NEW_CA_CERT_WAIT_FOR_RETRY
Dec 31 03:14:19.184: PKI:get_cert GETVPN 0x10 (expired=0):
Dec 31 03:14:19.184: PKI: Shadow state for GETVPN now GET_NEW_CA_CERT
Dec 31 03:14:39.187: PKI: Shadow timer went off for GETVPN
Dec 31 03:14:39.187: CRYPTO_PKI: Sending Next CA Certificate Request:
GET /cgi-bin/pkiclient.exe?operation=GetNextCACert&message=GETVPN HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.105.3


Dec 31 03:14:39.187: CRYPTO_PKI: locked trustpoint GETVPN, refcount is 1
Dec 31 03:14:39.187: CRYPTO_PKI: http connection opened
Dec 31 03:14:39.187: CRYPTO_PKI: Sending HTTP message

Dec 31 03:14:39.191: CRYPTO_PKI: Reply HTTP header:
HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.105.3


Dec 31 03:14:39.203: CRYPTO_PKI: unlocked trustpoint GETVPN, refcount is 0
Dec 31 03:14:39.203: CRYPTO_PKI: locked trustpoint GETVPN, refcount is 1
Dec 31 03:14:39.223: CRYPTO_PKI: unlocked trustpoint GETVPN, refcount is 0
Dec 31 03:14:39.223: CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 404 Not Found
Date: Tue, 30 Dec 2014 16:14:28 GMT
Server: cisco-IOS
Accept-Ranges: none

Content-Type indicates we did not receive a certificate.

Dec 31 03:14:39.227: %Error in connection to Certificate Authority:
status = FAIL

Nota: Esta edição não é RA específico e pode igualmente acontecer quando um RA não é usado (CA somente).

Pesquise defeitos e identificação do problema

Um dos sintomas chaves observados na falha é que há muitos pedidos PKI no RA que vêm dos clientes PKI. Isto pode ser visto com saídas do Netflow ou da captura de pacote de informação. A quantidade de pedidos PKI pode oprimir o server de modo que não possa responder rapidamente bastante. Uma maneira de verificar esta circunstância é ao telnet ao server de CA na porta de HTTP que está escutando. Quando o serviço escuta na porta e responde, você deve ver a conexão aberta. No estado falho, a tentativa do telnet cronometra para fora que indica que o TCP termina nem sequer o aperto de mão da 3-maneira.

A fim compreender melhor porque o TCP falha, incorpore o comando do <tcp_peer_address> do endereço das transações debugar IP tcp no server a fim ganhar introspecções na manipulação do server dos fluxos de TCP a um endereço de origem particular TCP (é importante especificar o filtro de endereço quando você debuga um ambiente em grande escala). No estado falho, estes debugam são observados:

TCP0: bad seg from x.x.x.x -- connection queue limit reached:
port 80 seq 1276472961 ack 0 rcvnxt 0 rcvwnd 4128 len 0
TCP0: bad seg from x.x.x.x -- connection queue limit reached:
port 80 seq 1276472961 ack 0 rcvnxt 0 rcvwnd 4128 len 0
TCP0: bad seg from x.x.x.x -- connection queue limit reached:
port 80 seq 1276472961 ack 0 rcvnxt 0 rcvwnd 4128 len 0

Dica: Nas versões 15.1 e 15.2 o comando debug ip tcp transactions não tem uma opção de endereço nela. No lugar deste comando, incorpore os <tcp_peer_address do endereço do pacote debugar IP tcp a fim mostrar igualmente se o limite da fila de conexão é alcançado.

Uma captura de pacote de informação para os pedidos PKI pode igualmente ajudar a revelar a informação adicional sobre o que estes pedidos PKI são. Da captura de pacote de informação, você pode ver um número grande de pedidos similares a:

Para alguns destes pedidos que o server pode realmente responder a, você igualmente vê um "404 não encontrar a” resposta:

Causa de raiz

Há alguns fatores que contribuem a este problema particular. Primeiramente, o GetNextCACert mostra que estes pedidos PKI são pedidos do derrubamento dos clientes pedir para um derrubamento/certificado de CA da sombra. Para mais detalhes na operação do derrubamento de CA, veja IO PKI Auto-registrar-se, Auto-derrubamento, e temporizadores. A” resposta "404 não encontrada indica que o server RA/CA não pôde ter o certificado da sombra na altura do pedido. Isto pode ser verificado com o comando certificate cripto do pki da mostra output nos server de CA e RA. O problema é devido a esta configuração do temporizador do certificado encontrada no servidor PKI e no cliente:

Server RA/CA

CA-Server#show running | section pki server
crypto pki server ca-server
<snip>
lifetime certificate 600
lifetime ca-certificate 1825

auto-rollover
CA-Server#show crypto pki server | include Rollover
Auto-Rollover configured, overlap period 30 days
CA-Server#

Clientes PKI

crypto pki trustpoint test enroll url http://enrollment_url.test.com:80
enrollment mode ra subject-name OU = TEST OU, OU = cisco auto-enroll 70

O problema é que o momento da validez do certificado de CA está configurado de ser os anos 5 (1825 dias), mas o certificado do derrubamento/sombra não obtém criado no server de CA até 30 dias antes da expiração atual do certificado. Os certificados de roteador têm uma estadia de uma validez de 600 dias, e baseado na configuração auto-registrar-se, o roteador poderia pedir um certificado do derrubamento/sombra após 70% da vida de 600 dias. Isto podia realizar-se a partir de 180 dias antes do tempo de expiração atual do certificado de CA. Para um cálculo detalhado destas épocas e a explicação dos eventos PKI, refira outra vez IO que O PKI Auto-se registra, Auto-derrubamento, e temporizadores. Isto explica porque os clientes continuam a pedir o derrubamento/sombra de CA, e continua a receber o” erro "404 não encontrado desde que não são criados no server ainda. Esta circunstância persiste até que o certificado do derrubamento/sombra de CA esteja gerado. 

Entretanto, devido à grande quantidade de pedidos que entram o server RA, o server do Cisco IOS RA pode exceder este ponto inicial da conexão de HTTP e começá-lo deixar cair pedidos de conexão de HTTP entrantes:

  • O limite simultâneo das conexões de servidor do máximo HTTP. Isto pode ser mudado a um máximo de 16 conexões simultâneas com o comando das MAX-conexões 16 do HTTP de IP.
  • O limite interno da taxa de conexão do Server do HTTP de 80 conexões pelo minuto. Quando este ponto inicial é alcançado, o Server do HTTP do theCiscoIOS estrangula para trás e para de escutar pedidos do HTTP novos por 15 segundos. Atualmente, este ponto inicial do limite de taxa não é usuário configurável. Em consequência, o theTCP da “erro alcançado limite fila de conexão” é considerado com transação do theTCP debuga. 

    Nota: Atualmente o ponto inicial acima não pode ser monitorado com um comando cisco ios. Uma requisição de aprimoramento foi aberta melhorar isto, considera a identificação de bug Cisco CSCuj83430.

Solução

A solução a este problema é corrigir as configurações do temporizador do evento PKI no server de CA tais que um certificado do derrubamento/sombra está gerado antes de todo o pedido do derrubamento do cliente PKI. Isto pode ser feito com estas etapas:

  1. Inscreva o comando shutdown sob a ordem cripto do servidor PKI command.in desabilitar o server de CA.
  2. Aumente o tempo da sobreposição do derrubamento baseado na configuração da vida e do reenrollment do certificado:

    CA-Server(config)#crypto pki server ca-server
    CA-Server(cs-server)#auto-rollover ?
    <0-1825> Overlap time between CA certificates during rollover, in days
    <cr>
    CA-Server(cs-server)#auto-rollover 365
  3. Reenable o server de CA.
  4. Se há um anRA, theRA do derrubamento para recuperar manualmente o certificado do derrubamento/sombra.

    Dica: A fim forçar manualmente CA ao derrubamento sem permitir o auto-derrubamento, incorpore o comando cripto do derrubamento do <server-name> do server do pki.

Também, como discutido previamente, recomenda-se aumentar o limite máximo da conexão simultânea HTTP a 16 para que o server segure uma taxa alta da conexão recebida.



Document ID: 118734