Se hai una forte comprensione di cosa sia un certificato X509, alza la mano. Ora che abbiamo constatato che nessuno sta alzando la mano, cambiamo questa situazione.
I certificati sono un argomento complesso e spesso poco compreso. Questo tutorial si propone di cambiare questa situazione mostrandoti esempi di certificati X509, dimostrando i certificati PKI e molto altro ancora.
In questo articolo otterrai una buona panoramica dei certificati X509. Alla fine, comprenderai come funzionano a grandi linee. Non diventerai un esperto con un solo articolo, ma alla fine di questo articolo avrai almeno familiarità con la terminologia corretta.
Argomento correlato: Gestione dei certificati con Windows Certificate Manager e PowerShell
Chiavi pubbliche e private: protezione degli asset
Qualsiasi spiegazione sui certificati X509 sarebbe incompleta senza menzionare prima le chiavi. Avrai sentito parlare del concetto di chiavi quando vengono usati termini come private e pubbliche chiavi. Ma cosa è esattamente una chiave e come si relaziona con i certificati?
Per rendere la connessione più facile, spieghiamo il concetto di chiavi con un buon e vecchio lucchetto per porte.
Quando acquisti un nuovo lucchetto per porte, quest’ultimo viene fornito con una chiave. Quella chiave è unica per quel lucchetto in modo che nessun altro possa aprirlo.
Pensa alla serratura stessa come a una chiave pubblica. Quando installata, tu, la tua famiglia o i passanti possono vedere la serratura sulla tua porta. Chiunque è libero di vederla e persino cercare di aprirla, ma non avrà successo. Per aprirla, avrebbero bisogno di inserire la chiave unica della porta che è stata originariamente fornita con la serratura. La chiave unica fornita con la serratura è la chiave privata.
La chiave privata e quella pubblica insieme vengono chiamate una coppia di chiavi.
Scambio di chiavi
Quando la chiave della porta viene inserita nella serratura, puoi pensare a quell’azione come a uno scambio di chiavi. La chiave privata (chiave della porta) deve essere scambiata con la chiave pubblica (serratura) per aprire la porta.
Nel mondo della crittografia, darai liberamente una chiave pubblica a chiunque e terrai la chiave privata per te stesso. Dopotutto, non ti importa chi vede la serratura, ma sicuramente ti importa chi può aprirla (scambiare le chiavi).
Esistono un paio di modi diversi in cui le chiavi vengono scambiate, chiamati algoritmi di scambio di chiavi. Gli algoritmi di scambio di chiavi si concentrano sulla derivazione e sulla trasmissione sicura di un segreto condiviso unico.
Due popolari algoritmi di scambio di chiavi che potresti aver sentito nominare sono Diffie-Hellman (DH) e Elliptic Curve Diffie-Hellman (ECDH).
Fiducia nelle chiavi
Se hai bisogno che qualcuno entri attraverso la porta, gli daresti la chiave (o una copia dell’originale, chiave unica). Dai la tua chiave solo a coloro che affidi. La persona che detiene la chiave privata (chiave della porta) è stata affidata ad aprire la serratura della porta (chiave pubblica).
Utilizzo delle chiavi
L’uso chiave definisce lo scopo del certificato X509, questo si allinea agli algoritmi che il certificato utilizzerà. L’uso chiave estesa (EKU) definisce gli scopi previsti per la chiave pubblica al di là dell’uso chiave.
Certificati X509: “Contenitori” di chiavi pubbliche
Come si relazionano le chiavi private e pubbliche al concetto di un certificato X509? Pensate a un certificato come a una semplice chiave pubblica. Un certificato è l'”involtura” che contiene una chiave pubblica insieme ad altre informazioni sulla chiave, come a chi è stata emessa la chiave pubblica, chi ha firmato la chiave e così via. I certificati sono memorizzati sotto forma di file.
In seguito illustreremo un paio di buoni esempi di certificati X509.
Hai mai visto un file con estensione di file PEM o CER? Quelli sono certificati (chiavi pubbliche). Scoprirai di più su questi formati un po’ più avanti.
La chiave pubblica da sola non è necessariamente un certificato per definizione. È la chiave pubblica e i dati attributi associati combinati che definiscono un certificato.
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
Thumbprint: Un identificatore unico del certificato
Ogni certificato X509 è destinato a fornire l’identificazione di un singolo soggetto. Il certificato dovrebbe garantire che ogni chiave pubblica sia univocamente identificabile.
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
Il concetto di identificare un insieme di dati più ampio con un identificatore univoco più piccolo è l’argomento generale dell’informatica del fingerprinting. Il blog di Morgan Simonson approfondisce ulteriormente il thumbprint.
Oggetto: Definizione degli attributi importanti dei certificati X509
Ogni certificato X509 deve non solo avere un identificatore univoco, ma anche rispondere a domande come quelle di seguito riportate. Il soggetto del certificatodeve fare proprio questo.
- Chi dovrebbe utilizzare questo certificato?
- Quale organizzazione dovrebbe essere considerata attendibile?
- Quale utente deve presentare questo certificato?
Il soggetto è probabilmente la parte più importante di un certificato. Il soggetto è destinato ad avere attributi definiti da X.500, che rappresentano chi o cosa è stato emesso il certificato. È rappresentato in un formato di nome distintivo (DN).
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
I tipi di attributo e i formati dei valori sono definiti dalle raccomandazioni ITU-T X.520. Un riferimento aggiuntivo è RFC 4519 per raccomandazioni specifiche sui tipi di attributo e i formati dei valori.
Dato che gli standard dei certificati X509 non sono regole ma solo forti suggerimenti, molte persone usano il proprio giudizio quando definiscono un soggetto. Il soggetto dovrebbe identificare specificamente l’entità finale di cui ci si fida. Se il soggetto non rappresenta questo, come si può fidarsi di qualunque cosa utilizzi la chiave pubblica presentata?
In altre parole, se si consente a più persone di utilizzare lo stesso nome utente per accedere a un sistema, non si può attribuire responsabilità specifiche alle azioni di nessuna persona in particolare. Questa pratica complica il modello di fiducia che i certificati sono destinati a seguire.
Puoi vedere un esempio di come Windows rappresenta un certificato X509 e più specificamente il soggetto del certificato nella seguente schermata.
Visualizzazione degli attributi di un certificato con Cryptext.dll.
Nome alternativo soggetto (SAN)
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
Puoi vedere il SAN di seguito in questo esempio di certificato X509.
Alcuni degli attributi SAN associati al certificato di Google.
Comprensione della codifica
Utilizziamo molte lingue per comunicare tra di noi, allo stesso modo i computer hanno la propria lingua. Questa lingua è binaria e i diversi metodi di codifica ci permettono di rendere il binario più utilizzabile per gli altri, proprio come tradurremmo l’inglese in altre lingue.
La codifica ha uno scopo specifico. La codifica consente di memorizzare i valori delle estensioni leggibili dall’uomo in modo che anche i computer possano utilizzarli. I formati di codifica facilitano la memorizzazione e il trasferimento dei certificati X509 ma ci permettono anche di leggere i loro contenuti.
I computer sono bravi a lavorare con numeri interi, la codifica consente di convertire valori numerici in valori alfanumerici o addirittura in blocchi binari. Questa conversione è fondamentale per lavorare con i computer e i certificati si affidano alla codifica per trasmettere correttamente le informazioni ai computer. I formati di codifica definiscono gli standard per eseguire tali conversioni.
- ASN.1 – Lo standard Notazione di sintassi astratta uno è il formato di serializzazione per ciascuno dei campi all’interno dei certificati.
- ASCII – Il Codice Standard Americano per lo Scambio di Informazioni (ASCII) definisce un valore binario per ciascuno dei caratteri di controllo del computer e dei caratteri stampabili utilizzati per la maggior parte delle comunicazioni leggibili dall’uomo.
- Base64 – Base64 definisce uno schema per codificare contenuti binari all’interno dell’insieme di caratteri ASCII. Questi sono i certificati che è possibile aprire in un editor di testo e vedere “BEGIN CERTIFICATE” o altro testo di riferimento.
- DER – Le Regole di Codifica Distinte (DER) definiscono un altro schema di codifica specifico per i dati ASN.1 come ottetti sequenziali. L’importante considerazione con DER è che l’output codificato non è visualizzabile come ASCII.
Puoi vedere di seguito le differenze negli schemi di codifica. Nota che il file certificate.crt visualizzato per primo ha una -------INIZIO CERTIFICATO-------, seguito da una serie di lettere e numeri casuali e termina con -------FINE CERTIFICATO-------. Tutti i caratteri sono leggibili dall’uomo. Il primo certificato è codificato in Base64.
Ora guarda il secondo esempio del file certificate.cer. Il contenuto di questo file è molto diverso dal certificato Base64. Questo certificato X509 è codificato in DER.
Differenza tra file codificati in Base64 e DER.
Comprensione dei Tipi di File di Certificato X509
Ricorda che un certificato non è altro che una chiave pubblica con alcune informazioni rappresentate come file. Troverai molti tipi diversi di file che rappresentano molti tipi diversi di certificati. Ogni tipo di file è differenziato dalla sua estensione. Quando ci riferiamo a un file KEY, ad esempio, ci riferiamo alla sua estensione di file.
Di seguito troverai tutti i tipi comuni di certificati definiti dalla loro estensione di file con cui potresti lavorare e il loro scopo.
Nell’elenco sottostante, noterai vari riferimenti a PKCS. PKCS o Public Key Cryptography Standards è un insieme di standard per definire come vengono creati vari certificati. Per ulteriori informazioni, consulta questo informativo articolo di Wikipedia.
- PFX – Questi si trovano più comunemente in un ambiente Windows, ma sono un formato standard indipendentemente dal sistema operativo. I file PFX contengono un certificato, la chiave pubblica e le estensioni e una chiave privata criptata con una password. PFX è definito dallo standard PKCS #12.
- P12 – Come PFX, P12 è definito dallo standard PKCS #12. Formalmente, PKCS #12 è il successore del formato PFX, anche se entrambi i tipi di file rappresentano lo stesso formato nelle implementazioni crittografiche moderne.
- P7B – Un contenitore di certificati ASN.1, specificamente chiavi pubbliche per tutti i livelli di una catena di autorità di certificazione come apprenderai di seguito. Un file PKCS #7 fornisce un singolo file per distribuire più chiavi pubbliche, spesso utilizzato per configurare manualmente una fiducia con le CA in una PKI privata.
- P7C – Il tipo di file P7C è funzionalmente identico a P7B, ma è semplicemente un’altra estensione comune utilizzata per rappresentare un file PKCS #7.
- DER – Un file DER è una chiave pubblica codificata in formato DER.
- CER – Una chiave pubblica può essere codificata in formato DER o Base64. Un file CER è solitamente codificato in formato DER.
- CRT – Un file CRT è solitamente codificato in formato Base64, ma non ci sono garanzie.
- KEY – Un file KEY è spesso una chiave privata codificata in formato Base64, sia criptata che non criptata.
- PEM – Un riferimento a un certificato codificato in formato Base64, anche se è possibile che un singolo file PEM contenga più chiavi, solitamente si assume che il file PEM contenga una chiave privata. Più comunemente utilizzato per un file di chiave privata PEM codificato in formato Base64, sia criptato che non criptato.
- CSR – Utilizzato per inviare una chiave pubblica a un CA per essere firmata e dotata di campi aggiuntivi come un numero di serie. In genere, un file CSR contiene la struttura ASN.1 della richiesta codificata in formato Base64.
- REQ – Utilizzato in Windows per specificare le impostazioni di policy di registrazione utilizzate durante la generazione della CSR.
- CRL – Un file CRL è un elenco specifico dei certificati revocati da un CA, il loro stato di revoca e il motivo della revoca.
Infrastruttura a Chiave Pubblica (PKI): L’Ecosistema dei Certificati X509
Ricorda quando qualcuno aveva la chiave della serratura di una porta. In quel caso, avevi solo una singola porta. Ma cosa succede quando ti trovi improvvisamente come proprietario di decine o centinaia di appartamenti? Gestire tutte quelle chiavi diventerà complicato!
Inoltre, gli inquilini non rimarranno in quell’appartamento per sempre. Ci saranno persone che terranno la chiave o ne faranno copie non autorizzate. Dovrai cambiare le serrature per impedire l’accesso. Non ti fidi più degli ex inquilini.
Se devi gestire centinaia di appartamenti con inquilini che entrano e escono costantemente, come fai a gestire tutto questo? La risposta è un’infrastruttura a chiave pubblica (PKI).
PKI è un intero ecosistema di ruoli, politiche e procedure costruito attorno alla gestione delle chiavi pubbliche. PKI rappresenta un insieme completo di molte diverse aree di focus per distribuire, utilizzare, gestire ed eliminare certificati X509. È essenzialmente tutto ciò che serve per gestire e gestire correttamente i certificati su larga scala.
Nelle prossime sezioni, analizzeremo molti dei componenti più comuni di una PKI e spiegheremo il ruolo di ciascun componente.
Autorità di Certificazione (CA): I tuoi genitori
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
Hai bisogno di una terza parte che sia già stata garantita dalla parte originale. Questi intermediari di terze parti sono chiamati autorità di certificazione (CA) identificate da un’estensione di identificatori di chiavi di autorità (AKI) derivata dalla chiave pubblica utilizzata per firmare il certificato dato.
Immaginati come un bambino come un certificato X509. Probabilmente ti è stato insegnato dai tuoi genitori di non fidarti degli estranei. Ma cosa succede se i tuoi genitori (quelli di cui ti fidi) ti presentano uno sconosciuto e ti dicono che è sicuro fidarsi di lui? Probabilmente accetteresti e ti fideresti di quella persona. Dopotutto, se i tuoi genitori si fidano di loro, anche tu puoi farlo.
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
Il ruolo principale di una CA è agire come un intermediario fidato.
Rilascio di certificati X509: Creazione di fiducia
Essendo una nota entità fidata, una CA permette la fiducia tra parti indirette. Per permettere la fiducia tra le parti, una CA “emette” certificati. Quando parliamo di emissione da parte di una CA, intendiamo che la CA sta convalidando le estensioni richieste e sta aggiungendo estensioni generate dalla CA per creare un certificato.
Quando una CA emette un certificato X509, utilizzerà la propria chiave privata per firmare digitalmente la chiave pubblica del certificato. Attraverso il processo di firma, una CA sta contrassegnando il certificato in modo da informare tutti che si fida di questa chiave pubblica. DocuSign fornisce una buona panoramica di questo concetto specifico con un buon diagramma.
Un altro esempio di estensione generata dalla CA è il numero seriale per ogni certificato, e ogni numero seriale deve essere univoco per quella determinata CA secondo le specifiche di progettazione RFC.
Un esempio di fiducia non intenzionale nelle notizie moderne è l’uso malevolo delle PKI con malware. Gli autori ricevono certificati validi che sono implicitamente fidati dalla maggior parte dei sistemi, rendendo più difficile per i vostri sistemi identificare i binari di malware come maligni.
Revoca dei certificati X509: Rimozione della fiducia
La CA è anche responsabile della revoca dei certificati X509 che non devono più essere fidati. Queste revocazioni vengono pubblicate dalla CA in una lista di revoca dei certificati (CRL). La revoca è un modo per le CA di invalidare attivamente un certificato, anziché attendere che la durata di validità scada.
La fiducia è un componente critico affinché i certificati funzionino come previsto. I punti di distribuzione aiutano a garantire la fiducia fornendo un punto di riferimento da cui è possibile scaricare il certificato e le liste di revoca emesse dall’autorità di certificazione, e confrontarle con il certificato in uso.
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
Anche se la validazione della revoca tramite CRL o OCSP è disponibile, deve essere implementata e supportata dal client, e ciò non è sempre il caso.
Gerarchizzazione
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
Concatenazione dei certificati X509
Come avete appreso in precedenza, la fiducia è un punto focale importante nell’uso dei certificati. Le parti coinvolte devono essere in grado di fidarsi o convalidare un certificato emesso da una CA fidata.
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
Firma dei certificati X509
Spesso si sente parlare del concetto di firma di un certificato, ma cosa significa esattamente? Come hai già appreso, i certificati riguardano tutti la fiducia. Per stabilire la fiducia, un certificato X509 viene firmato da una CA. Firmare un certificato assegna un hash crittografico unico a un certificato, comunicando a tutte le parti che lo leggono che possono fidarsi di esso. È stato firmato da una CA fidata.
In una gerarchia PKI, i certificati vengono firmati dalle CA, ma l’uso di quei certificati dipende dal tipo di CA che li firma.
Quando c’è una singola CA in una PKI, quella CA è la radice. Poiché non esiste un’altra CA, quella CA deve generare il proprio certificato autofirmato. Quella CA emette quindi certificati firmati dal proprio certificato.
Se una PKI ha più di una CA, tutte le CA vengono firmate da una CA radice o da una CA intermedia che risale alla CA radice.
Tipicamente, quando un dispositivo utilizza la stessa chiave privata che corrisponde alla chiave pubblica durante la generazione di un certificato X509, questo è conosciuto come un certificato autofirmato. Tuttavia, è anche possibile richiedere a una CA di utilizzare la propria chiave privata per firmare il certificato.
Algoritmi di firma
Gli algoritmi di firma si concentrano sulla validazione dell’autenticità di un messaggio da un peer remoto. Una firma digitale è un digest del messaggio ottenuto da una funzione di hash criptografico, cifrato con la chiave privata del mittente. Il destinatario decifra la firma digitale utilizzando una copia della chiave pubblica del mittente. Il destinatario può quindi confrontare il digest del messaggio ricevuto con quello decifrato dalla firma digitale. Quando i digest corrispondono, l’autenticità del messaggio è valida.
La crittografia asimmetrica è la capacità di generare testo cifrato senza l’uso di un segreto precedentemente noto. La combinazione di un algoritmo di scambio chiave con un algoritmo di firma è alla base della crittografia asimmetrica.
Di seguito sono riportati gli algoritmi principali utilizzati per le firme digitali.
- Rivest–Shamir–Adleman (RSA)
- Algoritmo di firma digitale (DSA)
- DSA a curva ellittica (ECDSA)
Richieste di firma del certificato (CSR)
Le CA emettono richieste di firma del certificato (CSR) che consentono ai client di inviare chiavi pubbliche alle CA per l’emissione. Una CA accetta una CSR e rilascerà certificati X509 firmati in base alle politiche di emissione configurate. Ciò significa che ogni CA di cui ti fidi implica anche fiducia per le chiavi pubbliche che firma.
Funzionamento degli hash
Gli hash sono un argomento complesso e non cercherò nemmeno di spiegarlo in modo esaustivo in questo post. Il team di Computerphile ha una buona panoramica sul loro canale YouTube. L’hashing si concentra su un oggetto di input e crea un hash di output unico per quell’input unico. L’hash di output è noto come digest. Ciò significa che anche il minimo cambiamento all’oggetto di input creerà un digest diverso, unico e non correlato.
Le implementazioni moderne si concentrano sugli algoritmi Secure Hash Algorithm (SHA) 2. A titolo informativo, SHA 256, SHA 384 e SHA 512 sono noti come SHA 2.
Ecco una lista degli algoritmi di hashing comuni che vedrai.
- SHA 256
- SHA 384
- SHA 512
- Messaggio Digest (MD) 5
Politiche del Certificato
L’estensione delle politiche del certificato (CP) fornisce il riferimento all’organizzazione che gestisce la CA, documentando le loro politiche effettive per la PKI specificata e dovrebbe essere allineata come una Dichiarazione di Pratica di Certificazione (CPS) che fornisce la politica dell’organizzazione per la gestione della PKI specificata.
Punti di Distribuzione
Un altro tipo di punto di distribuzione identificato nei certificati sono gli Accessi alle Informazioni dell’Autorità (AIA). Questi AIA forniscono i protocolli e le posizioni per ottenere copie delle informazioni del certificato emittente, più comunemente significa la chiave pubblica della CA emittente.
Riepilogo
Si spera che ora, quando ti viene posta una domanda come all’inizio di questo articolo, ti sentirai più a tuo agio nel alzare la mano, lentamente. Onestamente, speriamo che questo articolo ti abbia aiutato a comprendere le complessità dei certificati X509 e dell’implementazione di Windows di questi standard. Ti aiuterà anche a capire alcuni dei componenti di base che ti saranno utili in futuro nel lavorare con i certificati.
Almeno ora, quando qualcuno chiede una chiave pubblica del tuo certificato, puoi confermare che vogliono sia la codifica DER che la codifica Base64, e non lo sapranno quindi invierai comunque entrambe.