A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
A Cisco recomenda que você tenha conhecimento destes tópicos:
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.
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).
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.
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.
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.
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.
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 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 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 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 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”
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.
Estes logs ajudam com o isolamento da maioria de edições.
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.
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 é 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 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
Nota: Ajuste o nível de rastreamento CAPF a “detalhou” e reiniciam o serviço CAPF antes que testar esteja executado.
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
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.
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
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!!
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
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
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
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
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
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
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
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
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
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.
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
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