Vai al contenuto
Certificati TLS/SSL

Decodifica e ispeziona certificati SSL/x509 nel browser

Incolla un certificato in formato PEM (-----BEGIN CERTIFICATE-----) e ottieni la lettura completa dei suoi campi x509: Subject (CN, O, OU), Subject Alternative Names, Issuer, finestra di validità con giorni alla scadenza, numero seriale, algoritmo di firma, tipo e dimensione della chiave pubblica, fingerprint SHA-256 e SHA-1. Tutto lato browser: il certificato non lascia mai la tua macchina e nessun server viene contattato.

Come decodificare un certificato

  1. 1

    Esporta il certificato in PEM

    Da terminale, per il certificato di un server: openssl s_client -connect esempio.it:443 -servername esempio.it < /dev/null | openssl x509. Da un file .crt, .cer o .pem, aprilo con un editor di testo: se inizia con -----BEGIN CERTIFICATE----- è già PEM. Da browser: clicca il lucchetto nella barra degli indirizzi, apri i dettagli del certificato ed esporta in formato Base64 (PEM).

  2. 2

    Incolla nel tool

    Incolla l'intero blocco, delimitatori -----BEGIN CERTIFICATE----- ed -----END CERTIFICATE----- compresi. Vengono accettati anche i soli caratteri base64 del DER: il tool li riconosce e li avvolge. Per ispezionare la catena completa, incolla i blocchi uno dopo l'altro e spunta "Analizza l'intera catena".

  3. 3

    Decodifica

    Il tool converte il PEM nei byte DER, cammina la struttura ASN.1 lato browser ed estrae Subject, Subject Alternative Names, Issuer, finestra di validità, numero seriale, algoritmo di firma, tipo e dimensione della chiave pubblica. I fingerprint SHA-256 e SHA-1 sono calcolati con l'API WebCrypto nativa sui byte DER dell'intero certificato.

  4. 4

    Leggi e verifica

    Controlla la scadenza (un badge segnala quando mancano meno di 30 giorni o quando il certificato è già scaduto), verifica che il dominio compaia nei SAN e non solo nel Common Name, confronta il fingerprint con quello atteso. Il bottone "Copia report" produce un riepilogo testuale pronto per un ticket, un runbook o la documentazione di deploy.

Cosa fa (e cosa non fa) un decoder di certificati

Un certificato x509 lega una chiave pubblica a un'identità. È il mattone su cui poggia TLS/HTTPS: quando il browser apre https://, il server presenta un certificato che dichiara "questa chiave pubblica appartiene a questo dominio", firmato da una Certificate Authority di cui il browser si fida. Il formato e le regole di validazione per la PKI di internet sono definiti nella RFC 5280. Un certificato contiene versione, numero seriale, algoritmo di firma, il Distinguished Name dell'emittente, la finestra di validità (Not Before / Not After), il Distinguished Name del soggetto, la chiave pubblica e una serie di estensioni (SAN, Key Usage, Basic Constraints e altre).

La catena di fiducia. Nessun browser si fida direttamente del certificato del tuo sito. Si fida di poche centinaia di root CA preinstallate nel proprio trust store. Il tuo certificato (il leaf, o end-entity) è firmato da una CA intermedia, che a sua volta è firmata dalla root. La validazione consiste nel costruire un percorso dal leaf fino a una root fidata: ogni anello deve essere firmato dal successivo. Se manca un intermedio (errore di deploy frequente) la catena si spezza e il browser rifiuta la connessione anche se il certificato del sito è perfetto. Per questo il tool permette di incollare l'intera catena e mostrare, cert per cert, chi firma chi.

Il SAN batte il Common Name. Storicamente il nome host stava nel campo Common Name (CN) del Subject. Dal 2017 i browser basati su Chromium, e a seguire tutti gli altri, ignorano completamente il CN per il matching del dominio: contano solo i Subject Alternative Names. Un certificato con CN=esempio.it ma senza esempio.it nei SAN dà ERR_CERT_COMMON_NAME_INVALID. Il CN oggi è cosmetico e spesso ripete il primo SAN. Quando decodifichi un certificato per capire perché un dominio non è coperto, guarda i SAN, non il CN.

Scadenza e rinnovo. La durata massima dei certificati TLS pubblici è scesa negli anni: dai vecchi 3 anni agli 825 giorni, fino ai 398 giorni imposti dai browser dal 2020. Il CA/Browser Forum ha inoltre approvato una riduzione progressiva fino a circa 47 giorni entro il 2029. La conseguenza pratica è che il rinnovo manuale non è più sostenibile: ci si affida ad ACME e a certificati a vita breve (Let's Encrypt emette a 90 giorni, rinnovati in automatico). Decodificare il certificato prima di un deploy, o durante un incidente, resta il modo più rapido per leggere la data esatta di Not After e sapere quanti giorni mancano.

PEM, DER e fingerprint. Un certificato è in sostanza una struttura ASN.1 codificata in DER (binario). Il PEM è quel binario in base64, avvolto fra i delimitatori BEGIN/END: testo ASCII copiabile ovunque. Estensioni come .crt e .cer possono contenere l'uno o l'altro. Il fingerprint non è un campo del certificato: è l'hash (SHA-256, o SHA-1 per compatibilità) calcolato sui byte DER dell'intero certificato, e serve a identificarlo in modo univoco, per esempio nel certificate pinning o per confrontare due copie.

Decodificare non è validare. Questo strumento legge e mostra ciò che il certificato dichiara; non verifica la firma della CA, non controlla la revoca (OCSP/CRL) e non conferma che la catena arrivi a una root fidata. Un certificato può decodificarsi senza errori ed essere comunque rifiutato dal browser perché scaduto, con hostname fuori dai SAN, self-signed o con un intermedio mancante. La decodifica ti dà i fatti; la fiducia è una valutazione separata che dipende dal trust store e dal contesto.

Privacy by design. Nessun upload, nessun fetch remoto. Il PEM viene convertito in DER, parsato e sottoposto a hashing interamente nel tuo browser via WebCrypto. Il dominio a cui il certificato appartiene non viene mai contattato dal nostro server. È lo strumento giusto per ispezionare certificati di sistemi interni, ambienti di staging non raggiungibili dall'esterno, dispositivi in intranet o certificati esportati da un HSM che non vuoi far uscire dalla tua rete.

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

x509 #
Standard ITU-T che definisce il formato dei certificati a chiave pubblica. Il profilo usato dalla PKI di internet (HTTPS, S/MIME, code signing) è specificato dalla RFC 5280. La versione corrente dei campi ed estensioni è la v3.
Common Name (CN) #
Attributo del Distinguished Name del Subject. In passato conteneva il nome host del sito; oggi i browser lo ignorano per il matching del dominio e usano solo i SAN. Resta un campo descrittivo, spesso una copia del primo SAN.
Subject Alternative Name (SAN) #
Estensione che elenca tutte le identità coperte dal certificato: nomi DNS (anche wildcard *.esempio.it), indirizzi IP, email, URI. È il campo autoritativo per stabilire quali domini un certificato è autorizzato a proteggere.
Issuer #
Distinguished Name della Certificate Authority che ha firmato il certificato. In un certificato self-signed l'Issuer coincide con il Subject. L'Issuer di un leaf deve corrispondere al Subject dell'intermedio che lo firma.
Certificate Authority (CA) #
Entità che emette e firma certificati. Le root CA sono preinstallate nei trust store di sistema operativo e browser; le CA intermedie firmano i certificati end-entity per tenere le chiavi radice offline e ridurre il rischio.
Fingerprint #
Hash crittografico (SHA-256 o SHA-1) calcolato sui byte DER dell'intero certificato. Non è memorizzato nel certificato: si ricalcola. Identifica in modo univoco una copia e viene usato nel certificate pinning e nei confronti manuali.
Chain of trust #
Sequenza leaf -> intermedio(i) -> root che il client percorre per validare un certificato. Ogni anello è firmato dal successivo; la catena è valida se termina in una root presente nel trust store. Un intermedio mancante la spezza.
PEM #
Privacy-Enhanced Mail: codifica testuale di dati DER in base64, racchiusa fra -----BEGIN CERTIFICATE----- ed -----END CERTIFICATE-----. Un file PEM può contenere più certificati concatenati (la catena).
DER #
Distinguished Encoding Rules: la codifica binaria canonica della struttura ASN.1 del certificato. Il PEM è semplicemente il DER in base64. I fingerprint e le firme si calcolano sempre sui byte DER, non sul testo PEM.
Serial number #
Intero che identifica il certificato in modo univoco presso il suo emittente. La RFC 5280 lo limita a 20 ottetti; le CA pubbliche devono includervi almeno 64 bit di entropia per prevenire attacchi di collisione sull'hash di firma.

Domande frequenti sul decoder di certificati

Il tool funziona offline?
Sì. Una volta caricata la pagina, la decodifica avviene interamente nel browser: parsing ASN.1/DER e calcolo dei fingerprint via WebCrypto, senza alcuna chiamata di rete. Puoi staccare la connessione e continuare a usarlo, o salvare la pagina per usarla su una macchina isolata.
I dati del certificato restano nel mio browser?
Sempre. Il certificato che incolli non viene inviato al nostro server né a terze parti: viene elaborato in locale e resta in memoria fino a quando pulisci il campo o chiudi la scheda. Un certificato pubblico non è un segreto, ma questo garantisce che anche certificati di sistemi interni o esportati da un HSM non escano dalla tua rete.
Che formati di certificato accetta (PEM, DER, base64)?
Accetta il PEM completo di delimitatori BEGIN/END CERTIFICATE e anche il solo base64 del DER, che il tool avvolge automaticamente. Il DER binario grezzo non è incollabile come testo: convertilo prima in PEM con openssl x509 -inform der -in cert.der -out cert.pem. Chiavi private e CSR non sono certificati e non vengono decodificate.
Qual è la differenza fra CN e SAN?
Il Common Name è un attributo del Subject che un tempo conteneva il nome host. Dal 2017 i browser lo ignorano per il matching del dominio e considerano solo i Subject Alternative Names. In pratica: un dominio è coperto solo se compare nei SAN. Se un certificato ha il tuo dominio nel CN ma non nei SAN, il browser lo rifiuta con ERR_CERT_COMMON_NAME_INVALID.
Come faccio a vedere quando scade il certificato?
La sezione Validità mostra Not Before e Not After in forma leggibile e i giorni residui alla scadenza. Un badge diventa giallo quando mancano meno di 30 giorni e rosso quando il certificato è già scaduto o non è ancora valido. Il valore autoritativo è la data di Not After espressa in UTC.
Posso incollare l'intera catena (leaf + intermedi + root)?
Sì. Incolla i blocchi PEM uno dopo l'altro e spunta "Analizza l'intera catena": il tool decodifica ogni certificato e li mostra in ordine, etichettando leaf, intermedi ed eventuale root self-signed. È utile per diagnosticare un intermedio mancante o fuori ordine, la causa più comune di errori di catena in produzione.
Cos'è il fingerprint e a cosa serve?
È l'hash SHA-256 (o SHA-1 per compatibilità) calcolato sui byte DER dell'intero certificato. Non è un campo memorizzato nel certificato: si ricalcola ogni volta. Serve a identificare in modo univoco una specifica copia, per esempio per confrontare il certificato servito con quello atteso, per il certificate pinning o per riconoscere due export dello stesso certificato.
Perché il mio certificato risulta "non valido" nel browser ma qui si decodifica senza errori?
Perché decodificare non è validare. Il tool legge i campi del certificato; il browser invece verifica la fiducia. Un certificato può essere ben formato e comunque venire rifiutato se è scaduto, se il dominio non è nei SAN, se è self-signed o emesso da una CA non fidata, se manca un intermedio nella catena o se è stato revocato. La decodifica ti dà i fatti per capire quale di questi casi si applica.
Il tool verifica la firma o controlla la revoca (OCSP/CRL)?
No. È un decoder, non un validatore. Non verifica crittograficamente la firma della CA, non interroga endpoint OCSP né scarica CRL, non costruisce il percorso fino a una root fidata. Per la validazione completa servono strumenti che contattano la rete e il trust store, per esempio openssl verify o i test di laboratori SSL online.
Che differenza c'è fra leaf, intermedio e root?
Il leaf (o end-entity) è il certificato del tuo sito o servizio, quello che presenta il nome host nei SAN. Gli intermedi sono certificati di CA che firmano i leaf e sono a loro volta firmati dalla root. La root è la CA autofirmata in cima alla catena, preinstallata nel trust store: non viene servita dal server perché il client la possiede già. Un deploy corretto invia leaf più intermedi, mai la root.

Chi sviluppa questi strumenti?

Maurizio Fonte, consulente IT senior con oltre 20 anni di esperienza in PHP, Laravel, infrastrutture Linux, cybersecurity e integrazione AI/LLM in azienda. Backend di produzione, modernizzazione di codice legacy, audit di sicurezza, agenti AI e MCP server custom: il lavoro che sta dietro a questi strumenti.

Conosci Maurizio Fonte