Struttura dei certificati X.509

Un certificato X.509 è un documento digitale standardizzato che associa una chiave pubblica a un'identità. Lo standard X.509 (definito nella RFC 5280) specifica il formato, i campi e le estensioni utilizzati nei certificati digitali in tutto il mondo. Ogni certificato TLS/HTTPS, certificato e-mail S/MIME, certificato per la firma del codice e certificato per l'autenticazione client segue il formato X.509. Comprendere la struttura di un certificato X.509 La aiuta a leggere le informazioni del certificato, diagnosticare gli errori dei certificati e prendere decisioni consapevoli sulla distribuzione e sulla convalida dei certificati.

I primi campi di un certificato X.509 ne definiscono l'identità di base. Versione: X.509 v3 è lo standard attuale (la v3 ha aggiunto le estensioni). Numero di serie: un numero intero univoco assegnato dalla CA emittente che identifica questo specifico certificato; viene utilizzato nelle CRL (liste di revoca) per revocare singoli certificati. Algoritmo di firma: specifica l'algoritmo utilizzato dalla CA per firmare il certificato (ad esempio, sha256WithRSAEncryption o ecdsa-with-SHA256). Questo campo compare due volte: una volta nel TBSCertificate e una volta nel wrapper della firma esterna; i due valori devono coincidere.

Due dei campi più importanti di un certificato identificano le parti coinvolte. Il campo Issuer identifica la CA che ha firmato il certificato (ad esempio, CN=DigiCert Global CA G2, O=DigiCert Inc, C=US). Il campo Subject identifica l'entità a cui è stato rilasciato il certificato (ad esempio, CN=*.example.com, O=Example Corp, C=US). In un certificato TLS, il Common Name (CN) del Subject o l'estensione Subject Alternative Name (SAN) specifica per quali nomi di dominio è valido il certificato. I browser confrontano il nome host richiesto con questi campi.

Il periodo di validità definisce quando il certificato è attivo. È composto da due timestamp: notBefore (prima di questa data il certificato non è ancora valido) e notAfter (dopo questa data il certificato è scaduto). I client TLS verificano che l'ora corrente rientri in questo intervallo. I certificati presentati al di fuori del periodo di validità causano un errore del certificato nei browser e devono essere rinnovati. La pratica moderna raccomandata consiste nell'emettere certificati a breve durata (90 giorni, come fa Let's Encrypt) per limitare l'esposizione nel caso in cui una chiave privata venga compromessa tra l'emissione e la scadenza.

Il contenuto principale del certificato è il campo Subject Public Key Info, che contiene la chiave pubblica certificata e specifica l'algoritmo con cui viene utilizzata. In un certificato RSA, questo campo contiene il modulo e l'esponente della chiave pubblica RSA, insieme alla relativa lunghezza in bit (2048, 4096). In un certificato ECC, contiene il nome della curva (ad esempio, prime256v1) e il punto della chiave pubblica. La CA non genera questa coppia di chiavi: il richiedente del certificato genera la propria coppia di chiavi e invia solo la chiave pubblica in una Certificate Signing Request (CSR).

X.509 v3 ha introdotto le estensioni, che ampliano notevolmente le funzionalità dei certificati. Le estensioni possono essere critical (un client che non è in grado di elaborarle deve rifiutare il certificato) oppure non-critical (possono essere ignorate se non vengono comprese). Le estensioni principali includono: Subject Alternative Name (SAN) — ulteriori nomi di dominio o indirizzi IP coperti dal certificato; Key Usage — limita le operazioni per cui è possibile utilizzare la chiave (firma digitale, cifratura delle chiavi); Extended Key Usage — limita ulteriormente lo scopo (autenticazione del server TLS, autenticazione del client, firma del codice); e Basic Constraints — indica se il Subject è una CA.

Storicamente, il campo Common Name (CN) nel campo Subject distinguished veniva utilizzato per il nome di dominio principale. I certificati moderni utilizzano invece i Subject Alternative Names (SAN), poiché i browser hanno deprecato la corrispondenza basata sul CN (RFC 2818) a favore dei SAN. I SAN consentono a un singolo certificato di coprire più domini (certificati multi-SAN) o tutti i sottodomini di un dominio (certificati wildcard: *.example.com). I wildcard nei SAN coprono un solo livello: *.example.com copre www.example.com, ma non sub.www.example.com.

Due estensioni fondamentali indicano ai client come verificare se un certificato è stato revocato prima della data di scadenza. CRL Distribution Points (CDP): contiene gli URL da cui è possibile scaricare la Certificate Revocation List della CA. Authority Information Access (AIA): contiene l'URL del responder OCSP (Online Certificate Status Protocol) della CA per la verifica della revoca in tempo reale. I client moderni preferiscono OCSP al download delle CRL, perché le CRL possono essere file di grandi dimensioni. La firma digitale della CA sulle risposte OCSP garantisce che i client ricevano informazioni autentiche sullo stato di revoca.

I certificati X.509 sono disponibili in diversi formati di codifica che potrà incontrare nella pratica. PEM (Privacy Enhanced Mail): DER codificato in base64 e racchiuso nelle intestazioni -----BEGIN CERTIFICATE-----. È leggibile e viene utilizzato su Linux/Apache/nginx. DER (Distinguished Encoding Rules): formato binario. Viene utilizzato nelle applicazioni Java e in alcuni contesti Windows. PFX/PKCS#12: formato contenitore che riunisce certificato, catena e chiave privata in un unico file protetto da password. Viene utilizzato in Windows IIS e durante l'esportazione dei certificati insieme alle relative chiavi private. P7B/PKCS#7: contiene solo la catena di certificati, senza chiave privata, e viene utilizzato negli archivi certificati di Windows.

Certificate Transparency (CT) è un framework che impone alle CA di registrare tutti i certificati emessi in log verificabili pubblicamente. Ciò consente a chiunque di monitorare la presenza di certificati non autorizzati emessi per i propri domini. Chrome e Safari richiedono che i certificati TLS siano inclusi nei log CT. SCT (Signed Certificate Timestamp) è la prova dell'inclusione nel log, incorporata nel certificato o fornita tramite un'estensione TLS. I log CT rendono rapidamente visibili le emissioni errate: se una CA emette per errore un certificato per il Suo dominio, lo vedrà in log come crt.sh prima che gli aggressori possano abusarne.

L'ultimo componente di un certificato X.509 è la firma digitale della CA. La CA calcola l'hash di tutti i dati del certificato (TBSCertificate) e firma tale hash con la propria chiave privata. Questa firma è ciò che rende attendibile il certificato: chiunque può verificarla utilizzando la chiave pubblica della CA (presente nel certificato della CA stessa). L'algoritmo di firma utilizzato (elencato nel campo della firma) deve corrispondere a quello specificato in precedenza nel certificato. Qualsiasi modifica apportata al certificato dopo la firma invalida la firma stessa, garantendo l'integrità del certificato.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha appreso che un certificato X.509 contiene versione, numero di serie, issuer, subject, periodo di validità, chiave pubblica ed estensioni v3; l'estensione SAN controlla quali nomi host copre il certificato; le estensioni CDP e AIA indicano gli endpoint per la verifica della revoca; inoltre, i log CT forniscono registri di audit pubblici delle emissioni dei certificati. Nella prossima sezione esamineremo il ciclo di vita e la revoca dei certificati.