Questo documento descrive come richiedere, installare, considerare attendibili e rinnovare alcuni tipi di certificati su software Cisco ASA gestito con ASDM.
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
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.
I tipi di certificati a cui si riferisce il documento sono:
SSL (Secure Sockets Layer), TLS (Transport Layer Security) e IKEv2 rfc7296 per i protocolli di autenticazione EAP richiedono che il server SSL/TLS/IKEv2 fornisca al client un certificato server per eseguire l'autenticazione del server. A tale scopo, è consigliabile utilizzare CA di terze parti attendibili per rilasciare certificati SSL all'appliance ASA.
Cisco sconsiglia di utilizzare un certificato autofirmato perché potrebbe essere impossibile configurare inavvertitamente un browser per considerare attendibile un certificato rilasciato da un server non autorizzato. Gli utenti possono ricevere avvisi di protezione durante la connessione al gateway sicuro, con conseguenti possibili interruzioni del flusso di lavoro.
Quando è installato, un certificato CA attendibile può essere utilizzato per autenticare diversi tipi di connessioni VPN tramite l'autenticazione del certificato. È controllato con il comando di trust Validation-Usage (Configurazione > Gestione dispositivi > Gestione certificati >Certificati CA >Aggiungi -> Altre opzioni... > Avanzate > selezionare le opzioni di utilizzo della convalida).
I tipi di utilizzo della convalida sono:
ipsec-client: Convalida le connessioni client IPSec.ssl-client: Convalida le connessioni client SSL.ssl-server: Convalida i certificati server SSL.
Navigate to:
Configuration > Device Management > Certificate Management > CA Certificates.
a) Select a wanted trustpoint and click Edit.
b) Navigate to Advanced and uncheck all Validation Usage options.
trustpoint public-root-ca no validation-usage

Per impostazione predefinita, è possibile utilizzare un certificato CA attendibile per autenticare un peer IPSEC VPN o un utente VPN ad accesso remoto che si connette a qualsiasi gruppo di tunnel. È necessario progettare un'autorizzazione adeguata.
Utilizzare le mappe dei certificati e dei gruppi di tunnel per garantire che per gruppi di tunnel specifici vengano utilizzati solo i certificati autorizzati. Impostare una regola della mappa del gruppo di tunnel predefinita che punti a un gruppo di tunnel senza accesso per limitare l'accesso non autorizzato.
L'autenticazione del certificato è consentita solo per:
Gli utenti con altri certificati vengono assegnati a no_access tunnel-group per impostazione predefinita, tramite il comando tunnel-group-map default-group no_access. Le regole di mapping dei certificati hanno la priorità sull'URL del gruppo grazie al comando tunnel-group-map enable rules. La conoscenza dell'URL del gruppo non consente di ignorare le regole di mapping dei certificati.
Navigate to:
Configuration > Remote Access VPN > Network (Client) Access > Group Policies > Add > General > More Options
a) Uncheck Inherit next to Simultaneous Logins and set the value 0.
b) Uncheck Inherit next to Banner and set a wanted massage, for example NO ACCESS GROUP POLICY.
group-policy no_access_gp internal
group-policy no_access_gp attributes
banner value NO ACCESS GROUP POLICY
vpn-simultaneous-logins 0
Accessi simultanei impostati su 0
2. Configurare i gruppi di tunnel per gli utenti e i gruppi di tunnel che impediscono l'accesso VPN.
Navigate to:
Configuration > Remote Access VPN > Network (Client) Access > Secure Client Connection Profiles. Click Add and configure:
a) Authentication method as Certificate.
b) Group Policy - for the no_access tunnel group use no_access_gp where simultaneous logins is set to 0.
tunnel-group mgmt-tunnel type remote-access tunnel-group mgmt-tunnel general-attributes address-pool vpn_pool default-group-policy mgmt-tunnel tunnel-group mgmt-tunnel webvpn-attributes authentication certificate ! tunnel-group users_access type remote-access tunnel-group users_access general-attributes default-group-policy user_access_gp address-pool vpn_pool tunnel-group users_access webvpn-attributes authentication certificate ! tunnel-group no_access type remote-access tunnel-group no_access general-attributes default-group-policy no_access_gp address-pool vpn_pool tunnel-group no_access webvpn-attributes authentication certificate
Nessun gruppo di tunnel di accesso
3. Creare mapping dei certificati per gli utenti e utilizzare i mapping dei certificati per il mapping tunnel-gruppo:
Navigate to: Configuration > Remote Access VPN > Advanced > Certificate to Secure Client and Clientless SSL VPN Connection Profile Maps.
a) Click Add to configure Certificate to Connection Profile Maps.
b) Select New and configure a certificate group map name, for example mgmt_tunnel_map or users_access_map.
c) Select a corresponding connection profile/tunnel group from the drop-down menu at Mapped to Connection Profile.
d) Click Add to configure Mapping Criteria.
e) Select: Field: Subject, Component: Organizational Unit (OU), Operator: Equals, Value: machines or users.
d) Select: Field: Issuer, Component: Common Name (CN), Operator: Equals, Value: example.com.
crypto ca certificate map mgmt_tunnel_map 10
issuer-name attr cn eq example.com
subject-name attr ou eq machines
crypto ca certificate map users_access_map 10
issuer-name attr cn eq example.com
subject-name attr ou eq users
!
webvpn
(...)
certificate-group-map mgmt_tunnel_map 10 mgmt-tunnel
certificate-group-map users_access_map 10 users_access
Mappe profilo connessione certificato-client sicura
4. Abilitare le mappe dei gruppi di tunnel e configurare un gruppo di tunnel predefinito per negare l'accesso se un certificato utente non corrisponde ad altre mappe di certificati.
Navigate to: Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Certificate to Connection Profile Maps > Policy.
a) Check Use the configure rules to match a certificate to a Connection Profile.
b) Check Default to Connection Profile and select from the drop-down menu the no-access connection profile/tunnel group.
tunnel-group-map enable rules tunnel-group-map default-group no_access
Abilita mapping certificati e profilo di connessione predefinitoPer istruzioni di configurazione più dettagliate, fare riferimento alla documentazione di Cisco:
È possibile richiedere un certificato a un'Autorità di certificazione (CA) e installarlo su un'appliance ASA in due modi:
Sul dispositivo viene creato un CSR che richiede un certificato di identità. Utilizzare una coppia di chiavi creata sul dispositivo.
Un CSR contiene:
Il CSR viene passato all'Autorità di certificazione (CA) per la firma nel modulo PKCS#10.
Il certificato firmato viene restituito dalla CA in un modulo PEM.








| Attributo | Descrizione |
|---|---|
| CN | Il nome attraverso il quale è possibile accedere al firewall (in genere il nome di dominio completo, ad esempio vpn.example.com). |
| UO | Il nome del reparto all'interno dell'organizzazione. |
| O | La ragione sociale legalmente registrata dell'azienda/organizzazione. |
| C | Codice paese (codice a 2 lettere senza punteggiatura). |
| ST | Stato in cui si trova l'organizzazione. |
| L | Città in cui si trova l'organizzazione. |
| EA | Indirizzo email |





Nelle procedure di installazione si presuppone che l'autorità di certificazione abbia firmato il CSR e abbia fornito un certificato di identità con codifica PEM (.pem,.cer, .crt) e un bundle di certificati CA.






È necessario configurare l'ASA in modo che utilizzi il nuovo certificato di identità per le sessioni WebVPN che terminano sull'interfaccia specificata.


A questo punto il nuovo certificato di identità è in uso.
Il file PKCS12 (formato .p12 o .pfx) contiene il certificato di identità, la coppia di chiavi e i certificati CA. Viene creata dalla CA, in caso di certificato con caratteri jolly, o esportata da un dispositivo diverso. Si tratta di un file binario e non può essere visualizzato con un editor di testo.




È necessario configurare l'ASA in modo che utilizzi il nuovo certificato di identità per le sessioni WebVPN che terminano sull'interfaccia specificata.


Il rinnovo del certificato di un certificato registrato CSR richiede la creazione e la registrazione di un nuovo punto di attendibilità. Deve avere un nome diverso, ad esempio un nome precedente con il suffisso dell'anno di iscrizione. Può utilizzare gli stessi parametri e la stessa coppia di chiavi del certificato precedente oppure diversi.







| Attributo |
Descrizione |
|---|---|
| CN |
Il nome attraverso il quale è possibile accedere al firewall (in genere il nome di dominio completo, ad esempio vpn.example.com). |
| UO |
Il nome del reparto all'interno dell'organizzazione. |
| O |
La ragione sociale legalmente registrata dell'azienda/organizzazione. |
| C |
Codice paese (codice a 2 lettere senza punteggiatura) |
| ST |
Stato in cui si trova l'organizzazione. |
| L |
Città in cui si trova l'organizzazione. |
| EA |
Indirizzo email |





Nelle procedure di installazione si presuppone che l'autorità di certificazione abbia firmato il CSR e abbia fornito un nuovo certificato di identità e un bundle di certificati CA codificati PEM (.pem, .cer, .crt).
Il certificato CA che ha firmato il certificato di identità può essere installato nel punto di fiducia creato per il certificato di identità. Se il certificato di identità è firmato da un'autorità di certificazione intermedia, è possibile installare tale certificato nel punto di fiducia del certificato di identità. Tutti i certificati CA a monte nella gerarchia e possono essere installati in punti di trust CA distinti.



In questo esempio, il nuovo certificato è firmato con lo stesso certificato CA del precedente. Lo stesso certificato CA è associato a due punti di trust.




È necessario configurare l'ASA in modo che utilizzi il nuovo certificato di identità per le sessioni WebVPN che terminano sull'interfaccia specificata.


Il rinnovo del certificato di registrazione PKCS12 richiede la creazione e la registrazione di un nuovo trust point. Deve avere un nome diverso, ad esempio un nome precedente con il suffisso dell'anno di iscrizione.
Il file PKCS12 (formato .p12 o .pfx) contiene il certificato di identità, la coppia di chiavi e i certificati CA. Viene creata dalla CA, ad esempio nel caso di un certificato con caratteri jolly, oppure esportata da un dispositivo diverso. Si tratta di un file binario e non può essere visualizzato con un editor di testo.
Il certificato di identità, i certificati CA e la coppia di chiavi devono essere raggruppati in un unico file PKCS12.




È necessario configurare l'ASA in modo che utilizzi il nuovo certificato di identità per le sessioni WebVPN che terminano sull'interfaccia specificata.


Utilizzare questa procedura per verificare che l'installazione dei certificati dei fornitori di terze parti sia stata completata correttamente e per utilizzare le connessioni VPN SSL.

Se l'installazione di un certificato SSL ha esito negativo, questo comando di debug viene raccolto nella CLI per raccogliere le informazioni di diagnostica.
D. Che cos'è PKCS12?
R. In crittografia, PKCS12 definisce un formato di file di archivio creato per memorizzare molti oggetti di crittografia come un unico file. Viene in genere utilizzato per includere una chiave privata nel relativo certificato X.509 o per includere tutti i membri di una catena di attendibilità.
D. Che cos'è un CSR?
A. Nei sistemi con infrastruttura a chiave pubblica (PKI), una richiesta di firma del certificato (anche CSR o richiesta di certificazione) è un messaggio inviato da un richiedente a un'autorità di registrazione dell'infrastruttura a chiave pubblica per richiedere un certificato di identità digitale. In genere contiene la chiave pubblica per la quale è possibile rilasciare il certificato, le informazioni utilizzate per identificare il certificato firmato (ad esempio un nome di dominio in Oggetto) e la protezione dell'integrità (ad esempio, una firma digitale).
D. Dov'è la password di PKCS12?
R. Quando si esportano certificati e coppie di chiavi in un file PKCS12, la password viene specificata nel comando di esportazione. Per importare un file PKCS12, la password deve essere recapitata dal proprietario del server CA o da un utente che ha esportato il file PKCS12 da un altro dispositivo.
D. Qual è la differenza tra la radice e l'identità?
R. Nella crittografia e nella protezione del computer, un certificato radice è un certificato a chiave pubblica che identifica un'autorità di certificazione (CA) radice. I certificati radice sono autofirmati (ed è possibile che un certificato abbia più percorsi di attendibilità, ad esempio, se il certificato è stato rilasciato da una radice con firma incrociata) e costituiscono la base di un'infrastruttura a chiave pubblica (PKI) basata su X.509. Un certificato a chiave pubblica, noto anche come certificato digitale o certificato di identità, è un documento elettronico utilizzato per provare la proprietà di una chiave pubblica. Il certificato include informazioni sulla chiave, informazioni sull'identità del proprietario (denominato soggetto) e la firma digitale di un'entità che ha verificato il contenuto dei certificati (denominata emittente). Se la firma è valida e il software che esamina il certificato considera attendibile l'autorità emittente, può utilizzare tale chiave per comunicare in modo sicuro con il soggetto del certificato.
D. Ho installato il certificato, perché non funziona?
R. Ciò può essere dovuto a diversi motivi, ad esempio:
1. Il certificato e il trust point sono configurati, tuttavia, non sono stati associati al processo che li utilizza. Ad esempio, il trust point utilizzato non è associato all'interfaccia esterna che termina le connessioni dei client VPN AnyConnect di Cisco Secure Access.
2. È installato un file PKCS12, ma vengono restituiti errori dovuti alla mancanza del certificato CA intermedio nel file PKCS12. I client che hanno il certificato CA intermedio come attendibile, ma non hanno il certificato CA radice come attendibile, non possono verificare l'intera catena di certificati e segnalare il certificato di identità del server come non attendibile.
3. Un certificato contenente attributi non corretti può causare errori di installazione o errori sul lato client. Alcuni attributi, ad esempio, vengono codificati utilizzando il formato errato. Un altro motivo è che nel certificato di identità manca il nome alternativo del soggetto (SAN) oppure il nome di dominio utilizzato per accedere al server non è presente come SAN.
D. L'installazione di un nuovo certificato richiede una finestra di manutenzione o causa tempi di inattività?
R. L'installazione di un nuovo certificato (identità o CA) non è intrusiva e non causa tempi di inattività né richiede un intervento di manutenzione. L'abilitazione di un nuovo certificato da utilizzare per un servizio esistente è una modifica e richiede una finestra di richiesta di modifica/manutenzione.
D. È possibile aggiungere o modificare un certificato per disconnettere gli utenti connessi?
R. No, gli utenti attualmente connessi rimangono connessi. Il certificato viene utilizzato al momento della connessione. Una volta riconnessi gli utenti, verrà utilizzato il nuovo certificato.
D. Come creare un CSR con un carattere jolly? O un nome alternativo del soggetto (SAN)?
A. Al momento, l'ASA/FTD non può creare un CSR con un carattere jolly; tuttavia, questo processo può essere eseguito con OpenSSL. Per generare la chiave CSR e ID, è possibile eseguire i comandi seguenti:
openssl genrsa -out id.key 2048
openssl req -out id.csr -key id.key -new
Quando un trust point è configurato con un attributo FQDN (Fully Qualified Domain Name), il CSR creato da ASA/FTD contiene la SAN con tale valore. La CA può aggiungere altri attributi SAN quando firma il CSR oppure è possibile creare il CSR con OpenSSL
D. La sostituzione del certificato è immediata?
R. Il nuovo certificato di identità del server viene utilizzato solo per le nuove connessioni. Un nuovo certificato è pronto per essere utilizzato subito dopo la modifica, ma viene utilizzato con le nuove connessioni.
D. Come verificare se l'installazione funziona?
A. Il comando CLI da verificare: show crypto ca cert <nometrust>
D. Come si genera PKCS12 da certificato di identità, certificato CA e chiave privata?
R. PKCS12 può essere creato con OpenSSL, con il comando:
openssl pkcs12 -export -out p12.pfx -inkey id.key -in id.crt -certfile ca.crt
D. Come esportare un certificato per installarlo in una nuova appliance ASA?
R.
Con CLI: utilizzare il comando: crypto ca export <nometrust> pkcs12 <password>
Con ASDM:


D. Se vengono utilizzate chiavi ECDSA, il processo di generazione del certificato SSL è diverso?
R. L'unica differenza nella configurazione è la fase di generazione della coppia di chiavi, in cui è possibile generare una coppia di chiavi ECDSA anziché una coppia di chiavi RSA. Il resto dei gradini rimane lo stesso.
D. È sempre necessario generare una nuova coppia di chiavi?
A. I passaggi per la generazione della coppia di chiavi sono facoltativi. È possibile utilizzare la coppia di chiavi esistente oppure importare la coppia di chiavi PKCS12 con il certificato. Vedere la sezione Selezionare il nome della coppia di chiavi per il rispettivo tipo di registrazione/ri-registrazione.
D. È sicuro generare una nuova coppia di chiavi per un nuovo certificato di identità?
R. Questo processo è sicuro se si utilizza un nuovo nome di coppia di chiavi. In questo caso, le vecchie coppie di chiavi non vengono modificate.
D. È necessario generare nuovamente la chiave quando si sostituisce un firewall (come RMA)?
R. Il nuovo firewall non dispone per impostazione predefinita di una coppia di chiavi sul firewall precedente.
Il backup della configurazione corrente non contiene le coppie di chiavi. Il backup completo eseguito con ASDM può contenere le coppie di chiavi.
I certificati di identità possono essere esportati da un'appliance ASA con ASDM o CLI prima che si verifichi un errore. In caso di coppia di failover, i certificati e le coppie di chiavi vengono sincronizzati su un'unità in standby con un comando write standby. Se viene sostituito un nodo della coppia di failover, è sufficiente configurare il failover di base e inviare la configurazione al nuovo dispositivo.
Se una coppia di chiavi viene persa con il dispositivo e non è disponibile alcun backup, è necessario firmare un nuovo certificato con una coppia di chiavi presente nel nuovo dispositivo.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
29-May-2026
|
È stata aggiornata la spaziatura, le intestazioni e riscritta un paio di frasi a causa della struttura/grammatica. |
4.0 |
15-Nov-2024
|
Traduzione automatica e formattazione aggiornate. |
3.0 |
25-Jul-2024
|
Testo alternativo aggiornato, problemi di stile, espressioni e punteggiatura/maiuscole. |
2.0 |
22-Apr-2023
|
Elenco collaboratori aggiornato. |
1.0 |
19-Apr-2023
|
Versione iniziale |