Crea nuovi certificati da certificati CA firmati

Introduzione

In questo documento viene descritto come rigenerare i certificati firmati da un'Autorità di certificazione (CA) in Cisco Unified Communications Manager (CUCM).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Strumento di monitoraggio in tempo reale (RTMT)
• Certificati CUCM

Componenti usati

• CUCM release 14.x e 15.x

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.

Impatto aziendale

In questa tabella viene visualizzato l'impatto aziendale di ogni rinnovo di certificato nell'operazione. Esaminate attentamente le informazioni. Rinnova i certificati richiesti dopo l'orario di ufficio o durante i periodi di attesa, in base al livello di rischio di ogni certificato.

Informazioni pre-controllo

Nota: Per la rigenerazione dei certificati autofirmati, consultare la guida alla rigenerazione dei certificati. Per la rigenerazione di certificati multi-SAN con firma CA, consultare la Guida alla rigenerazione di certificati multi-SAN

Ogni tipo di richiesta di firma del certificato (CSR) ha utilizzi chiave diversi e quelli sono richiesti nel certificato firmato. La Security Guide include una tabella con gli utilizzi chiave richiesti per ogni tipo di certificato.

Per modificare le impostazioni dell'oggetto (Località, Stato, Unità organizzativa e così via), eseguire questo comando:

• set web-security orgunit orname locality state [paese] [alternatehostname] 

Il certificato Tomcat viene rigenerato automaticamente dopo l'esecuzione del comando set web-security. Il nuovo certificato autofirmato non viene applicato a meno che il servizio Tomcat non venga riavviato. Per ulteriori informazioni sul comando, consultare le seguenti guide:

• Guida di riferimento per la riga di comando
• Link alle fasi della Cisco Community
• Video

Configurazione e rigenerazione di certificati

Per ogni tipo di certificato vengono elencati i passaggi per la rigenerazione dei certificati a nodo singolo in un cluster CUCM firmato da una CA. Non è necessario rigenerare tutti i certificati nel cluster se non sono scaduti. 

Certificato Tomcat 

Avviso: La scadenza del certificato Tomcat o un processo non valido nel rinnovo può causare: Errore di accesso SSO. I telefoni non sono in grado di accedere ai servizi HTTP ospitati nel nodo CUCM, ad esempio la directory aziendale. CUCM può presentare diversi problemi Web, ad esempio l'impossibilità di accedere alle pagine del servizio da altri nodi del cluster. Problemi di mobilità delle estensioni (EM) o problemi di mobilità delle estensioni tra cluster. Area trasversale Expressway inattiva (verifica TLS abilitata). Se Unified Contact Center Express (UCCX) è integrato, a causa del cambiamento della sicurezza rispetto a CCX, è necessario caricare il certificato CUCM Tomcat (autofirmato) o il certificato radice e intermedio Tomcat (per CA firmato) in UCCX per l'archivio di attendibilità dei gatti poiché influisce sugli accessi desktop Finesse.

Attenzione: verificare che SSO sia disabilitato nel cluster (Amministrazione CM > Sistema > SAML Single Sign-On). Se SSO è abilitato, deve essere disabilitato e quindi abilitato una volta completato il processo di rigenerazione dei certificati Tomcat.

In tutti i nodi (CallManager e IM&P) del cluster:

Passaggio 1. Passare a Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the Tomcat certificate (Amministrazione del sistema operativo unificato Cisco > Sicurezza > Gestione certificati > Trova e verifica la data di scadenza del certificato Tomcat).

Passaggio 2. Fare clic su Genera CSR > Scopo certificato: tomcat. Selezionare le impostazioni desiderate per il certificato, quindi fare clic su Genera. Attendere che venga visualizzato il messaggio di operazione riuscita e fare clic su Chiudi.

Passaggio 3. Scaricare il CSR. Fare clic su Download CSR, selezionare Scopo certificato: tomcat, quindi fare clic su Download.

Passaggio 4. Inviare il CSR all'autorità di certificazione.

Passaggio 5. L'autorità di certificazione restituisce due o più file per la catena di certificati firmata. Carica i certificati nell'ordine seguente:

• Certificato CA radice come tomcat-trust. Passare a Gestione certificati > Carica certificato > Scopo certificato: tomcat-trust. Impostare la descrizione del certificato e sfogliare il file del certificato radice.
• Certificato intermedio come tomcat-trust (facoltativo). Passare a Gestione certificati > Carica certificato > Scopo certificato: tomcat-trust. Impostare la descrizione del certificato ed esplorare il file del certificato intermedio.

Nota: Alcune CA non forniscono un certificato intermedio. Se è stato fornito solo il certificato radice, questo passaggio può essere omesso.

• Certificato firmato dalla CA come tomcat. Passare a Gestione certificati > Carica certificato > Scopo certificato: tomcat. Impostare la descrizione del certificato e sfogliare il file del certificato firmato dalla CA per il nodo CUCM corrente.

Nota: A questo punto, CUCM confronta il CSR e il certificato firmato dall'autorità di certificazione caricato. Se le informazioni corrispondono, il CSR scompare e il nuovo certificato firmato dall'autorità di certificazione viene caricato. Se viene visualizzato un messaggio di errore dopo il caricamento del certificato, vedere la sezione Carica messaggi di errore comuni del certificato.

Passaggio 6. Per applicare il nuovo certificato al server, è necessario riavviare il servizio Cisco Tomcat tramite CLI (iniziare con Publisher, quindi gli abbonati, uno alla volta). A tale scopo, utilizzare il comando utils service restart Cisco Tomcat.

Per verificare che il certificato Tomcat sia ora utilizzato da CUCM, passare alla pagina Web del nodo e selezionare Informazioni sito (icona a forma di lucchetto) nel browser. Fare clic sull'opzione del certificato e verificare la data del nuovo certificato.

Certificato IPSec 

Avviso: La scadenza del certificato IPSec o un processo non valido nel rinnovo può causare: Il Disaster Recovery System (DRS)/Disaster Recovery Framework (DRF) non funziona correttamente. I tunnel IPsec verso il gateway (GW) o altri cluster CUCM non funzionano.

Attenzione: Un'attività di backup o ripristino non deve essere attiva quando il certificato IPSec viene rigenerato.

Per tutti i nodi (CallManager e IM&P) del cluster:

Passaggio 1. Passare a Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the ipsec certificate (Amministrazione del sistema operativo unificato Cisco > Sicurezza > Gestione certificati > Trova e verifica la data di scadenza del certificato ipsec).

Passaggio 2. Fare clic su Genera CSR > Scopo certificato: ipsec. Selezionare le impostazioni desiderate per il certificato, quindi fare clic su Genera. Attendere che venga visualizzato il messaggio di operazione riuscita, quindi fare clic su Chiudi.

Passaggio 3. Scaricare il CSR. Fare clic su Download CSR. Selezionare Certificate Purpose ipsec e fare clic su Download.

Passaggio 4. Inviare il CSR all'autorità di certificazione.

Passaggio 5. L'autorità di certificazione restituisce due o più file per la catena di certificati firmata. Carica i certificati nell'ordine seguente:

• Certificato CA radice come attendibilità ipsec. Passare a Gestione certificati > Carica certificato > Scopo certificato: ipsec-trust. Impostare la descrizione del certificato e sfogliare il file del certificato radice.
• Certificato intermedio come trust IPSec (facoltativo). Passare a Gestione certificati > Carica certificato > Scopo certificato: tomcat-trust. Impostare la descrizione del certificato ed esplorare il file del certificato intermedio.

Nota: Alcune CA non forniscono un certificato intermedio. Se è stato fornito solo il certificato radice, questo passaggio può essere omesso.

• Certificato firmato da CA come ipsec. Passare a Gestione certificati > Carica certificato > Scopo certificato: ipsec. Impostare la descrizione del certificato e sfogliare il file del certificato firmato dalla CA per individuare il nodo CUCM corrente.

Nota: A questo punto, CUCM confronta il CSR e il certificato firmato dall'autorità di certificazione caricato. Se le informazioni corrispondono, il CSR scompare e il nuovo certificato firmato dall'autorità di certificazione viene caricato. Se viene visualizzato un messaggio di errore dopo il caricamento del certificato, vedere la sezione Caricamento dei messaggi di errore comuni dei certificati< /strong>.

Passaggio 6. Per applicare il nuovo certificato al server, è necessario riavviare i servizi richiesti (solo se il servizio è in esecuzione ed è attivo). Accedere a:

• Cisco Unified Serviceability > Strumenti > Control Center - Servizi di rete > Cisco DRF Master (Publisher)
• Cisco Unified Serviceability > Strumenti > Control Center - Servizi di rete > Cisco DRF Local (publisher e abbonati)

Certificato CAPF

Avviso: La scadenza del certificato CAPF o un processo non valido nel rinnovo può causare: Problemi di configurazione dell'autenticazione e della crittografia per gli endpoint (ad eccezione della modalità CAPF online e offline), Phone VPN, 802.1x e Phone Proxy. CTI, JTAPI e TAPI.

Nota: per determinare se il cluster è in modalità mista, passare a Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non sicuro; 1 == Mixed Mode) (Gestione di Cisco Unified CM > Sistema > Parametri aziendali > Modalità di sicurezza cluster (0 = non sicuro; 1 = modalità mista).

Nota: il servizio CAPF viene eseguito solo nel server di pubblicazione e questo è l'unico certificato utilizzato. Non è necessario ottenere i nodi del Sottoscrittore firmati da una CA perché non vengono utilizzati. Se il certificato è scaduto nei Sottoscrittori e si desidera evitare gli avvisi relativi ai certificati scaduti, è possibile rigenerare i certificati CAPF sottoscrittori come autofirmati. Per ulteriori informazioni, vedere Certificato CAPF autofirmato.

Nel server di pubblicazione:

Passaggio 1. Passare a Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the CAPF certificate (Amministrazione del sistema operativo unificato Cisco > Sicurezza > Gestione certificati > Trova e verifica la data di scadenza del certificato CAPF).

Passaggio 2. Fare clic su Genera CSR > Scopo certificato: CAPF. Selezionare le impostazioni desiderate per il certificato, quindi fare clic su Genera. Attendere che venga visualizzato il messaggio di operazione riuscita e fare clic su Chiudi.

Passaggio 3. Scaricare il CSR. Fare clic su Download CSR. Selezionare Certificate Purpose CAPF e fare clic su Download.

Passaggio 4. Inviare il CSR all'autorità di certificazione.

Passaggio 5. L'autorità di certificazione restituisce due o più file per la catena di certificati firmata. Carica i certificati nell'ordine seguente:

• Certificato CA radice come trust CAPF. Passare a Gestione certificati > Carica certificato > Scopo certificato: trust CAPF. Impostare la descrizione del certificato e sfogliare il file del certificato radice.
• Certificato intermedio come CAPF-trust (facoltativo). Passare a Gestione certificati > Carica certificato > Scopo certificato: trust CAPF. Impostare la descrizione del certificato ed esplorare il file del certificato intermedio.

Nota: Alcune CA non forniscono un certificato intermedio. Se è stato fornito solo il certificato radice, questo passaggio può essere omesso.

• Certificato firmato da CA come CAPF. Passare a Gestione certificati > Carica certificato > Scopo certificato: CAPF. Impostare la descrizione del certificato e sfogliare il file del certificato firmato dalla CA per individuare il nodo CUCM corrente.

Nota: A questo punto, CUCM confronta il CSR e il certificato firmato dall'autorità di certificazione caricato. Se le informazioni corrispondono, il CSR scompare e il nuovo certificato firmato dall'autorità di certificazione viene caricato. Se viene visualizzato un messaggio di errore dopo il caricamento del certificato, vedere la sezione Carica messaggi di errore comuni del certificato.

Passaggio 6. Se il cluster è in modalità mista, aggiornare l'elenco di certificati attendibili (CTL) prima di riavviare i servizi: Token o Token. Se il cluster è in modalità non protetta, ignorare questo passaggio e procedere con il riavvio del servizio.

Passaggio 7. Per applicare il nuovo certificato al server, è necessario riavviare i servizi richiesti (solo se il servizio è in esecuzione ed è attivo). Accedere a:

• Cisco Unified Serviceability > Strumenti > Control Center - Servizi di rete > Cisco Trust Verification Service (tutti i nodi in cui viene eseguito il servizio).
• Cisco Unified Serviceability > Strumenti > Control Center - Feature Services > Cisco TFTP (tutti i nodi in cui viene eseguito il servizio).
• Cisco Unified Serviceability > Strumenti > Control Center - Servizi funzionalità > Funzione proxy Cisco Certificate Authority (Publisher)

Passaggio 8. Reimpostare tutti i telefoni:

• Passare a Cisco Unified CM Administration > System > Enterprise Parameters > Reset (Amministrazione Cisco Unified CM > Sistema > Parametri aziendali > Reimposta). Viene visualizzata una finestra popup con l'istruzione, Si sta per ripristinare tutte le periferiche del sistema. L'operazione non può essere annullata. Continuare? selezionare OK, quindi fare clic su Reimposta.

Nota: Monitoraggio della registrazione del dispositivo tramite RTMT. Una volta che tutti i telefoni si sono registrati di nuovo si può procedere con il successivo tipo di certificato.

Certificato CallManager 

Avviso: La scadenza del certificato di Gestione chiamate o un processo non valido nel rinnovo può causare: Problemi relativi alla registrazione del telefono. I telefoni crittografati/autenticati non si registrano. Il protocollo TFTP (Trivial File Transfer Protocol) non è attendibile (i telefoni non accettano file di configurazione firmati e/o ITL). I trunk SIP (Secure Session Initiation Protocol) o le risorse multimediali (bridge di conferenze, MTP (Media Termination Point), Xcoder e così via) non si registrano o non funzionano. La richiesta AXL ha esito negativo.

Attenzione: Non rigenerare contemporaneamente i certificati CallManager e TVS. Ciò causa una mancata corrispondenza irreversibile con l'ITL installato sugli endpoint che richiede la rimozione dell'ITL da TUTTI gli endpoint nel cluster. Completare l'intero processo di CallManager e, una volta registrati nuovamente i telefoni, avviare il processo per la TV.

Nota: per determinare se il cluster è in modalità mista, passare a Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non sicuro; 1 == Mixed Mode) (Gestione di Cisco Unified CM > Sistema > Parametri aziendali > Modalità di sicurezza cluster (0 = non sicuro; 1 = modalità mista).

Per tutti i nodi CallManager del cluster:

Passaggio 1. Passare a Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the CallManager certificate (Amministrazione Cisco Unified SO > Sicurezza > Gestione certificati > Trova e verifica la data di scadenza del certificato di CallManager).

Passaggio 2. Fare clic su Genera CSR > Scopo certificato: CallManager. Selezionare le impostazioni desiderate per il certificato, quindi fare clic su Genera. Attendere che venga visualizzato il messaggio di operazione riuscita e fare clic su Chiudi.

Passaggio 3. Scaricare il CSR. Fare clic su Download CSR. Selezionare lo scopo del certificato: CallManager e fare clic su Download. 

Passaggio 4. Inviare il CSR all'autorità di certificazione.

Passaggio 5. L'autorità di certificazione restituisce due o più file per la catena di certificati firmata. Carica i certificati nell'ordine seguente:

• Certificato CA radice come CallManager-trust. Passare a Gestione certificati > Carica certificato > Scopo certificato: CallManager-trust. Impostare la descrizione del certificato e sfogliare il file del certificato radice.
• Certificato intermedio come CallManager-trust (facoltativo). Passare a Gestione certificati > Carica certificato > Scopo certificato: CallManager-trust. Impostare la descrizione del certificato ed esplorare il file del certificato intermedio.

Nota: Alcune CA non forniscono un certificato intermedio. Se è stato fornito solo il certificato radice, questo passaggio può essere omesso.

• Certificato firmato da CA come CallManager. Passare a Gestione certificati > Carica certificato > Scopo certificato: CallManager. Impostare la descrizione del certificato e sfogliare il file del certificato firmato dalla CA per individuare il nodo CUCM corrente.

Nota: A questo punto, CUCM confronta il CSR e il certificato firmato dall'autorità di certificazione caricato. Se le informazioni corrispondono, il CSR scompare e il nuovo certificato firmato dall'autorità di certificazione viene caricato. Se viene visualizzato un messaggio di errore dopo il caricamento del certificato, vedere la sezione Carica messaggi di errore comuni del certificato.

Passaggio 6. Se il cluster è in modalità mista, aggiornare l'elenco di certificati attendibili (CTL) prima di riavviare i servizi: Token o Token. Se il cluster è in modalità non protetta, ignorare questo passaggio e procedere con il riavvio dei servizi.

Passaggio 7. Per applicare il nuovo certificato al server, è necessario riavviare i servizi richiesti (solo se il servizio è in esecuzione ed è attivo). Accedere a:

• Cisco Unified Serviceability > Strumenti > Control Center - Servizi di rete > Cisco Trust Verification Service
• Cisco Unified Serviceability > Strumenti > Control Center - Feature Services > Cisco TFTP
• Cisco Unified Serviceability > Strumenti > Control Center - Feature Services > Cisco CallManager
• Cisco Unified Serviceability > Strumenti > Control Center - Feature Services > Cisco CTIM Manager 

Passaggio 8. Reimpostare tutti i telefoni:

• Passare a Cisco Unified CM Administration > System > Enterprise Parameters > Reset (Amministrazione Cisco Unified CM > Sistema > Parametri aziendali > Reimposta). Viene visualizzata una finestra popup con l'istruzione, Si sta per ripristinare tutte le periferiche del sistema. L'operazione non può essere annullata. Continuare? selezionare OK, quindi fare clic su Reset (Reimposta).

Nota: Monitoraggio della registrazione del dispositivo tramite RTMT. Una volta che tutti i telefoni si sono registrati di nuovo si può procedere con il successivo tipo di certificato.

Certificato TV  

Avviso: la scadenza di un certificato TVS o un processo errato provoca problemi di registrazione telefonica; i nuovi telefoni non possono registrarsi su Cisco UCM. I dispositivi registrati in CUCM non possono accedere ad applicazioni quali servizi EM, directory e MIDlet quando si utilizza HTTPS. Anche l'autenticazione dei TL e dei file di configurazione (cfg) ha esito negativo.

Attenzione: Non rigenerare contemporaneamente i certificati CallManager e TVS. Ciò causa una mancata corrispondenza irreversibile con l'ITL installato sugli endpoint che richiede la rimozione dell'ITL da TUTTI gli endpoint nel cluster. Completare l'intero processo per CallManager e, una volta registrati i telefoni, avviare il processo per il televisore.

Per tutti i nodi TVS del cluster:

Passaggio 1. Passare a Cisco Unified OS Administration > Security > Certificate Management > Find and verify the expiration date of the TVS certificate (Amministrazione del sistema operativo unificato Cisco > Sicurezza > Gestione certificati > Trova e verifica la data di scadenza del certificato TVS).

Passaggio 2. Fare clic su Genera CSR > Scopo certificato: TVS. Selezionare le impostazioni desiderate per il certificato, quindi fare clic su Genera. Attendere che venga visualizzato il messaggio di operazione riuscita e fare clic su Chiudi.

Passaggio 3. Scaricare il CSR. Fare clic su Download CSR. Selezionare Certificate Purpose TVS e fare clic su Download.

Passaggio 4. Inviare il CSR all'autorità di certificazione.

Passaggio 5. L'autorità di certificazione restituisce due o più file per la catena di certificati firmata. Carica i certificati nell'ordine seguente:

• Certificato CA radice come TVS-trust. Passare a Gestione certificati > Carica certificato > Scopo certificato: TVS-trust. Impostare la descrizione del certificato e sfogliare il file del certificato radice.
• Certificato intermedio come TVS-trust (facoltativo). Passare a Gestione certificati > Carica certificato > Scopo certificato: TVS-trust. Impostare la descrizione del certificato ed esplorare il file del certificato intermedio.

Nota: Alcune CA non forniscono un certificato intermedio. Se è stato fornito solo il certificato radice, questo passaggio può essere omesso.

• Certificato firmato dall'autorità di certificazione come TV. Passare a Gestione certificati > Carica certificato > Scopo certificato: TVS. Impostare la descrizione del certificato e sfogliare il file del certificato firmato dalla CA per individuare il nodo CUCM corrente.

Nota: A questo punto, CUCM confronta il CSR e il certificato firmato dall'autorità di certificazione caricato. Se le informazioni corrispondono, il CSR scompare e il nuovo certificato firmato dall'autorità di certificazione viene caricato. Se viene visualizzato un messaggio di errore dopo il caricamento del certificato, vedere la sezione Carica messaggi di errore comuni del certificato.

Passaggio 6. Per applicare il nuovo certificato al server, è necessario riavviare i servizi richiesti (solo se il servizio è in esecuzione ed è attivo). Accedere a:

• Cisco Unified Serviceability > Strumenti > Control Center - Feature Services > Cisco TFTP (tutti i nodi in cui viene eseguito il servizio).
• Cisco Unified Serviceability > Strumenti > Control Center - Servizi di rete > Cisco Trust Verification Service (tutti i nodi in cui viene eseguito il servizio).

Passaggio 7. Reimpostare tutti i telefoni:

• Passare a Cisco Unified CM Administration > System > Enterprise Parameters > Reset (Amministrazione Cisco Unified CM > Sistema > Parametri aziendali > Reimposta). Viene visualizzata una finestra popup con l'istruzione, Si sta per ripristinare tutte le periferiche del sistema. L'operazione non può essere annullata. Continuare? selezionare OK, quindi fare clic su Reimposta.

Nota: Monitoraggio della registrazione del dispositivo tramite RTMT. Una volta registrati tutti i telefoni, si può procedere con il successivo tipo di certificato.

Risoluzione dei problemi relativi ai messaggi di errore dei certificati caricati comuni

In questa sezione sono elencati alcuni dei messaggi di errore più comuni quando viene caricato un certificato firmato dalla CA.

Il certificato CA non è disponibile nell'archivio attendibile

Questo errore indica che il certificato radice o intermedio non è stato caricato in CUCM. Verificare che i due certificati siano stati caricati come attendibilità prima di caricare il certificato del servizio.

Il file /usr/local/platform/.security/tomcat/keys/tomcat.csr non esiste

Questo errore viene visualizzato quando non esiste un CSR per il certificato (tomcat, callmanager, ipsec, capf, tvs). Verificare che il CSR sia stato creato in precedenza e che il certificato sia stato creato in base a tale CSR. Punti importanti da tenere a mente:

• Può esistere un solo CSR per server e tipo di certificato. Ciò significa che se viene creata una nuova RSI, quella precedente viene sostituita.
• I certificati jolly non sono supportati da CUCM.
• Non è possibile sostituire un certificato di servizio attualmente in uso senza un nuovo CSR.
• Un altro possibile errore per lo stesso problema è "Impossibile caricare il file /usr/local/platform/upload/certs//tomcat.der". Dipende dalla versione CUCM.

Chiave pubblica CSR e chiave pubblica del certificato non corrispondenti

Questo errore viene visualizzato quando il certificato fornito dalla CA ha una chiave pubblica diversa da quella inviata nel file CSR. Le possibili cause sono:

• È stato caricato il certificato errato (forse da un altro nodo).
• Il certificato CA è stato generato con un altro CSR.
• Il CSR è stato rigenerato e ha sostituito il precedente CSR utilizzato per ottenere il certificato firmato.

Per verificare la corrispondenza tra CSR e chiave pubblica del certificato, sono disponibili diversi strumenti in linea, ad esempio SSL. 

Un altro possibile errore per lo stesso problema è "Impossibile caricare il file /usr/local/platform/upload/certs//tomcat.der". Dipende dalla versione CUCM.

Il nome alternativo del soggetto (SAN) CSR e la SAN del certificato non corrispondono

Le SAN tra il CSR e il certificato devono essere identiche. Ciò impedisce la certificazione per i domini non consentiti. Per verificare la mancata corrispondenza SAN, procedere come segue:

1. Decodificare il CSR e il certificato (base 64). Ci sono diversi decoder disponibili online, come il Decoder. 

2. Confrontare le voci SAN e verificare che corrispondano tutte. L'ordine non è importante, ma tutte le voci nel CSR devono essere identiche nel certificato. 

Ad esempio, al certificato firmato dall'autorità di certificazione vengono aggiunte due voci SAN aggiuntive, il Nome comune del certificato e un indirizzo IP aggiuntivo.

3. Una volta identificata la mancata corrispondenza della SAN, sono disponibili due opzioni per risolvere il problema:

1. Richiedere all'amministratore della CA di rilasciare un certificato con le stesse voci SAN inviate nel CSR.
2. Creare un CSR in CUCM che soddisfi i requisiti della CA.

Per modificare il CSR creato da CUCM:

1. Se la CA rimuove il dominio, è possibile creare un CSR in CUCM senza il dominio. Durante la creazione di CSR, rimuovere il dominio popolato per impostazione predefinita.
2. Se viene creato un certificato multisito, alcune CA non accettano -ms nel nome comune. I -ms possono essere rimossi dal CSR al momento della creazione. 

3. Per aggiungere un nome alternativo oltre a quelli completati automaticamente da CUCM:

1. Se si utilizza un certificato multisSAN, è possibile aggiungere più FQDN. (gli indirizzi IP non sono accettati).

b. Se il certificato è a nodo singolo, utilizzare il comando set web-security. Questo comando è valido anche per i certificati multi-SAN. (È possibile aggiungere qualsiasi tipo di dominio, ma sono consentiti anche indirizzi IP).

Per ulteriori informazioni, vedere la Guida di riferimento per la riga di comando.

Certificati di attendibilità con lo stesso CN non sostituiti

CUCM è stato progettato per archiviare un solo certificato con lo stesso nome comune e lo stesso tipo di certificato. Questo significa che se un certificato che è un tomcat-trust esiste già nel database e deve essere sostituito con uno recente con la stessa CN, CUCM rimuove il vecchio certificato e lo sostituisce con quello nuovo.

In alcuni casi, il certificato precedente non viene sostituito da CUCM:

1. Il certificato caricato è scaduto: CUCM non consente di caricare un certificato scaduto.
2. La data FROM del certificato precedente è più recente di quella del nuovo certificato. In CUCM viene mantenuto il certificato più recente e la data FROM precedente viene catalogata come precedente. Per questo scenario, è necessario eliminare il certificato indesiderato e quindi caricare quello nuovo.