Generazione e download dei certificati CSR sui WLC di Catalyst 9800

Introduzione

Questo documento descrive il processo generale per generare, scaricare e installare certificati su Catalyst 9800

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Come configurare il WLC 9800, il punto di accesso (AP) per le operazioni di base
• Come utilizzare l'applicazione OpenSSL
• Infrastruttura a chiave pubblica (PKI) e certificati digitali

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• 9800-CL, Cisco IOS® XE versione 17.9.4
• Applicazione OpenSSL (versione 3.1.3)

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.

Configurazione

Nella versione 16.10.X, 9800 non supporta un certificato diverso per l'autenticazione e l'amministrazione Web. Il certificato predefinito viene sempre utilizzato per l'accesso al portale Web.

Nella versione 16.11.X è possibile configurare un certificato dedicato per l'autenticazione Web, definire il trust point all'interno della mappa dei parametri globali.

Ci sono due opzioni per ottenere un certificato per un WLC 9800.

1. Generare una richiesta di firma del certificato (CSR) con OpenSSL o qualsiasi altra applicazione SSL. Generare (utilizzando OpenSSL) o ottenere un certificato PKCS12 firmato dall'autorità di certificazione (CA) e caricarlo direttamente sul WLC 9800. La chiave privata viene fornita insieme al certificato.
2. Utilizzare il WLC 9800 per generare un CSR, apporre la firma di un'autorità di certificazione e quindi caricare manualmente ogni certificato nella catena sul WLC 9800.
   

Usa quello che meglio si adatta alle tue esigenze.

Opzione 1 - Caricamento di un certificato firmato PKCS12 preesistente sul WLC

Passaggio 1: creare una richiesta di firma del certificato

Se il certificato non è ancora disponibile, è necessario generare una richiesta di firma del certificato (CSR) da inviare alla CA.

Creare un file di testo denominato "openssl.conf" dalla directory corrente (su un laptop in cui è installato OpenSSL), copiare e incollare queste righe per includere il campo Nomi alternativi soggetto (SAN) nei CSR appena creati.

[ req ]
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no
[ req_distinguished_name ]
countryName                 = <Country Name (2 letter code)>
stateOrProvinceName         = <State or Province Name (full name)>
localityName               = <Locality Name (eg, city)>
organizationName           = <Organization Name (eg, company)>
commonName                 = <Common Name (e.g. server FQDN or YOUR name)>
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = testdomain.com
DNS.2   = example.com
DNS.3   = webadmin.com
IP.1    = <WLC_IP_ADDRESS> (note : this is optionnal, but can be added in case you want to access your WLC using the IP address instead of FQDN)

Sostituire i nomi DNS.X con la rete SAN (nome alternativo soggetto). Sostituire i campi principali con i dettagli del certificato necessari. Assicurarsi di ripetere il Nome comune nei campi SAN (DNS.x). Google Chrome richiede che il nome presente nell'URL sia nei campi SAN per poter considerare attendibile il certificato.

Nel caso dell'amministratore Web, è inoltre necessario popolare i campi SAN con variazioni dell'URL (ad esempio solo nome host o nome di dominio completo (FQDN) completo) in modo che il certificato corrisponda a prescindere da quello che l'amministratore digita nell'URL nella barra degli indirizzi del browser.

Generare il CSR da OpenSSL con questo comando:

openssl req -out myCSR.csr -newkey rsa:4096 -nodes -keyout private.key -config openssl.conf

Il CSR viene generato come myCSR.csr e la relativa chiave come private.key nella directory da cui viene eseguito OpenSSL, a meno che non venga fornito il percorso completo del comando.

Passaggio 2: Verificare il contenuto del CSR

È possibile copiare e incollare il contenuto del CSR in uno strumento online (digitare "CSR decoder" su Google per esempio) per verificarne il contenuto. Verificare che la SAN (Subject Alternative Name) sia inclusa nel CSR come richiesto da alcuni browser. 

È inoltre possibile verificare il contenuto del CSR con OpenSSL utilizzando questo comando:

openssl req -noout -text -in myCSR.csr 

Passaggio 3: Inviare il CSR alla CA

È quindi possibile fornire questo CSR alla CA per firmarlo e ricevere nuovamente un certificato. Verificare che la catena completa venga scaricata dalla CA e che il certificato sia in formato Base64 in caso sia necessario modificarlo ulteriormente. In genere si ricevono più file dalla CA: il certificato del dispositivo firmato, il certificato della CA radice e uno o più certificati della CA intermedia.

Passaggio 4: Creare e/o importare il file pkcs12 sul WLC

Se il CSR è stato generato nel computer utilizzando OpenSSL, è possibile che la CA fornisca solo il certificato firmato insieme al proprio certificato ed eventuali certificati intermedi. In tal caso, è necessario generare il file PKCS12 personalmente utilizzando OpenSSL. Se la CA ha accesso anche alla chiave privata, può fornire direttamente il file PKCS12 (file PFX) e in tal caso, è sufficiente importarlo sul controller. A tale scopo, consultare la sezione "Importazione del file PKCS12". 

Creare il file PKCS12

È possibile che il file della chiave privata e il certificato in formato PEM o CRT vengano combinati in un formato PKCS12 (.pfx) per caricarli nel WLC 9800. È inoltre possibile disporre di uno o più certificati CA da includere anche in questo file PFX prima di eseguire l'importazione nel WLC 9800. 

La prima cosa da fare è combinare tutte le CA intermedie e il file CA radice in un unico file. Copiare e incollare il contenuto (salvare il file in formato .pem):

----- BEGIN Certificate --------
<intermediate CA cert>
------END Certificate --------
-----BEGIN Certificate -----
<root CA cert>
-----END Certificate--------

È quindi possibile creare il file con estensione pfx utilizzando il comando seguente: 

For versions older than 17.12.1 : 
openssl pkcs12 -export -macalg sha1 -legacy -descert -out chaincert.pfx -inkey  -in  -certfile 
       
       
 
       
 
      For version 17.12.1 or above : 
openssl pkcs12 -export -out chaincert.pfx -inkey  -in  -certfile 
      

Verificare il file PKCS12 creato

È possibile controllare il contenuto del file PKCS12 utilizzando questo comando:

openssl pkcs12 -info -in 
    
    

In questo output vengono visualizzati la catena di certificati completa e la chiave privata. Il file è protetto con la password configurata in precedenza. 

Importare il file PKCS12

A questo punto, è possibile importare il file .pfx sul WLC 9800, utilizzando la GUI o la CLI. 

Uso della GUI:

Aprire la GUI del WLC 9800 e selezionare Configurazione > Sicurezza > Gestione PKI, fare clic sulla scheda Aggiungi certificato. Espandere il menu Importa certificato PKCS12. Se il file con estensione pfx è memorizzato nel computer, scegliere l'opzione Desktop (HTTPS) nell'elenco a discesa Tipo di trasporto, che consente il caricamento HTTP tramite il browser. Password certificato si riferisce alla password utilizzata al momento della generazione del certificato PKCS12.

Verificare che le informazioni siano corrette e fare clic su Importa. Quindi, nella scheda Generazione coppia di chiavi verrà visualizzata la nuova coppia di chiavi del certificato per il nuovo trust point installato. Una volta completata l'importazione, il WLC 9800 crea anche un trust point aggiuntivo per le CA multilivello.

Uso della CLI:

9800# configure terminal
9800(config)#crypto pki import 
    
    
      pkcs12 [tftp:// 
     
       / 
      
        | ftp:// 
       
         / 
        
          | 
         http:// 
          
            / 
            
           | bootflash: 
         
           ] password 
           
          
         
        
       
      
    

Nota: è importante che il nome del file del certificato e il nome del trust point corrispondano esattamente a quelli del WLC 9800 per creare ulteriori trust point per CA multilivello.

Opzione 2 - Definizione di una chiave e di una richiesta di firma del certificato (CSR) sul WLC 9800

Passaggio 1: generare una coppia di chiavi RSA per uso generale

Passare a Configurazione > Sicurezza > Gestione PKI, scegliere la scheda Generazione coppia di chiavi e fare clic su + Aggiungi. Immettere i dettagli, verificare che la casella di controllo Chiave esportabile sia selezionata e quindi fare clic su Genera.

Configurazione CLI:

9800(config)#crypto key generate rsa general-keys label 9800-keys exportable
The name for the keys will be: 9800-keys
Choose the size of the key modulus in the range of 512 to 4096 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [1024]: 4096
% Generating 4096 bit RSA keys, keys will be exportable...
[OK] (elapsed time was 9 seconds)

Passaggio 2: generare un CSR sul WLC 9800

Passare alla scheda Aggiungi certificato ed espandere Genera richiesta di firma del certificato, immettere i dettagli e scegliere la coppia di chiavi creata in precedenza dall'elenco a discesa. È importante che Domain Name corrisponda all'URL definito per l'accesso client sul WLC 9800 (pagina di amministrazione Web, pagina di autenticazione Web e così via), Certificate Name (Nome certificato) è il nome del trust in modo che sia possibile assegnare un nome in base al relativo utilizzo.

Nota: i WLC 9800 supportano i certificati con parametri jolly all'interno del nome comune.

Verificare che le informazioni siano corrette, quindi fare clic su Genera. Il CSR verrà visualizzato in una casella di testo accanto al modulo originale

Copia consente di salvare una copia negli Appunti in modo da poterla incollare in un editor di testo e salvare il file CSR.  
Save to device crea una copia del CSR e la memorizza in bootflash:/csr. Per visualizzarlo, eseguire i comandi seguenti:

9800#dir bootflash:/csr
Directory of bootflash:/csr/

1046531 -rw- 1844 Sep 28 2021 18:33:49 +00:00 9800-CSR1632856570.csr

26458804224 bytes total (21492699136 bytes free)
9800#more bootflash:/csr/9800-CSR1632856570.csr
-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

Configurazione CLI:

9800(config)#crypto pki trustpoint 9800-CSR
9800(ca-trustpoint)#enrollment terminal pem
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#subject-name C=BE, ST=Brussels, L=Brussels, O=Cisco Systems, OU=Wireless TAC, CN=mywlc.local-domain
9800(ca-trustpoint)#rsakeypair 9800-keys
9800(ca-trustpoint)#subject-alt-name example.com,guestportal.com,webadmin.com
9800(ca-trustpoint)#exit

(config)#crypto pki enroll 9800-CSR
% Start certificate enrollment ..

% The subject name in the certificate will include: C=BE, ST=Brussels, L=Brussels, O=Cisco Systems, OU=Wireless TAC, CN=mywlc.local-domain
% The subject name in the certificate will include: mywlc
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:

-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

---End - This line not part of the certificate request---

Redisplay enrollment request? [yes/no]: no

Parametri disponibili per la configurazione del nome soggetto:

C: Paese, deve essere composto solo da due lettere maiuscole.

ST: Qualche stato, fa riferimento al nome dello stato o della provincia.

L: Nome località, si riferisce alla città.

O: Nome organizzazione, si riferisce alla società.

OU: nome dell'unità organizzativa, può fare riferimento alla sezione.

CN: (nome comune)In riferimento al soggetto a cui viene rilasciato il certificato, è necessario specificare l'indirizzo IP specifico a cui accedere (IP di gestione wireless, IP virtuale e così via) o configurare il nome host con FQDN.

Nota: se si desidera aggiungere un nome soggetto alternativo, non è possibile farlo sulle versioni Cisco IOS XE precedenti alla 17.8.1 a causa dell'ID bug Cisco CSCvt1517 . Questo scenario può generare alcuni avvisi del browser a causa dell'assenza della SAN. Per evitare questo problema, creare la chiave e la CSR nella casella di configurazione off-box, come mostrato nell'opzione 1.

Passaggio 3: Inviare il CSR alla CA (Autorità di certificazione)

È necessario inviare la stringa completa alla CA per ottenerne la firma.

-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

Se si utilizza una CA di Windows Server per firmare il certificato, scaricare il certificato firmato in formato Base64. In caso contrario, è necessario eseguire l'esportazione con utilità quali Gestione certificati di Windows.

L'utente riceve dalla CA il certificato del dispositivo firmato, le CA intermedie (se presenti) e il certificato della CA radice.

Passaggio 4: Autenticare le CA sul WLC 9800

Se il certificato è firmato direttamente dalla CA radice, è possibile controllare le istruzioni dal passo4a (tutto può essere fatto usando la GUI).
Se il certificato è firmato da un'autorità di certificazione multilivello, seguire le istruzioni elencate al punto4b (in questo caso è richiesta la CLI).

Fase 4a: autenticazione della CA radice 

Rendere 9800 attendibile la CA emittente. Scaricare o ottenere il certificato CA dell'autorità emittente in formato .pem (Base64). Espandere la sezione Autenticazione CA radice all'interno dello stesso menu, scegliere il trust definito in precedenza dall'elenco a discesa TrustPoint e incollare il certificato CA dell'autorità emittente. Verificare che i dettagli siano configurati correttamente e fare clic su Autentica.

Configurazione CLI:

9800(config)# crypto pki authenticate 9800-CSR

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
    
      -----END CERTIFICATE----- 
    

Certificate has the following attributes:
       Fingerprint MD5: DD05391A 05B62573 A38C18DD CDA2337C
      Fingerprint SHA1: 596DD2DC 4BF26768 CFB14546 BC992C3F F1408809

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported

Fase 4b: autenticazione di CA multilivello

Nello scenario in cui esistono più livelli di autorizzazione, è necessario un nuovo trust point per ogni livello CA aggiuntivo. Se il certificato è firmato direttamente dalla CA radice, fare riferimento al punto 4a in quanto è richiesto un solo punto di fiducia (quello creato durante la generazione del CSR). 

Nel caso si disponga di una CA intermedia e di una CA radice, sono necessari due punti di trust: quello già creato (che contiene il certificato del dispositivo e il certificato della CA intermedia, che fa riferimento al punto di trust della CA radice) e uno nuovo, che contiene il certificato della CA radice. Nel caso in cui si disponga di 2 certificati intermedi, sono necessari 3 punti di trust e così via. Questi trust point aggiuntivi contengono solo il certificato di autenticazione e puntano al livello di autenticazione successivo. questo processo può essere eseguito solo dalla CLI. 

Configurazione CLI (esempio con una CA intermedia): 

9800(config)#crypto pki trustpoint RootCA
9800(ca-trustpoint)#enrollment terminal
9800(ca-trustpoint)#chain-validation stop
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#exit
9800(config)#crypto pki authenticate RootCA

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
    
-----END CERTIFICATE-----

Certificate has the following attributes:
Fingerprint MD5: 6CAC00D5 C5932D01 B514E413 D41B37A8
Fingerprint SHA1: 5ABD5667 26B7BD0D 83BDFC34 543297B7 3D3B3F24

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported

9800(config)#crypto pki trustpoint 9800-CSR <<< This is the trustpoint created with the CSR
9800(ca-trustpoint)#chain-validation continue RootCA <<< This is the trustpoint created above
9800(config)#crypto pki authenticate 9800-CSR

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----

Certificate has the following attributes: 
Fingerprint MD5: DD05391A 05B62573 A38C18DD CDA2337C 
Fingerprint SHA1: 596DD2DC 4BF26768 CFB14546 BC992C3F F1408809 
Certificate validated - Signed by existing trustpoint CA certificate.

Trustpoint CA certificate accepted. 
% Certificate successfully imported

Nota: se nella catena di certificazione sono presenti più CA intermedie, è necessario generare un nuovo punto di accesso per ogni livello di certificazione aggiuntivo. Questi punti di trust devono fare riferimento al punto di trust che contiene il livello di certificazione successivo con il comando chain-validation continue <nome-punto-di-trust>.

Configurazione CLI (esempio semplificato con 2 CA intermedie): 

9800(config)#crypto pki trustpoint RootCA
9800(ca-trustpoint)#enrollment terminal
9800(ca-trustpoint)#chain-validation stop
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#exit
9800(config)#crypto pki authenticate RootCA
-----BEGIN CERTIFICATE-----

    
    
-----END CERTIFICATE-----
9800(config)#crypto pki trustpoint Inter2 <<< This is the trustpoint for the 1st intermediate CA (from top of the chain)
9800(ca-trustpoint)#chain-validation continue RootCA <<< This is the trustpoint created above
9800(config)#crypto pki authenticate Inter2
-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----
9800(config)#crypto pki trustpoint 9800-CSR <<< This is the trustpoint created with the CSR
9800(ca-trustpoint)#chain-validation continue Inter2 <<< This is the trustpoint created above
9800(config)#crypto pki authenticate 9800-CSR
-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----

Passaggio 5: importare il certificato firmato del dispositivo sullo switch 9800

Caricare il certificato firmato nel WLC 9800. Espandere la sezione Importa certificato dispositivo nello stesso menu. Scegliere il trust point definito in precedenza e incollare il certificato di dispositivo firmato fornito dalla CA. Quindi fare clic su import (Importa) dopo aver verificato le informazioni sul certificato.

Configurazione CLI:

9800(config)#crypto pki import 9800-CSR certificate

Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----
< 9800 device certificate >
-----END CERTIFICATE-----

% Router Certificate successfully imported

A questo punto, il certificato del dispositivo viene importato nel WLC 9800 insieme a tutte le CA e il certificato è pronto per essere utilizzato (accesso GUI, WebAuth e così via)

Usa il nuovo certificato

Amministrazione Web (accesso GUI)

Passare a Amministrazione > Gestione > HTTP/HTTPS/Netconf e scegliere il certificato importato dall'elenco a discesa Trust Point.

Configurazione CLI:

9800(config)#ip http secure-trustpoint 9800.pfx
9800(config)#no ip http secure-server
9800(config)#ip http secure-server

Autenticazione Web locale

Passare a Configurazione > Sicurezza > Autenticazione Web, scegliere la mappa dei parametri globali e scegliere il trust point importato dall'elenco a discesa TrustPoint. Fare clic su Aggiorna e applica per salvare le modifiche. Verificare che il nome host IPv4 virtuale corrisponda al nome comune nel certificato.

Configurazione CLI:

9800(config)#parameter-map type webauth global
9800(config-params-parameter-map)#type webauth
9800(config-params-parameter-map)#virtual-ip ipv4 192.0.2.1 virtual-host mywlc.local-domain
9800(config-params-parameter-map)#trustpoint 9800-CSR

Per aggiornare l'utilizzo dei certificati, riavviare i servizi HTTP:

9800(config)#no ip http server
9800(config)#ip http server 

.

Considerazioni sull'alta disponibilità

Su una coppia 9800 configurata per lo standard HA (Stateful Switchover High Availability), tutti i certificati vengono replicati dal server primario al server secondario durante la sincronizzazione di massa iniziale. Sono inclusi i certificati in cui la chiave privata è stata generata sul controller stesso, anche se la chiave RSA è configurata per non essere esportabile. Una volta stabilita la coppia HA, qualsiasi nuovo certificato installato viene installato su entrambi i controller e tutti i certificati vengono replicati in tempo reale.

In caso di errore, l'ex controller secondario ora attivo utilizza in modo trasparente i certificati ereditati dal controller primario.

Verifica dell'attendibilità del certificato da parte dei browser Web

Per garantire l'attendibilità di un certificato da parte dei browser Web, è necessario tenere presenti alcune considerazioni importanti:

• Il relativo nome comune (o campo SAN) deve corrispondere all'URL visitato dal browser.
• Deve essere compreso nel suo periodo di validità.
• Deve essere rilasciato da una CA o da una catena di CA la cui radice è considerata attendibile dal browser. A tale scopo, il certificato fornito dal server Web deve contenere tutti i certificati della catena fino a quando non viene incluso un certificato considerato attendibile dal browser client (in genere la CA radice).
• Se contiene elenchi di revoche, il browser deve essere in grado di scaricarli e il certificato CN non deve essere elencato.

Verifica

È possibile utilizzare i seguenti comandi per verificare la configurazione dei certificati:

9800#show crypto pki certificate 9800.pfx

Certificate
Status: Available
Certificate Serial Number (hex): 1236
Certificate Usage: General Purpose
Issuer:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Subject:
Name: alz-9800
e=user@example.com
cn=alz-9800
ou=Cisco Systems
o=Wireless TAC
l=CDMX
st=CDMX
c=MX
Validity Date:
start date: 17:54:45 Pacific Sep 28 2021
end date: 17:54:45 Pacific Sep 26 2031
Associated Trustpoints: 9800.pfx

CA Certificate
Status: Available
Certificate Serial Number (hex): 1000
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Validity Date:
start date: 05:10:34 Pacific Apr 29 2020
end date: 05:10:34 Pacific Apr 27 2030
Associated Trustpoints: 9800.pfx

9800#show ip http server secure status

HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite: 3des-ede-cbc-sha aes-128-cbc-sha
 aes-256-cbc-sha dhe-aes-128-cbc-sha ecdhe-rsa-3des-ede-cbc-sha
 rsa-aes-cbc-sha2 rsa-aes-gcm-sha2 dhe-aes-cbc-sha2 dhe-aes-gcm-sha2
 ecdhe-rsa-aes-cbc-sha2 ecdhe-rsa-aes-gcm-sha2
HTTP secure server TLS version: TLSv1.2 TLSv1.1 TLSv1.0
HTTP secure server client authentication: Disabled
HTTP secure server trustpoint: 9800.pfx
HTTP secure server active session modules: ALL

È possibile verificare la catena di certificati sul modello 9800. Nel caso di un certificato di dispositivo rilasciato da una CA intermedia, a sua volta rilasciato da una CA radice, si dispone di un trust point per gruppi di due certificati, in modo che ogni livello disponga di un trust point specifico. In questo caso, il WLC 9800 ha 9800.pfx con il certificato del dispositivo (certificato WLC) e la relativa CA di rilascio (CA intermedia). Quindi un altro trust point con la CA radice che ha emesso la CA intermedia.

9800#show crypto pki certificate 9800.pfx
Certificate
Status: Available
Certificate Serial Number (hex): 1236
Certificate Usage: General Purpose
Issuer:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Subject:
Name: alz-9800
e=user@example.com
cn=alz-9800
ou=Cisco Systems
o=Wireless TAC
l=CDMX
st=CDMX
c=MX
Validity Date:
start date: 17:54:45 Pacific Sep 28 2021
end date: 17:54:45 Pacific Sep 26 2031
Associated Trustpoints: 9800.pfx

CA Certificate
Status: Available
Certificate Serial Number (hex): 1000
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Validity Date:
start date: 05:10:34 Pacific Apr 29 2020
end date: 05:10:34 Pacific Apr 27 2030
Associated Trustpoints: 9800.pfx

9800#show crypto pki certificate 9800.pfx-rrr1
CA Certificate
Status: Available
Certificate Serial Number (hex): 00
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Validity Date:
start date: 04:58:05 Pacific Apr 29 2020
end date: 04:58:05 Pacific Apr 27 2030
Associated Trustpoints: 9800-CSR 9800.pfx-rrr1

Verifica dei certificati con OpenSSL

OpenSSL può essere utile per verificare il certificato stesso o eseguire alcune operazioni di conversione.

Per visualizzare un certificato con OpenSSL:

openssl x509 -in 
    
    
      -text 
    

Per visualizzare il contenuto di un CSR:

openssl req -noout -text -in 
    
    

Se si desidera verificare il certificato finale sul WLC 9800 ma si desidera utilizzare un altro strumento oltre al browser, OpenSSL può eseguire questa operazione e fornire molti dettagli.

openssl s_client -showcerts -verify 5 -connect 
    
    
      :443 
    

È possibile sostituire <wlcURL> con l'URL di webadmin del modello 9800 o con l'URL del portale guest (IP virtuale). È inoltre possibile inserire un indirizzo IP. Indica la catena di certificati ricevuta, ma la convalida dei certificati non può mai essere corretta al 100% quando si utilizza un indirizzo IP anziché un nome host.

Per visualizzare il contenuto e verificare un certificato PKCS12 (con estensione pfx) o una catena di certificati:

openssl pkcs12 -info -in 
    
    

Di seguito è riportato un esempio di questo comando su una catena di certificati in cui il certificato del dispositivo viene rilasciato al Technical Assistance Center (TAC) da una CA intermedia chiamata "intermediate.com", a sua volta rilasciata da una CA radice chiamata "root.com":

openssl pkcs12 -info -in chainscript2.pfx
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
localKeyID: 1D 36 8F C2 4B 18 0B 0D B2 57 A2 55 18 96 7A 8B 57 F9 CD FD
subject=/C=BE/ST=Diegem/L=Diegem/O=Cisco/CN=TAC
issuer=/C=BE/ST=Diegem/O=Cisco/OU=TAC/CN=intermediate.com/emailAddress=int@int.com
-----BEGIN CERTIFICATE-----
< Device certificate >
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=BE/ST=Diegem/O=Cisco/OU=TAC/CN=intermediate.com/emailAddress=int@int.com
issuer=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
-----BEGIN CERTIFICATE-----
< Intermediate certificate >
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
issuer=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
-----BEGIN CERTIFICATE-----
< Root certificate >
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
localKeyID: 1D 36 8F C2 4B 18 0B 0D B2 57 A2 55 18 96 7A 8B 57 F9 CD FD
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
< Private key >
-----END ENCRYPTED PRIVATE KEY-----

Risoluzione dei problemi

Utilizzare questo comando per la risoluzione dei problemi. Se l'operazione viene eseguita in una sessione remota (SSH o telnet), è necessario un monitor del terminale per visualizzare le uscite:

9800#debug crypto pki transactions

Output del comando debug scenario completato

Questo output visualizza l'output previsto quando l'importazione di un certificato su un 9800 ha esito positivo. Utilizzare questo per riferimento e identificare lo stato di errore:

Sep 28 17:35:23.242: CRYPTO_PKI: Copying pkcs12 from bootflash:9800.pfx
Sep 28 17:35:23.322: CRYPTO_PKI: Creating trustpoint 9800.pfx
Sep 28 17:35:23.322: %PKI-6-TRUSTPOINT_CREATE: Trustpoint: 9800.pfx created succesfully
Sep 28 17:35:23.324: CRYPTO_PKI: examining cert:
Sep 28 17:35:23.324: CRYPTO_PKI: issuerName=cn=Chuu Intermediate CA,ou=Chuu Wireless,o=Chuu Inc,st=CDMX,c=MX
Sep 28 17:35:23.324: CRYPTO_PKI: subjectname=e=user@example.com,cn=alz-9800,ou=Cisco Systems,o=Wireless TAC,l=CDMX,st=CDMX,c=MX
Sep 28 17:35:23.324: CRYPTO_PKI: adding RSA Keypair
Sep 28 17:35:23.324: CRYPTO_PKI: bitValue of ET_KEY_USAGE = 140
Sep 28 17:35:23.324: CRYPTO_PKI: Certificate Key Usage = GENERAL_PURPOSE
Sep 28 17:35:23.324: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named 9800.pfx has been generated or imported by pki-pkcs12
Sep 28 17:35:23.331: CRYPTO_PKI: adding as a router certificate.Public key in cert and stored public key 9800.pfx match

Sep 28 17:35:23.333: CRYPTO_PKI: examining cert:
Sep 28 17:35:23.333: CRYPTO_PKI: issuerName=cn=Chuu Root CA,ou=Chuu Wireless,o=Chuu Inc,l=Iztapalapa,st=CDMX,c=MX
Sep 28 17:35:23.333: CRYPTO_PKI: subjectname=cn=Chuu Intermediate CA,ou=Chuu Wireless,o=Chuu Inc,st=CDMX,c=MX
Sep 28 17:35:23.333: CRYPTO_PKI: no matching private key presents.

[...]

Sep 28 17:35:23.335: CRYPTO_PKI: Setting the key_type as RSA
Sep 28 17:35:23.335: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.335: CRYPTO_PKI:Peer's public inserted successfully with key id 21
Sep 28 17:35:23.336: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.337: CRYPTO_PKI: Deleting cached key having key id 31
Sep 28 17:35:23.337: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.337: CRYPTO_PKI:Peer's public inserted successfully with key id 32
Sep 28 17:35:23.338: CRYPTO_PKI: (A0323) Session started - identity selected (9800.pfx)
Sep 28 17:35:23.338: CRYPTO_PKI: Rcvd request to end PKI session A0323.
Sep 28 17:35:23.338: CRYPTO_PKI
alz-9800#: PKI session A0323 has ended. Freeing all resources.
Sep 28 17:35:23.338: CRYPTO_PKI: unlocked trustpoint 9800.pfx, refcount is 0
Sep 28 17:35:23.338: CRYPTO_PKI: Expiring peer's cached key with key id 32Public key in cert and stored public key 9800.pfx match

Sep 28 17:35:23.341: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.341: CRYPTO_PKI: cert verified and inserted.
Sep 28 17:35:23.402: CRYPTO_PKI: Creating trustpoint 9800.pfx-rrr1
Sep 28 17:35:23.402: %PKI-6-TRUSTPOINT_CREATE: Trustpoint: 9800.pfx-rrr1 created succesfully
Sep 28 17:35:23.403: CRYPTO_PKI: Setting the key_type as RSA
Sep 28 17:35:23.404: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.404: CRYPTO_PKI:Peer's public inserted successfully with key id 22
Sep 28 17:35:23.405: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.406: CRYPTO_PKI: no CRLs present (expected)
Sep 28 17:35:23.406: %PKI-6-PKCS12_IMPORT_SUCCESS: PKCS #12 import in to trustpoint 9800.pfx successfully imported.

Provare a importare un certificato PKCS12 privo di CA

Se si importa un certificato e viene visualizzato il messaggio di errore "Impossibile trovare il certificato CA", significa che il file con estensione pfx non contiene l'intera catena o che una CA non è presente.

9800(config)#crypto pki import pkcs12.pfx pkcs12 bootflash:pks12.pfx password 
    
    
% Importing pkcs12...
Source filename [pks12.pfx]?
Reading file from bootflash:pks12.pfx
% Warning: CA cert is not found. The imported certs might not be usable.

Se si esegue il comando openssl pkcs12 -info -in <percorso del certificato> e viene visualizzato un solo certificato con una chiave privata, significa che la CA non è presente. In genere, questo comando elenca l'intera catena di certificati. Non è necessario includere la CA radice principale superiore se è già nota ai browser client.

Un modo per risolvere il problema consiste nel decostruire il PKCS12 in PEM e ricostruire la catena in modo corretto. Nell'esempio successivo era presente un file con estensione pfx contenente solo il certificato del dispositivo (WLC) e la relativa chiave. È stato rilasciato da una CA intermedia (che non era presente nel file PKCS12) che a sua volta è stata firmata da una CA radice nota.

Passaggio 1. Esporta la chiave privata in uscita.

openssl pkcs12 -in 
    
    
      -out cert.key -nocerts -nodes 
    

Passaggio 2. Esporta il certificato come PEM.

openssl pkcs12 -in 
    
    
      -out certificate.pem -nokeys -clcerts 
    

Passaggio 3. Scaricare il certificato CA intermedio come PEM.

L'origine della CA dipende dalla natura della CA. Se si tratta di una CA pubblica, è sufficiente una ricerca in linea per trovare il repository. In caso contrario, l'amministratore della CA deve fornire i certificati nel formato Base64 (.pem). Se sono presenti più livelli di CA, raggrupparli in un unico file come quello presentato al termine del processo di importazione dell'opzione 1.

Passaggio 4. Ricostruire il PKCS 12 dalla chiave, dal certificato del dispositivo e dal certificato della CA.

openssl pkcs12 -export -out fixedcertchain.pfx -inkey cert.key -in certificate.pem -certfile CA.pem

A questo punto è disponibile il file "fixedcertchain.pfx" che è possibile importare in Catalyst 9800!

Esportazione della chiave privata

Se si esegue la migrazione a un altro WLC o si desidera ripristinare il WLC, è possibile che la chiave privata venga esportata per essere spostata in un'altra posizione.

#crypto key export rsa 
    
    
      pem terminal aes 
      
    

Note e limitazioni

• Cisco IOS® XE non supporta certificati CA con ID bug Cisco oltre il 2099: CSCvp64208
• Cisco IOS® XE non supporta il bundle PKCS 12 con message digest SHA256 (sono supportati i certificati SHA256, ma non se il bundle PKCS12 è firmato con SHA256) : CSCvz41428. Questo problema è stato risolto nella versione 17.12.1. 
• È possibile verificare la frammentazione se il WLC deve trasportare certificati utente e l'appliance NAC/ISE è raggiungibile tramite Internet (ad esempio, in una distribuzione SD-WAN). I certificati sono quasi sempre più grandi di 1500 byte (ossia vengono inviati diversi pacchetti RADIUS per trasportare il messaggio del certificato) e se si hanno diverse MTU sul percorso di rete, può verificarsi una frammentazione eccessiva dei pacchetti RADIUS stessi. In questi casi, si consiglia di inviare tutti i datagrammi UDP per il traffico WLC sullo stesso percorso per evitare problemi di ritardo/jitter che possono essere causati da condizioni meteo su Internet