La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritta la risoluzione dei problemi relativi alla funzionalità di registrazione e rinnovo automatici CAPF (Certificate Authority Proxy Function). Questa funzione è nota anche come CAPF Online CA.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Le informazioni fornite in questo documento si basano sulla versione 12.5 di CUCM, in quanto la funzione CAPF Online CA è stata introdotta in CUCM 12.5.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
RA è un'autorità di una rete che verifica le richieste degli utenti per un certificato digitale e comunica all'autorità di certificazione (CA) di rilasciare il certificato. Gli RA fanno parte di un'infrastruttura a chiave pubblica (PKI).
EST è un protocollo definito in RFC (Request for Comment) 7030 per la registrazione dei certificati per i client che utilizzano messaggi CMS (Certificate Management over CMS) su TLS (Transport Layer Security) e HTTP (HyperText Transfer Protocol). Il sistema EST utilizza un modello client/server in cui il client EST invia le richieste di registrazione e il server EST invia le risposte con i risultati.
libEST è la libreria per l'implementazione di EST da parte di Cisco. libEST consente il provisioning dei certificati X509 sui dispositivi dell'utente finale e sull'infrastruttura di rete. Questa libreria è implementata da CiscoEST e CiscoRA.
NGINX è un server Web e un proxy inverso simile ad Apache. NGINX viene utilizzato per la comunicazione HTTP tra CAPF e CES, nonché per la comunicazione tra CES e il servizio di registrazione Web CA. Quando libEST funziona in modalità server, è necessario un server Web per gestire le richieste TCP per conto di libEST.
CES è il servizio su CUCM che funge da RA tra il servizio CAPF e la CA. Il termine CES viene anche definito CiscoRA o semplicemente RA. Il CES utilizza NGINX come server Web perché implementa libEST in modalità server per fungere da server di registrazione.
CAPF è un servizio CUCM con cui i telefoni interagiscono quando si eseguono richieste di registrazione di certificati. Il CAPF interagisce con il CES per conto dei telefoni. In questo modello di funzionalità CAPF implementa libEST in modalità client per registrare i certificati dei telefoni tramite CES.
In sintesi, ecco come viene implementato ciascun componente:
Il client EST utilizza questo URL per inviare una chiamata API che richiede la registrazione del certificato al server EST. Una volta ricevuta la chiamata API, il server EST avvierà il processo di registrazione dei certificati che include la comunicazione HTTPS con il servizio di registrazione Web della CA. Se il processo di registrazione ha esito positivo e il server EST riceve il nuovo certificato, CAPF procederà a caricare il certificato e a restituirlo al telefono IP.
L'URL /certsrv viene utilizzato dal client EST per autenticare e avviare una sessione con la CA.
L'immagine seguente è un esempio di URL /certsrv da un browser Web. Pagina iniziale dedicata a Servizi certificati.
L'URL /certsrv/certrqxt.asp viene utilizzato per avviare la richiesta di un nuovo certificato. Il client EST utilizza /certsrv/certrqxt.asp per inviare il CSR, il nome del modello di certificato e qualsiasi attributo desiderato.
L'immagine seguente è un esempio di /certsrv/certrqxt.asp da un browser Web.
L'URL /certsrv/certfnsh.asp viene utilizzato per inviare i dati per la richiesta di certificato; che include il CSR, il nome del modello di certificato ed eventuali attributi desiderati. Per visualizzare l'inoltro, utilizzare gli Strumenti di sviluppo del browser per aprire la console del browser prima di inviare i dati tramite la pagina certrqxt.asp.
L'immagine seguente è un esempio dei dati visualizzati nella console del browser.
La risposta di invio da /certsrv/certfnsh.asp include l'ID richiesta del certificato rilasciato dalla CA. L'ID della richiesta viene visualizzato in un browser Web quando si controlla il codice sorgente della pagina.
Suggerimento: Cerca "ReqID" nell'origine della pagina
A questo punto il client EST è a conoscenza dell'ID richiesta per il nuovo certificato. Il client EST utilizza /certsrv/certnew.cer per passare l'ID richiesta e la codifica del file come parametri per scaricare il file di certificato con estensione .cer.
Equivale a quanto accade nel browser quando si fa clic sul collegamento Scarica certificato.
Per visualizzare l'URL e i parametri della richiesta, utilizzare la console del browser.
Nota: Il browser specifica bin per il parametro di codifica se è selezionata la codifica DER; tuttavia, la codifica Base64 verrà visualizzata come b64.
Questi registri consentono di isolare la maggior parte dei problemi.
I registri CAPF includono le interazioni con i telefoni e la registrazione minima delle attività di CiscoEST.
Nota: Questi log sono disponibili per la raccolta mediante l'interfaccia della riga di comando (CLI) o lo strumento di monitoraggio in tempo reale (RTMT). A causa di CSCvo28048 CAPF potrebbe non apparire tra l'elenco dei servizi in RTMT.
I registri CiscoRA vengono spesso definiti registri CES. I registri CiscoRA contengono l'attività di avvio iniziale del servizio Web di registrazione certificati e visualizzano gli errori che possono verificarsi durante l'autenticazione con l'autorità di certificazione.Se l'autenticazione iniziale con l'autorità di certificazione ha esito positivo, l'attività successiva per le registrazioni telefoniche non viene registrata in questa posizione. Pertanto, i registri CiscoRA rappresentano un buon punto di partenza per la risoluzione dei problemi.
Nota: questi log possono essere raccolti solo dalla CLI a partire dalla creazione di questo documento.
NGINX error.log è il log più utile per questa funzione, in quanto registra tutte le attività durante l'avvio e tutte le interazioni HTTP tra NGINX e il lato CA; che include i codici di errore restituiti dalla CA e quelli generati da CiscoRA dopo l'elaborazione della richiesta.
Nota: Al momento della creazione di questo documento, non è possibile raccogliere questi log neanche dalla CLI. Questi registri possono essere scaricati solo utilizzando un account di supporto remoto (root).
I registri del server Web CA sono importanti in quanto visualizzano qualsiasi attività HTTP, inclusi URL di richieste, codici di risposta, durata della risposta e dimensioni della risposta. È possibile utilizzare questi registri per correlare le interazioni tra CiscoRA e la CA.
Nota: I registri del server Web CA nel contesto di questo documento sono i registri di MS IIS. Se in futuro saranno supportate altre CA Web, è possibile che dispongano di file di log diversi che fungono da log del server Web della CA
Nota: Impostare il livello di traccia CAPF su "Dettagliato" e riavviare il servizio CAPF prima di eseguire il test.
Da questo registro vengono raccolte poche informazioni. La catena di certificati completa caricata nell'archivio di certificati attendibili è visualizzata qui e una è per il contenitore Web mentre l'altra è per 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
L'accesso con la configurazione e le credenziali del modello di certificato viene osservato nel frammento di codice:
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
Il recupero della catena di certificati CA viene osservato nel frammento di codice:
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 la richiesta ha esito positivo, viene ottenuto il file certnew.p7b. Lo stesso URL con le credenziali del modello può essere utilizzato per ottenere il file certnew.p7b da un browser Web.
Gli stessi eventi di avvio CES rilevati nel file error.log di NGINX sono osservati anche nei log di IIS; tuttavia, i log di IIS includono altre 2 richieste HTTP GET perché la prima richiesta verrà contestata dal server Web tramite una risposta 401; e una volta autenticata, una richiesta verrà reindirizzata utilizzando una risposta 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
La maggior parte di ciò che si verifica nei log CAPF per l'avvio del CES ha lo stesso aspetto di quello che si verifica negli altri log; ma il servizio CAPF rileva il metodo e la configurazione per la CA online:
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
La successiva osservazione importante dai log è quando il servizio CAPF inizializza il client 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!!
Si consiglia di raccogliere tutti i registri necessari e avviare l'analisi con una revisione dei registri CAPF. Questo ci permette di conoscere il riferimento orario per un telefono specifico.
La parte iniziale della segnalazione è simile a quella di altri metodi CAPF, con la differenza che il client EST in esecuzione nel servizio CAPF eseguirà l'iscrizione con CES verso la fine della finestra di dialogo (dopo che il CSR è stato fornito dal telefono).
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
Una volta che il CES ha recuperato il certificato firmato del telefono, il certificato viene convertito in formato DER prima di essere fornito al telefono.
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
Il servizio CAPF riprende il controllo e carica il CSR dal punto in cui è stato scritto nel frammento precedente (/tmp/capf/cert/). Il servizio CAPF fornisce quindi al telefono il LSC firmato. Allo stesso tempo il CSR del telefono viene eliminato.
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
Lo snippet di codice seguente visualizza gli eventi nei registri di IIS relativi alla procedura di installazione LSC di un telefono, come spiegato in precedenza.
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
Quando si verifica un errore sul lato CES, nei log CAPF dovrebbe essere visualizzato un output simile al frammento di codice riportato di seguito. Accertarsi di controllare altri registri per continuare a ridurre il problema.
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 un certificato radice o intermedio che si trova nella catena di certificati non è considerato attendibile dal servizio di certificazione esterna, nei registri Inginx viene visualizzato il messaggio di errore "Unable to retrieve CA Cert chain from CA" (Impossibile recuperare la catena di certificati CA da CA).
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
L'utilizzo di un certificato autofirmato in IIS non è supportato e funzionerà anche se caricato come CAPF-trust in CUCM. Lo snippet di codice seguente proviene dai log di Index e visualizza ciò che viene osservato quando IIS utilizza un certificato autofirmato.
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
Il nome comune (lab-dc) del certificato IIS non corrisponde all'FQDN all'interno dell'URL del servizio di registrazione Web della CA. Affinché la convalida del certificato riesca, il nome di dominio completo (FQDN) all'interno dell'URL deve corrispondere al nome comune nel certificato utilizzato dalla 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 non è in grado di risolvere il nome host della CA online configurata nei parametri del servizio.
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 il protocollo NTP (Network Time Protocol) non funziona correttamente si verificano problemi con le date di validità dei certificati. Questo controllo viene eseguito dal CES all'avvio e viene osservato nei registri 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
Un errore causato da un errore nel nome nei parametri del servizio. Poiché nei registri CAPF e NGINX non vengono registrati errori, è necessario controllare il file error.log di NGINX.
***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
L'istantanea seguente mostra il timeout del client CES EST dopo il timer predefinito di 10 secondi durante il processo di autenticazione certsrv iniziale.
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 riguardano entrambi il timeout di autenticazione CES.
Timeout del client CES EST dopo un'autenticazione riuscita in attesa di una risposta a una richiesta di registrazione.
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
Servizio CSCvo28048 CAPF non più elencato nel menu Raccogli file RTMT
CSCvo58656 CAPF Online CA richiede l'opzione per configurare il timeout massimo della connessione tra RA e CA
CSCvf83629 EST Server che ottiene EST_ERR_HTTP_WRITE durante la registrazione
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
10-May-2019 |
Versione iniziale |