Questo articolo spiegherà come utilizzare i certificati emessi da un'autorità di certificazione (CA) di terze parti, come Let's Encrypt, Comodo, Symantec, Digicert ecc. Inoltre tratterà come funzionano i certificati in generale.
Sinossi
I certificati hanno due scopi principali: crittografare la comunicazione tra due entità e confermare l'autenticità dell'entità. Il primo può essere concesso da un cosiddetto certificato autofirmato, ma per autenticare l'entità è necessario un certificato globalmente attendibile emesso dalla CA radice o intermedia. Questo articolo spiegherà come i certificati generalmente ottengono questa autenticazione, come modificare il formato del certificato per funzionare con altri dispositivi, inclusi i nostri firewall, come importare il certificato nel tuo firewall e come devono essere gestiti i certificati per evitare rischi per la sicurezza.
Tabella dei contenuti
- Come funziona un certificato?
- Certificati autofirmati
- Lavorare con i certificati
- Importazione di certificati nei firewall USG/ATP
- Sicurezza del certificato
Come funziona un certificato?
Ogni certificato è composto da due parti: il certificato (chiamato anche chiave pubblica) e la chiave privata. Il certificato può essere condiviso pubblicamente e contiene semplicemente informazioni sugli scopi per cui è stato emesso il certificato e per quale entità è stato emesso il certificato - questo potrebbe essere il tuo FQDN, indirizzo e-mail o altro valore.
I certificati hanno un periodo di validità limitato: questo aiuta nelle situazioni in cui alcuni vecchi certificati con una chiave privata vengono ritrovati da qualche parte dopo decenni. Se la validità fosse infinita, il certificato potrebbe comunque essere utilizzato per scopi dannosi da chiunque vi metta le mani sopra. A partire dal 2021, si consiglia di non utilizzare un periodo di validità superiore a un anno. Con l'avvento di meccanismi di riemissione automatica come CertBot, questo periodo potrebbe essere molto più breve per migliorare ulteriormente la sicurezza.
I certificati possono essere revocati nel caso in cui la chiave privata sia stata trapelata e, per precauzione, qualsiasi violazione della sicurezza che ha compromesso l'hardware contenente chiavi private dovrebbe essere seguita da una revoca del certificato e dalla successiva riemissione di nuovi certificati.
I certificati possono essere emessi a varie entità, come FQDN, e-mail, persino indirizzo IP o nome. Sebbene sia tecnicamente possibile avere certificati FQDN con caratteri jolly e questi sono spesso preferiti dagli utenti, tieni presente che in caso di perdita di chiave privata da un servizio specifico, il certificato con caratteri jolly autentica l'intero FQDN - di conseguenza, una perdita del la chiave privata su un server Web che viene utilizzata per la semplice presentazione aziendale può essere utilizzata anche per attacchi MITM tra server Exchange o sistema CRM. Mantenere i certificati indipendenti per ogni sottodominio aiuta a mitigare l'impatto della perdita fino alla revoca del certificato.
Sebbene sia anche possibile emettere certificati per l'indirizzo IP, farlo è deprecato. La ragione di ciò è che gli IP possono essere modificati facilmente rispetto all'FQDN.
Il principio di base dei certificati è abbastanza semplice. In un esempio, Alice vuole accedere al server di Bob, ma il problema è che non è mai stata lì, quindi non potrebbero mai scambiarsi un segreto comune per autenticarsi. Come può Alice essere sicura di essere davvero connessa a Bob? È qui che entra in gioco Charlie. Alice conosce Charlie e ha aggiunto il suo certificato al repository dei certificati radice. Quindi Alice considera Charlie un'entità fidata. Se Bob ha il suo certificato e la sua chiave privata emessi da Charlie, può autenticarsi con Alice e non importa che Alice non sia mai stata in contatto con Bob prima, perché Bob è considerato affidabile da Charlie, e poiché Alice si fida di Charlie, anche lei si fida di Bob . Questa è una cosa chiamata catena di fiducia.
Diamo un'occhiata alla catena di fiducia per il nostro certificato web Support Campus:
Nota che c'è anche un'altra entità chiamata R3. Questo è chiamato CA intermedio, mentre DST Root CA X3 è Root CA. Il certificato può avere solo una CA radice, ma possono esserci più CA intermedie. La CA intermedia è un'entità a cui è stata concessa l'autorizzazione a emettere certificati per i propri clienti. Finché il tuo PC ha il certificato DST Root CA X3 nell'elenco dei certificati radice attendibili, considererà attendibile support.zyxel.eu.
Certificati autofirmati
Per impostazione predefinita, i nostri firewall (e molti altri dispositivi) utilizzano certificati autofirmati per stabilire una connessione TLS crittografata. Tale certificato viene segnalato da un noto messaggio di errore del browser: 
Ci sono due ragioni per cui questo accade. Il primo motivo è che il certificato è fondamentalmente un certificato CA radice che non è presente nel sistema. Ma installarlo semplicemente come CA root sul tuo computer non funzionerà, perché il certificato non viene emesso per il tuo IP o dominio. Il certificato è comunque adatto per una connessione sicura e il suo utilizzo non comporta alcun rischio per la sicurezza finché la sua chiave privata non viene trapelata - l'unico problema qui è che l'identità non può essere confermata.
Lavorare con i certificati
Nel corso degli anni sono stati sviluppati molti formati di certificati. I certificati, tuttavia, utilizzano ancora lo stesso principio e tutti i formati possono essere convertiti in altri formati.
Formati dei certificati
Il formato più vecchio sarebbe il PEM, che contiene la chiave codificata ASCII. La ragione di ciò è l'utilizzo originale nelle e-mail crittografate, in cui il certificato binario potrebbe essere malformato. I PEM sono comuni nei sistemi Unix ed è probabile che la tua CA ti abbia inviato un certificato insieme a una chiave privata in formato PEM. Di solito usa l'estensione del file .pem o .cer.
DER è una forma binaria di certificato in formato ASCII PEM. Tutti i tipi di certificati e chiavi private possono essere codificati in formato DER. Questo formato supporta l'archiviazione di un singolo certificato e non include una chiave privata per la CA intermedia/root. Hanno estensione .der o .cer e sono più spesso utilizzati su piattaforme Java.
PKCS#7 è un formato binario che consente di contenere certificati o interi certificati Chain of Trust in un unico file. Tuttavia, nessuna chiave privata può essere memorizzata in questo formato. Questo formato è più spesso utilizzato dalle CA per fornire una catena di fiducia completa. Utilizza l'estensione .p7b.
PKCS#12, noto anche come PFX, è un formato che può contenere l'intera catena di fiducia e anche la chiave privata. Di solito, questo formato è fornito dalle CA, poiché può essere protetto da una password. Usa comunemente l'estensione .p12 o .pfx.
Strumenti di certificazione
Windows dispone di un'utilità CLI di sistema integrata certutil che può essere utilizzata per convertire i certificati. I plug-in di gestione in Microsoft Management Console consentono anche la gestione dei certificati.
L'utilità open source chiamata OpenSSL è anche in grado di gestire e convertire i certificati. I binari sono disponibili per Windows, Linux e macOS (e molte altre piattaforme)
Comandi certutil utili:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Comandi OpenSSL utili:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importazione del certificato nei firewall USG/ATP
Il design attuale (a partire da giugno 2021) è limitato all'importazione di certificati senza chiavi intermedie. Se il certificato contiene una chiave intermedia, il file verrà analizzato in modo errato e il tentativo di utilizzare tale certificato potrebbe comportare l'indisponibilità del servizio (come WebGUI). È una buona idea ottenere il certificato in formato .pem ed esportarlo in formato .pfx utilizzando certutil o OpenSSL. Il certificato può essere importato, insieme alla sua password, nel seguente menu:
Configuration > Objects > Certificates > My Certificates
Sicurezza del certificato
Ogni certificato ha la sua rispettiva chiave privata. Sebbene un certificato sia un'informazione pubblica, la chiave privata deve essere gestita come segreta e non deve essere condivisa da nessuno. Nemmeno con noi di Zyxel: l'unico modo valido è utilizzare strumenti di assistenza remota come TeamViewer. Quando si archivia la chiave privata in formato pem, ricontrollare le autorizzazioni per accedere alla chiave privata per evitare perdite. Utilizzare sempre la crittografia della password in formato pfx per fornire almeno un certo grado di sicurezza durante l'esportazione dei certificati. Eventuali certificati con la chiave privata trapelata devono essere revocati immediatamente.
ESCLUSIONE DI RESPONSABILITA':
Gentile cliente, tieni presente che utilizziamo la traduzione automatica per fornire articoli nella tua lingua locale. Non tutto il testo può essere tradotto accuratamente. In caso di domande o discrepanze sull'accuratezza delle informazioni nella versione tradotta, rivedere l'articolo originale qui: Versione originale