Introdução

Este documento descreve pesquisar defeitos para a característica do registro automático e da renovação da função do proxy do Certificate Authority (CAPF). Esta característica é referida igualmente como o Online CA CAPF.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Certificados
• Segurança do gerente das comunicações unificadas de Cisco (CUCM)

Componentes Utilizados

A informação neste documento é baseada na versão 12.5 CUCM porque a característica em linha CAPF CA foi introduzida em CUCM 12.5.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Vista geral de componentes da característica

Registration authority (RA autoridade de registro)

O RA é uma autoridade em uma rede que verifique requisições de usuário para um certificado digital e diga o Certificate Authority (CA) para emitir o certificado. Os RA são parte de um Public Key Infrastructure (PKI).

Registro sobre o transporte seguro (EST)

O EST é um protocolo definido no request for comment (RFC) 7030 para o certificado de registro para os clientes que usam o gerenciamento certificado sobre mensagens CMS (CMC) sobre o Transport Layer Security (TLS) e o Hypertext Transfer Protocol (HTTP). O EST usa um modelo cliente/servidor onde o cliente EST envie pedidos do registro e o server EST envie respostas com os resultados.

libEST

o libEST é a biblioteca para a aplicação de Cisco do EST. o libEST permite que os Certificados X509 sejam fornecida em dispositivos de usuário finais e em dispositivos da infraestrutura de rede. Esta biblioteca é executada por CiscoEST e por CiscoRA.

Motor-x (NGINX)

NGINX é um servidor de Web e um proxy reverso similares a Apache. NGINX é usado para uma comunicação HTTP entre o CAPF e o CES assim como uma comunicação entre o CES e o serviço do registro da Web de CA. Quando o libEST se opera no modo de servidor um servidor de Web está exigido para segurar pedidos TCP em nome dos libEST.

Serviço do certificado de registro (CES)

O CES é o serviço em CUCM que atua como o RA entre o serviço CAPF e o CA CES é referido igualmente como CiscoRA, ou simplesmente em RA. O CES usa NGINX porque é servidor de Web porque o CES executa o libEST no modo de servidor a fim atuar como o RA.

Função do proxy do Certificate Authority (CAPF)

O CAPF é um serviço CUCM que os telefones interajam com ao executar o certificado de registro peçam. O CAPF interage com o CES em nome dos telefones. Neste modelo da característica o CAPF executa o libEST no modo de cliente para registrar os Certificados dos telefones com o CES.

Em resumo, é aqui como cada componente é executado:

1. O telefone envia um pedido do certificado ao CAPF
2. O CAPF executa CiscoEST (modo de cliente) para comunicar-se com o CES
3. O CES executa CiscoRA (modo de servidor) para processar e responder aos pedidos do cliente EST
4. CES/CiscoRA comunica-se com o serviço do registro da Web de CA através do HTTPS

Diagrama de fluxo de mensagem

Explicação do fluxo de mensagem

/.well-known/est/simpleenroll

O cliente EST usa esta URL para enviar um atendimento API que peça o certificado de registro do server EST. Uma vez que o server EST recebe o atendimento API começará o processo do certificado de registro que inclui uma comunicação HTTPS com o serviço do registro da Web de CA. Se o processo do registro é bem sucedido, e o server EST recebe o certificado novo, o CAPF continuará carregar o certificado e servir-lo de volta ao telefone IP.

/certsrv

/certsrv URL é usado pelo cliente EST para autenticar e começar uma sessão com CA.

A imagem abaixo é um exemplo de /certsrv URL de um navegador da Web. Este é os serviços certificados que aterram a página.

/certsrv/certrqxt.asp

/certsrv/certrqxt.asp URL é usado para iniciar o pedido para um certificado novo. O cliente EST usa /certsrv/certrqxt.asp para submeter o CSR, o nome do molde de certificado, e todos os atributos desejados.

A imagem abaixo é um exemplo de /certsrv/certrqxt.asp de um navegador da Web.

/certsrv/certfnsh.asp

/certsrv/certfnsh.asp URL é usado para submeter dados para o pedido do certificado; qual inclui o CSR, o nome do molde de certificado e todos os atributos desejados. Para ver a submissão use ferramentas do colaborador do navegador para abrir o console do navegador antes que os dados estejam submetidos através da página certrqxt.asp.

A imagem abaixo é um exemplo dos dados indicados no console do navegador.

A resposta da submissão de /certsrv/certfnsh.asp inclui o pedido ID do certificado emitido por CA. O pedido ID está considerado em um navegador da Web quando o código de origem da página é inspecionado.

Dica: Procure a fonte da página por “ReqID”

/certsrv/certnew.cer

Neste momento o cliente EST está ciente do pedido ID para o certificado novo. O cliente EST usa /certsrv/certnew.cer para passar o pedido ID e para arquivar a codificação como parâmetros para transferir o arquivo certificado com a extensão de .cer.

Isto é equivalente ao que acontece em seu navegador quando você clica o link do certificado da transferência.

Para ver o pedido URL e parâmetros, use o console do navegador.

Nota: O navegador especifica o escaninho para o parâmetro da codificação se a codificação DER é selecionada; contudo, a codificação de Base64 mostrará como b64.

Traços/logs relevantes para pesquisar defeitos

Estes logs ajudam com o isolamento da maioria de edições.

Logs CAPF

Os logs CAPF incluem interações com telefones e registro mínimo da atividade de CiscoEST.

Nota: Estes logs estão disponíveis para a coleção através do comando line interface(cli) ou da ferramenta do monitoramento em tempo real (RTMT). Devido a CSCvo28048 CAPF não pode mostrar entre a lista de serviços em RTMT.

Logs de CiscoRA

Os logs de CiscoRA são referidos frequentemente como os logs CES. Os logs de CiscoRA contêm a atividade da partida inicial CES e indicam os erros que podem elevarar quando a autenticação com CA ocorrer. Se a autenticação inicial com CA é bem sucedida, a atividade subsequente para registros do telefone não está entrada aqui. Consequentemente, os logs de CiscoRA servem como um bom ponto inicial para pesquisar defeitos edições.

Nota: Estes logs podem somente ser recolhidos através do CLI até à data desta criação dos documentos.

NGINX error.log

NGINX error.log é o log o mais útil para esta característica como ele registra toda a atividade durante começa acima assim como todas as interações HTTP entre NGINX e o lado de CA; qual inclui os códigos de erro retornados de CA assim como os aqueles gerados por CiscoRA após ter processado o pedido.

Nota: Na altura de criar este documento, não há nenhuma maneira de recolher estes logs mesmo do CLI. Estes logs podem somente ser transferidos usando uma conta remota do apoio (raiz).

Os logs do servidor de Web de CA

Os logs do servidor de Web de CA são importantes porque indicam toda a atividade de HTTP que inclui o pedido URL, os códigos da resposta, a duração de resposta e o tamanho de resposta. Você pode usar estes logs para correlacionar interações entre CiscoRA e CA.

Nota: O servidor de Web de CA entra o contexto deste documento é os logs MS IIS. Se a outra Web CA é apoiada no futuro, podem ter os arquivos de registro diferentes que servem como os logs do servidor de Web de CA

Localizações do arquivo de registro

Logs CAPF:

• Da raiz: <number >.txt de /var/log/active/cm/trace/capf/sdi/capf
• Do CLI: o arquivo obtém o activelog cm/trace/capf/sdi/capf*

Nota: Ajuste o nível de rastreamento CAPF a “detalhou” e reiniciam o serviço CAPF antes que testar esteja executado.

Cisco RA:

• Da raiz: <number >.txt de /var/log/active/cm/trace/capf/sdi/nginx
• Do CLI: o arquivo obtém o activelog cm/trace/capf/sdi/nginx*

Log de erros de Nginx:

• Da raiz: /usr/local/thirdparty/nginx/install/logs/error.log
• Não disponível do CLI

Log MS IIS:

• Abra o MMC
• Selecione o Internet Information Services (IIS) pressão-em
• Clique o nome do servidor
• Clique a website padrão
• Fazer duplo clique o registro para ver as opções de registro
• Selecione arquivos do View Log no menu de ações

Análise do log do exemplo

Serviços que começam acima normalmente

CES que começa acima como visto no log NGINX

Pouca informação é recolhida deste log. O certificate chain completo que é carregado em sua loja da confiança está visto aqui e uma é para o recipiente da Web quando o outro for para o EST:

nginx: [warn] CA Chain requested but this value has not yet been set
nginx: [warn] CA Cert response requested but this value has not yet been set
nginx: [warn] ossl_init_cert_store: Adding cert to store (/O=Cisco/CN=ACT2 SUDI CA)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/C=US/O=cisco/OU=tac/CN=CAPF-eb606ac0/ST=nc/L=rtp)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/C=US/O=cisco/OU=tac/CN=CAPF-eb606ac0/ST=nc/L=rtp)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/O=Cisco Systems/CN=Cisco Manufacturing CA)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/O=Cisco/CN=Cisco Manufacturing CA SHA2)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/O=Cisco Systems/CN=Cisco Root CA 2048)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/O=Cisco/CN=Cisco Root CA M2)
nginx: [warn] ossl_init_cert_store: Adding cert to store (/DC=com/DC=michamen/CN=lab-ca.michamen.com)
***EST [INFO][est_log_version:216]--> libest 2.2.0 (API level 4)
***EST [INFO][est_log_version:220]--> Compiled against CiscoSSL 1.0.2n.6.2.194-fips
***EST [INFO][est_log_version:221]--> Linking to CiscoSSL 1.0.2n.6.2.194-fips
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/O=Cisco/CN=ACT2 SUDI CA)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/C=US/O=cisco/OU=tac/CN=CAPF-eb606ac0/ST=nc/L=rtp)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/C=US/O=cisco/OU=tac/CN=CAPF-eb606ac0/ST=nc/L=rtp)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/O=Cisco Systems/CN=Cisco Manufacturing CA)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/O=Cisco/CN=Cisco Manufacturing CA SHA2)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/O=Cisco Systems/CN=Cisco Root CA 2048)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/O=Cisco/CN=Cisco Root CA M2)
***EST [INFO][ossl_init_cert_store_from_raw:182]--> Adding cert to store (/DC=com/DC=michamen/CN=lab-ca.michamen.com)
nginx: [warn] pop_enabled off in nginx.conf. Disabling EST Proof of Possession
***EST [INFO][set_ssl_option:1378]--> Using non-default ECDHE curve (nid=415)
***EST [INFO][set_ssl_option:1432]--> TLS SRP not enabled
EnrollmentService.sh : nginx server PID value =  31070

CES que começa acima como visto no NGINX error.log

O início de uma sessão usando a configuração e as credenciais do molde de certificado é observado no snippet aqui:

2019/03/05 12:31:21 [info] 31067#0: login_to_certsrv_ca: Secure connection to MS CertServ completed successfully using the following URL
https://lab-dc.michamen.com:443/certsrv

A recuperação da corrente de certificado de CA é observada no snippet aqui:

2019/03/05 12:31:21 [info] 31067#0: retrieve_cacerts: Secure connection to MS CertServ completed successfully using the following URL
https://lab-dc.michamen.com:443/certsrv/certnew.p7b?ReqID=CACert&Renewal=0&Enc=bin
[…]
2019/03/05 12:31:21 [info] 31067#0: ra_certsrv_ca_plugin_postconf: CA Cert chain retrieved from CA, will be passed to EST

Quando o pedido é bem sucedido o arquivo certnew.p7b está obtido. A mesma URL com as credenciais do molde pode ser usada para obter o arquivo certnew.p7b de um navegador da Web.

CES que começa acima como visto nos logs IIS

O mesmo CES que começa acima dos eventos vistos no NGINX error.log é observado igualmente nos logs IIS; contudo, os logs IIS incluem 2 mais pedidos HTTP GET porque o primeiro pedido será desafiado pelo servidor de Web com uma resposta 401; e uma vez autenticado pedido será reorientado usando uma resposta 301:

2019-03-05 17:31:15 14.48.31.152 GET /certsrv - 443 - 14.48.31.128 CiscoRA+1.0 - 401 1 2148074254 0
2019-03-05 17:31:15 14.48.31.152 GET /certsrv - 443 MICHAMEN\ciscora 14.48.31.128 CiscoRA+1.0 - 301 0 0 16
2019-03-05 17:31:15 14.48.31.152 GET /certsrv/certnew.p7b ReqID=CACert&Renewal=0&Enc=bin 443 MICHAMEN\ciscora 14.48.31.128 CiscoRA+1.0 - 200 0 0 2

CAPF que começa acima como visto nos logs CAPF

A maior parte o que ocorre nos logs CAPF para o CES que começa acima olha o mesmos como o que ocorre nos outros logs; mas você observará o serviço CAPF detectar o método e a configuração para CA em linha:

12:31:03.354 |   CServiceParameters::Init() Certificate Generation Method=OnlineCA:4
12:31:03.358 |   CServiceParameters::Init() TAM password already exists, no need to create.
12:31:03.358 |-->CServiceParameters::OnlineCAInit() 
12:31:03.388 |   CServiceParameters::OnlineCAInit() Online CA hostname is lab-dc.michamen.com
12:31:03.389 |   CServiceParameters::OnlineCAInit() Online CA Port : 443
12:31:03.390 |   CServiceParameters::OnlineCAInit() Online CA Template is  CiscoRA
12:31:03.546 |   CServiceParameters::OnlineCAInit() nginx.conf Updated and Credential.txt file is created
12:31:03.546 |   CServiceParameters::OnlineCAInit() Reading CAPF Service Parameters done
12:31:03.546 |<--CServiceParameters::OnlineCAInit() 
12:31:03.547 |   CServiceParameters::Init() OnlineCA Initialized
12:32:09.172 |   CServiceParameters::Init() Cisco RA Service Start Initiated. Please check NGINX logs for further details

A observação importante seguinte dos logs é quando o serviço CAPF a inicializa é cliente EST.

12:32:09.231 |   debug CA Type is Online CA, setting up EST Connection
12:32:09.231 |<--debug 
12:32:09.231 |-->debug 
12:32:09.231 |   debug Inside setUpESTClient
[…]
12:32:09.231 |-->debug 
12:32:09.231 |   debug cacert read success. cacert length : 1367
12:32:09.231 |<--debug 
12:32:09.232 |-->debug 
12:32:09.232 |   debug EST context ectx initialized
12:32:09.232 |<--debug 
12:32:09.661 |-->debug 
12:32:09.661 |   debug CA Credentials retrieved
12:32:09.661 |<--debug 
12:32:09.661 |-->debug 
12:32:09.661 |   debug est_client_set_auth() Successful!!
12:32:09.661 |<--debug 
12:32:09.661 |-->debug 
12:32:09.661 |   debug EST set server details success!!

O telefone LSC instala a operação

Logs CAPF

Recomenda-se a recolher todos os logs necessários e começar a análise com uma revisão dos logs CAPF. Isto permite que nós conheçam a referência de tempo para um telefone específico.

A inicial parte da sinalização olha o mesmos que com outros métodos CAPF a não ser que o cliente EST que é executado no serviço CAPF execute o registro com o CES para o fim do diálogo (depois que o CSR foi fornecido pelo telefone).

14:05:04.628 |-->debug 
14:05:04.628 |   debug 2:SEP74A02FC0A675:CA Mode is OnlineCA, Initiating Automatic Certificate Enrollment
14:05:04.628 |<--debug 
14:05:04.628 |-->debug 
14:05:04.628 |   debug 2:SEP74A02FC0A675:Calling enrollCertUsingEST() csr_file=/tmp/capf/csr/SEP74A02FC0A675.csr 
14:05:04.628 |<--debug 
14:05:04.628 |-->debug 
14:05:04.628 |   debug 2:SEP74A02FC0A675:Inside  X509_REQ *read_csr()
14:05:04.628 |<--debug 
14:05:04.628 |-->debug 
14:05:04.628 |   debug 2:SEP74A02FC0A675:Completed action in X509_REQ *read_csr()
14:05:04.628 |<--debug 

Uma vez que o CES recuperou o certificado assinado do telefone, o certificado está convertido ao formato DER antes que se esteja fornecido ao telefone.

14:05:05.236 |-->debug 
14:05:05.236 |   debug 2:SEP74A02FC0A675:Enrollment rv = 0 (EST_ERR_NONE) with pkcs7 length = 1963
14:05:05.236 |<--debug 
14:05:05.236 |-->debug 
14:05:05.236 |   debug 2:SEP74A02FC0A675:Signed Cert written to /tmp/capf/cert/ location...
14:05:05.236 |<--debug 
14:05:05.236 |-->debug 
14:05:05.236 |   debug 2:SEP74A02FC0A675:Inside write_binary_file()
14:05:05.236 |<--debug 
14:05:05.236 |-->debug 
14:05:05.236 |   debug 2:SEP74A02FC0A675:Completed action in write_binary_file()
14:05:05.236 |<--debug 
14:05:05.236 |-->debug 
14:05:05.236 |   debug 2:SEP74A02FC0A675:Converting PKCS7 file to PEM format and PEM to DER
14:05:05.236 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:Return value from enrollCertUsingEST() : 0
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:Online Cert Signing successful
14:05:05.289 |<--debug 
14:05:05.289 |-->findAndPost 
14:05:05.289 |   findAndPost Device found in the cache map SEP74A02FC0A675

O serviço CAPF toma sobre outra vez e carrega o CSR do lugar que se escreveu no snippet acima (/tmp/capf/cert/). O serviço CAPF fornece então o LSC assinado ao telefone. O CSR do telefone é suprimido ao mesmo tempo.

14:05:05.289 |<--findAndPost 
14:05:05.289 |-->debug 
14:05:05.289 |   debug addded 6 to readset
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug Recd event
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:CA CERT RES certificate ready .
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:CAPF CORE: Rcvd Event: CAPF_EV_CA_CERT_REP in State: CAPF_STATE_AWAIT_CA_CERT_RESP
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:CAPF got device certificate
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug loadFile('/tmp/capf/cert/SEP74A02FC0A675.der')
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug loadFile() successfully loaded file: '/tmp/capf/cert/SEP74A02FC0A675.der'
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug 2:SEP74A02FC0A675:Read certificate for device
14:05:05.289 |<--debug 
14:05:05.289 |-->debug 
14:05:05.289 |   debug LSC is verified. removing CSR at /tmp/capf/csr/SEP74A02FC0A675.csr
14:05:05.289 |<--debug 
14:05:05.290 |-->debug 
14:05:05.290 |   debug 2:SEP74A02FC0A675:Sending STORE_CERT_REQ msg

14:05:05.419 |<--Select(SEP74A02FC0A675) 
14:05:05.419 |-->SetOperationStatus(Success:CAPF_OP_SUCCESS):0 
14:05:05.419 |   SetOperationStatus(Success:CAPF_OP_SUCCESS):0 Operation status Value is '0'

14:05:05.419 |-->CAPFDevice::MapCapf_OpStatusToDBLTypeCertificateStatus(OPERATION_UPGRADE, Suc 
14:05:05.419 |   CAPFDevice::MapCapf_OpStatusToDBLTypeCertificateStatus(OPERATION_UPGRADE, Suc =>DbStatus=CERT_STATUS_UPGRADE_SUCCESS
14:05:05.419 |<--CAPFDevice::MapCapf_OpStatusToDBLTypeCertificateStatus(OPERATION_UPGRADE, Suc 
14:05:05.419 |   SetOperationStatus(Success:CAPF_OP_SUCCESS):0 Operation status is set to 1
14:05:05.419 |   SetOperationStatus(Success:CAPF_OP_SUCCESS):0 Operation status is set to Success:CAPF_OP_SUCCESS
14:05:05.419 |   SetOperationStatus(Success:CAPF_OP_SUCCESS):0 sql query - (UPDATE Device SET tkCertificateOperation=1, tkcertificatestatus='3' WHERE my_lower(name)=my_lower('SEP74A02FC0A675'))
14:05:05.503 |<--SetOperationStatus(Success:CAPF_OP_SUCCESS):0 
14:05:05.503 |-->debug 
14:05:05.503 |   debug 2:SEP74A02FC0A675:In capf_ui_set_ph_public_key()
14:05:05.503 |<--debug 
14:05:05.503 |-->debug 
14:05:05.503 |   debug 2:SEP74A02FC0A675:pubKey: 0‚
[…]
14:05:05.503 |<--debug 
14:05:05.503 |-->debug 
14:05:05.503 |   debug 2:SEP74A02FC0A675:pubKey length: 270
14:05:05.503 |<--debug 
14:05:05.503 |-->Select(SEP74A02FC0A675) 
14:05:05.511 |   Select(SEP74A02FC0A675) device exists 
14:05:05.511 |   Select(SEP74A02FC0A675) BEFORE DB query Authentication Mode=AUTH_BY_STR:1
14:05:05.511 |   Select(SEP74A02FC0A675) KeySize=KEY_SIZE_2048:3
14:05:05.511 |   Select(SEP74A02FC0A675) ECKeySize=INVALID:0
14:05:05.511 |   Select(SEP74A02FC0A675) KeyOrder=KEYORDER_RSA_ONLY:1
14:05:05.511 |   Select(SEP74A02FC0A675) Operation=OPERATION_NONE:1
14:05:05.511 |   Select(SEP74A02FC0A675) Operation Status =CERT_STATUS_UPGRADE_SUCCESS:3
14:05:05.511 |   Select(SEP74A02FC0A675) Authentication Mode=AUTH_BY_NULL_STR:2
14:05:05.511 |   Select(SEP74A02FC0A675) Operation Should Finish By=2019:01:20:12:00
[…]
14:05:05.971 |-->debug 
14:05:05.971 |   debug     MsgType               : CAPF_MSG_END_SESSION

Logs IIS

O snippet abaixo indica os eventos nos logs IIS para etapas de instalação LSC de um telefone como explicado acima.

2019-01-16 14:05:02 14.48.31.152 GET /certsrv - 443 - 14.48.31.125 CiscoRA+1.0 - 401 1 2148074254 0
2019-01-16 14:05:02 14.48.31.152 GET /certsrv - 443 MICHAMEN\ciscora 14.48.31.125 CiscoRA+1.0 - 301 0 0 0
2019-01-16 14:05:02 14.48.31.152 GET /certsrv/certrqxt.asp - 443 MICHAMEN\ciscora 14.48.31.125 CiscoRA+1.0 - 200 0 0 220
2019-01-16 14:05:02 14.48.31.152 GET /certsrv - 443 - 14.48.31.125 CiscoRA+1.0 - 401 1 2148074254 0
2019-01-16 14:05:02 14.48.31.152 GET /certsrv - 443 MICHAMEN\ciscora 14.48.31.125 CiscoRA+1.0 - 301 0 0 0
2019-01-16 14:05:02 14.48.31.152 POST /certsrv/certfnsh.asp - 443 MICHAMEN\ciscora 14.48.31.125 CiscoRA+1.0 https://lab-dc.michamen.com:443/certsrv/certrqxt.asp 200 0 0 15
2019-01-16 14:05:02 14.48.31.152 GET /certsrv/certnew.cer ReqID=10&ENC=b64 443 MICHAMEN\ciscora 14.48.31.125 CiscoRA+1.0 - 200 0 0 0

Problemas comuns

Sempre que há um erro no lado CES, espera-se ver a saída como o snippet abaixo nos logs CAPF. Seja certo verificar outros logs para continuar a reduzir abaixo da edição.

12:37:54.741 |-->debug 
12:37:54.741 |   debug 2:SEP001F6C81118B:CA Mode is OnlineCA, Initiating Automatic Certificate Enrollment
12:37:54.741 |<--debug 
12:37:54.741 |-->debug 
12:37:54.741 |   debug 2:SEP001F6C81118B:Calling enrollCertUsingEST() csr_file=/tmp/capf/csr/SEP001F6C81118B.csr 
12:37:54.741 |<--debug 
12:37:54.741 |-->debug 
12:37:54.742 |   debug 2:SEP001F6C81118B:Inside  X509_REQ *read_csr()
12:37:54.742 |<--debug 
12:37:54.742 |-->debug 
12:37:54.742 |   debug 2:SEP001F6C81118B:Completed action in X509_REQ *read_csr()
12:37:54.742 |<--debug 
12:38:04.779 |-->debug 
12:38:04.779 |   debug 2:SEP001F6C81118B:Enrollment rv = 35 (EST_ERR_SSL_READ) with pkcs7 length = 0
12:38:04.779 |<--debug 
12:38:04.779 |-->debug 
12:38:04.779 |   debug 2:SEP001F6C81118B:est_client_enroll_csr() Failed! Could not obtain new certificate. Aborting.
12:38:04.779 |<--debug 
12:38:04.779 |-->debug 
12:38:04.779 |   debug 2:SEP001F6C81118B:Return value from enrollCertUsingEST() : 35
12:38:04.779 |<--debug 
12:38:04.779 |-->debug 
12:38:04.779 |   debug 2:SEP001F6C81118B:Online Cert Signing Failed
12:38:04.779 |<--debug 
12:38:04.779 |-->debug 
12:38:04.779 |   debug addded 10 to readset
12:38:04.779 |<--debug

Certificado de CA faltante na corrente do expedidor do certificado de identidade IIS

Quando um certificado de raiz ou um certificado do intermediário, que esteja no certificate chain, não são confiados pelo CES o erro “incapaz de recuperar a corrente CERT de CA de CA” está imprimida nos logs do nginx.

nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 60 (SSL certificate problem: unable to get local issuer certificate)

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dc.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl
nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Servidor de Web que apresenta um certificado auto-assinado

O uso de um certificado auto-assinado no IIS não é apoiado e notará o trabalho mesmo se transferido arquivos pela rede como a CAPF-confiança no CUCM. O snippet abaixo é dos logs do nginx e indica o que é observado quando o IIS está usando um certificado auto-assinado.

nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 60 (SSL certificate problem: unable to get local issuer certificate)

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dc.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl
nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Má combinação com hostname e Common Name URL

O Common Name do certificado IIS (laboratório-DC) não combina o FQDN dentro da URL do serviço do registro da Web de CA. Para que a validação certificada suceda o FQDN dentro da URL deve combinar o Common Name no certificado usado por CA.

nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 51 (SSL: certificate subject name 'lab-dc' does not match target host name 'lab-dc.michamen.com')

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dc.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl

Edição da resolução de DNS

CiscoRA é incapaz de resolver o hostname de CA em linha configurado nos parâmetros de serviço.

nginx: [warn] CA Chain requested but this value has not yet been set
nginx: [warn] CA Cert response requested but this value has not yet been set
nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 6 (Could not resolve: lab-dcc.michamen.com (Domain name not found))

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dcc.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl
nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Edição com datas de validade de certificado

Quando o Network Time Protocol (NTP) que não trabalha corretamente emite com datas de validade de certificado ocorra. Esta verificação é executada pelo CES em cima começa acima e observa-se nos logs NGINX.

nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 60 (SSL certificate problem: certificate is not yet valid)

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dc-iis.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl
nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Misconfiguration do molde de certificado

Um erro tipográfico no nome dentro dos parâmetros de serviço causará falhas. Nenhum erro será entrado os logs CAPF nem NGINX assim que exige-se verificar o NGINX error.log.

***EST [INFO][est_enroll_auth:356]--> TLS: no peer certificate
2019/02/27 16:53:28 [warn] 3187#0: *2 ossl_init_cert_store: Adding cert to store (/DC=com/DC=michamen/CN=LAB-DC-RTP) while SSL EST handshaking, client: 14.48.31.128, server: 0.0.0.0:8084
2019/02/27 16:53:28 [info] 3187#0: *2 ra_certsrv_auth_curl_data_cb: Rcvd data len: 163
 while SSL EST handshaking, client: 14.48.31.128, server: 0.0.0.0:8084
2019/02/27 16:53:28 [info] 3187#0: *2 login_to_certsrv_ca: Secure connection to MS CertServ completed successfully using the following URL
https://lab-dc-iis.michamen.com:443/certsrv
 while SSL EST handshaking, client: 14.48.31.128, server: 0.0.0.0:8084
2019/02/27 16:53:28 [info] 3187#0: *2 ra_certsrv_auth_curl_data_cb: Rcvd data len: 11771
 while SSL EST handshaking, client: 14.48.31.128, server: 0.0.0.0:8084
2019/02/27 16:53:28 [info] 3187#0: *2 navigate_to_certsrv_page: Secure connection to MS CertServ completed successfully using the following URL
https://lab-dc-iis.michamen.com:443/certsrv/certrqxt.asp
 while SSL EST handshaking, client: 14.48.31.128, server: 0.0.0.0:8084
***EST [WARNING][est_enroll_auth:394]--> HTTP authentication failed. Auth type=1
***EST [WARNING][est_http_request:1435]--> Enrollment failed with rc=22 (EST_ERR_AUTH_FAIL)

***EST [INFO][mg_send_http_error:389]--> [Error 401: Unauthorized
The server was unable to authorize the request.
]
***EST [ERROR][est_mg_handler:1234]--> EST error response code: 22 (EST_ERR_AUTH_FAIL)

***EST [WARNING][handle_request:1267]--> Incoming request failed rv=22 (EST_ERR_AUTH_FAIL)
***EST [INFO][log_access:1298]--> 14.48.31.128 [27/Feb/2019:16:53:28 -0500] "POST /.well-known/est/simpleenroll HTTP/1.1" 401 0
***EST [INFO][log_header:1276]-->  -
***EST [INFO][log_header:1278]-->  "Cisco EST client 1.0"
***EST [WARNING][est_server_handle_request:1716]--> SSL_shutdown failed

Intervalo da autenticação CES

A mostra que abaixo cortada o tempo de cliente CES EST para fora após o temporizador padrão do 10 secunda durante o processo de autenticação inicial do certsrv.

nginx: [warn] login_to_certsrv_ca: Curl call for MS CA login failed with return code 28 (Operation timed out after 10000 milliseconds with 0 bytes received)

nginx: [warn] login_to_certsrv_ca: URL used: https://lab-dc.michamen.com:443/certsrv

nginx: [error] retrieve_cacerts: Unable to execute login to certsrv with curl
nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Nota: CSCvo58656 e CSCvf83629 ambos referem-se o intervalo da autenticação CES.

Intervalo do registro CES

Tempo de cliente CES EST para fora após uma autenticação bem sucedida mas ao esperar uma resposta a um pedido do registro.

nginx: [warn] retrieve_cacerts: Curl request failed with return code 28 (Operation timed out after 10001 milliseconds with 0 bytes received)


nginx: [warn] retrieve_cacerts: URL used: https://lab-dc.michamen.com:443/certsrv/certnew.p7b?ReqID=CACert&Renewal=0&Enc=bin


nginx: [warn] ra_certsrv_ca_plugin_postconf: Unable to retrieve CA Cert chain from CA

Caveats conhecidos

O serviço CSCvo28048 CAPF não alistado em RTMT recolhe o menu de arquivos anymore

CSCvo58656 CAPF CA em linha precisa a opção de configurar o timeout de conexão máximo entre o RA e o CA

Server CSCvf83629 EST que obtém EST_ERR_HTTP_WRITE durante o registro

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems