Pesquisando defeitos o Online CA CAPF
Índice
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:
- O telefone envia um pedido do certificado ao CAPF
- O CAPF executa CiscoEST (modo de cliente) para comunicar-se com o CES
- O CES executa CiscoRA (modo de servidor) para processar e responder aos pedidos do cliente EST
- 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.
/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.
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.
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.
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.
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.
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*
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
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
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)