Loading AI tools
standard proposto dall'Unione internazionale delle telecomunicazioni Da Wikipedia, l'enciclopedia libera
X.509 è uno standard proposto dall'Unione internazionale delle telecomunicazioni (ITU-T), usato per definire il formato dei certificati a chiave pubblica (PKC) e delle autorità di certificazione (CA). I certificati vengono utilizzati per la validazione dell'identità e la trasmissione di dati criptati che solo il possessore (persona, organizzazione o applicazione) di uno specifico certificato è in grado di decifrare e leggere. Questi vengono rilasciati dalle Certificate authority (CA), un soggetto terzo fidato che assicura la corrispondenza di una chiave pubblica a una determinata identità. Uno degli usi più diffusi di X.509 è nell'ambito internet, il certificato SSL/TLS viene usato nell'omonimo protocollo per criptare le comunicazioni tra un sito web e il nostro browser.
Lo standard inoltre definisce sotto diversi aspetti l'utilizzo dei certificati nelle infrastrutture a chiave pubblica (PKI) e nei Privilege Management Infrastructure (PMI). Oltre al certificato a chiave pubblica e ai certificati di attributi vengono descritti anche i seguenti tipi di dato: certificate revocation list (CRL) e attribute certificate revocation list (ACRL).[1]
Le certificate revocation list (CRL) contengono la lista dei certificati che sono stati revocati dall'autorità rilasciante. Le CRL vengono consultate per assicurarsi la validità e affidabilità dei certificati che si stanno per utilizzare. Operazione svolta dal browser ogni volta che ci si collega a un sito tramite SSL/TLS.
L'ITU-T X.509 venne presentato per la prima volta nel 1988 come parte dello standard X.500, insieme di raccomandazioni per un servizio di directory. Il formato dei certificati definito nel 1988 costituisce la versione uno(v1). Questo presupponeva uno stretto sistema di gerarchie di certificate authority (CA) per garantire la legittimità di un certificato. In contrasto con il modello della rete di fiducia (web of trust), utilizzato da PGP, dove chiunque, non solo i CA, può firmare e quindi attestare (certificare) la corrispondenza tra una chiave pubblica e il soggetto a cui essa appartiene.
Lo standard fu rivisitato nel 1993 con l'aggiunta del supporto di due nuovi attributi nel certificato, questa estensione costituisce la versione due (v2). Nello stesso anno con l'Internet Privacy Enhanced Mail (PEM) [rfc-1422] veniva proposta un'infrastruttura a chiave pubblica basata su X.509 versione uno(v1). L'esperienza fin qui acquisita fece emergere l'esigenza di un'ulteriore estensione, per rendere più dettagliati i certificati e favorirne l'interoperabilità sotto sistemi con profili diversi, come Internet. Nel 1996 fu quindi completata la versione tre (v3), dalla collaborazione d'ISO/IEC, ITU-T, e ANSI X9. La versione tre(v3) di X.509 permette una maggiore flessibilità nelle strutture di creazione dei certificati X.509, con possibilità di usare topologie di PKI in stile mesh o bridge [rfc-4158], anche in una rete di fiducia peer-to-peer come quella di Open-PGP, raramente però è implementata in questo modo. Questo aiuto a superare la rigida struttura gerarchica dei PKI.
Il sistema X.500 non è mai stato totalmente completato, e l'IETF e i public-key infrastructure working group (PKIX) hanno adattato lo standard con una struttura più flessibile adatta a Internet. Infatti il termine certificato X.509 si riferisce generalmente al profilo dei certificati e delle liste di revoca dei certificati (CRL, da Certificate Revocation List) dell'IETF basato su standard X.509 v3, come descritto nella RFC 5280.
Nel sistema X.509, una Certification Authority (CA) rilascia un certificato che accoppia una chiave pubblica a un nome univoco, oppure a un'entità come potrebbe essere un indirizzo e-mail o un record DNS. L'autenticità di un certificato e dell'autorità di certificazione dipendono dal root certificate. I root certificate sono implicitamente fidati. Uno degli esempi di software distribuiti con root certificate preinstallati sono i browser, rendendo possibile il funzionamento dei certificati SSL/TLS.[2]
La versione tre (v3) dei certificati digitali X.509 ha tre voci principali: il certificato, l'identificativo dell'algoritmo di firma del certificato e la firma del certificato. Il certificato viene descritto attraverso una serie di attributi come la versione, l'ID dell'algoritmo, il numero seriale, l'emittente, il richiedente, la validità, informazioni sulla chiave pubblica del richiedente, estensioni e altre voci facoltative. Le informazioni sulla chiave pubblica del richiedente sono poi ulteriormente dettagliate con l'algoritmo utilizzato e la chiave pubblica stessa, mentre la validità viene indicata tramite la data d'inizio e quella di fine, che eventualmente determina il periodo di vita del certificato.
I codici identificativi univoci dell'emettitore e del richiedente sono stati introdotti nella versione due(v2), per poter permettere il loro riutilizzo in altri certificati. Per esempio se una Certification Authority (CA) fallisce e non è più autorizzata ad esercitare. In seguito un'altra CA con lo stesso nome, potrebbe registrarsi nella lista pubblica delle CA, anche se non ha nessuna relazione con la prima CA. Tuttavia la IETF raccomanda di non riutilizzare lo stesso nome. Perciò la versione due(v2) non ha avuto un ampio utilizzo in Internet.
Le estensioni sono state introdotte nella versione tre (v3). Una CA può usare le estensioni solo per certificati che hanno uno specifico uso, come la firma di oggetti digitali. Ogni estensione del certificato ha un proprio identificativo, espresso come object identifier (OID), un insieme di valori che possono essere critici o non critici. Se analizzando un certificato un sistema incontra un'estensione critica che non riconosce, il certificato viene rigettato. Un'estensione non critica può essere ignorata se non riconosciuta, ma altrimenti deve essere processata. L'RFC 5280 definisce, nella sezione 4.2[3], delle estensioni in uso nelle Internet PKI. Ulteriori estensioni possono essere utilizzate, ma si deve fare attenzione nell'includere estensioni critiche, poiché potrebbero compromettere l'interoperabilità del certificato.
In tutte le versioni, il numero seriale deve essere univoco per ogni certificato emesso da una specifica Certification Authority(CA).
Estensioni comuni per i file contenenti i certificati X.509:
.pem
- Privacy-Enhanced Mail, è un certificato codificato con Base64, racchiuso tra "-----BEGIN CERTIFICATE-----" e "-----END CERTIFICATE-----";.cer
, .crt
, .der
- certificato codificato con DER, a volte sequenze di certificati;.p7b
, .p7c
– struttura SignedData PKCS#7 senza dati, solo il/i certificato/i o la/le CRL (Certificate revocation list);.pfx
, .P12
- PKCS#12, può contenere certificati e chiavi pubbliche e private (protette da password);PKCS #7 è uno standard per la firma o la crittazione (viene chiamata "imbustamento", "incapsulazione", "enveloping" in inglese) dei dati. Poiché è necessario un certificato per verificare i dati firmati, è possibile includerli in una struttura SignedData. Un file .p7c
non è altro che una struttura SignedData "degenere" (senza dati firmati).
PKCS #12 è nato dallo standard PFX (Personal inFormation eXchange) ed è usato per scambiarsi oggetti pubblici e privati all'interno dello stesso file.
Un file .pem
può essere utilizzato oltre che per i certificati anche per le chiavi private, racchiusi tra le apposite linee BEGIN/END.
Una persona/entità può richiedere di certificare la propria chiave pubblica inviando un Certificate Signing Request (CSR) a una Certification Authority (CA). Per prima cosa si genera una coppia di chiavi (privata/pubblica). La chiave privata viene tenuta segreta e viene utilizzata per firmare il CSR. La richiesta contiene tutte le informazioni necessarie per validare l'identità del richiedente, oltre alla chiave pubblica. In seguito alle verifiche il certificato viene firmato digitalmente dalla CA per evitare ulteriori modifiche. A questo punto la CA pubblica il certificato affinché altri lo possano trovare.
Esistono differenti tipi di entità definite in X.509:
Lo standard X.509 definisce il formato e la semantica delle certificate revocation list (CRL), liste di revoca di certificati, per le PKI. Ogni oggetto della Certificate Revocation List include il numero seriale del certificato revocato e la data di revoca. Anche i file delle CRL sono firmate dalla Certificate Authority per prevenire manomissioni. Possono essere aggiunte informazioni opzionali come un limite temporale se la revoca si applica solo per un periodo di tempo o la ragione della revoca.
Il problema con le CRL, come con tutte le blacklist, è la difficoltà di manutenerle e sono un modo inefficiente di distribuire informazioni critiche in sistema real-time. Tutto dipende dalla frequenza di aggiornamento delle CRL, anche se ad esempio sono aggiornate ogni ora, un certificato revocato potrebbe ancora essere accettato. Inoltre se una CRL non è disponibile, qualsiasi servizio si basi su questa non è utilizzabile.
Il protocollo Online Certificate Status Protocol (OCSP) è un'alternativa alle CRL, questo manda il certificato alle CA per essere verificato direttamente da loro, modalità utilizzata dai browser. Utilizzando meno traffico dati per effettuare la verifica.[4]
Un servizio che utilizza i certificati X.509, richiede la conoscenza di una chiave pubblica, prima di usare il certificato che la contiene questo deve essere validato. Se il servizio non ha già una copia valida della chiave pubblica del CA che ha firmato il certificato, il nome della CA, e le relative informazioni (come il periodo di validità), si ha bisogno di ulteriori certificati per ottenere quella chiave pubblica. In generale, si ha bisogno di una lista di certificati, incluso il certificato del proprietario della chiave pubblica (end-entity certificate) firmato da una CA, seguito da uno o più certificati di CA firmati da altre CA. Queste catene di certificati (chiamate anche certification paths[3]) sono necessarie poiché i software di solito sono inizializzati con un limitato numero di chiavi pubbliche di CA verificate.
Una catena di certificati ha le seguenti proprietà:
Possiamo distinguere tra un certificato emesso per le CA e quelli emessi per gli end-entity (per esempio utenti, dispositivi, server Web, processi) grazie all'estensione Basic Constraints[5]. Un certificato emesso per una CA sono chiamati cross-certificate. I cross-certificate vengono utilizzati sia in un modello con una struttura gerarchica, dove una CA più autorevole (cross-)certifica una CA subordinata, sia in un modello distribuito, dove diverse CA possono emettere certificati una per l'altra[6].
Tutti i certificati nella catena devono essere controllati. In generale, il processamento di una catena di certificati avviene in due fasi:
Esaminando come una catena di certificati viene costruita e validata, si nota che un certificato può fare parte di diverse catene di certificati, al più tutte valide. Questo grazie ai cross-certificate. Si possono infatti generare più certificati per una CA con lo stesso soggetto e chiave pubblica, ma essere firmati con diverse chiavi private, da diverse CA. Quindi, nonostante un singolo certificato X.509 possa avere un solo ente emittente e una sola firma, questo può essere collegato a più di un certificato in maniera valida. Questo è un aspetto cruciale per (cross-)certificare molteplici PKI e diverse applicazioni.
Nel diagramma, ogni rettangolo rappresenta un certificato, con il soggetto in grassetto. A → B significa "A è stato firmato da B" (più precisamente, "A è stato firmato dalla chiave privata corrispondente alla chiave pubblica nel certificato B"). I certificati con lo stesso colore (ad eccezione di quelli trasparenti) contengono la stessa chiave pubblica.
Per assicurarsi ad esempio che gli end-entity certificate in PKI.2, come il cert.2.2, siano verificabili tramite PKI.1, la CA.1 genera un certificato contenente la chiave pubblica di CA.2, in questo caso cert.2.1. Adesso sia cert.2 sia cert.2.1 in verde hanno lo stesso soggetto e chiave pubblica. In questo modo ci sono due catene valide per cert.2.2 (User.2):
In maniera simili, la CA.2 può generare un certificato che contiene la chiave pubblica di CA.1 (cert.1.1), in modo che i certificati all'interno di PKI.1 siano riconosciuti da PKI.2.
Ci sono numerose pubblicazioni sui problemi delle PKI da parte di Bruce Schneier, Peter Gutmann e altri esperti di sicurezza.[7][8][9]
«So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.»
La sicurezza di una firma digitale si basa su una funzione crittografica di hash. Nel momento in cui una PKI autorizza l'uso di una funzione di hash non più sicura, questa può essere sfruttata per compromettere i certificati. Più precisamente, se qualcuno riesce a produrre una collisione per una funzione di hash, dove il hash di un certificato è identico a un altro hash, di un certificato il cui contenuto è stato creato da un cracker. In seguito il cracker aggiunge la firma fornita dalla CA al proprio certificato, che risulta legittimamente firmato da un CA. Essendo il contenuto scelto dal cracker, ad esempio questo può estendere la validità di hostname oltre il suo termine oppure può inserire il campo CA: true
abilitandosi all'emissione di altri certificati.
Lo sfruttamento delle collisioni nelle funzioni di hash per manomettere i certificati X.509 implicano che il cracker conosca a priori il contenuto del certificato firmato dalla CA. Questa possibilità può essere ridotta dalle CA stesse, introducendo un componente aleatorio nel certificato, tipicamente il numero seriale.
La CA/Browser Forum richiede l'utilizzo del numero seriale dal 2011, nelle sue Baseline Requirements.[16]
Dal 2016 inoltre le Baseline Requirements proibiscono l'emissione di certificati che fanno uso dell'algoritmo di hash SHA‐1. L'anno successivo i browser come Chrome, Firefox, Edge e Safari non accettavano più certificati firmati con SHA-1.[17][18][19][20] Ci sono però numerosi software non-browser che accettano ancora i certificati SHA-1.[21]
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.