# Decodifica e ispeziona certificati SSL/x509 nel browser

> Decodifica un certificato SSL/x509 in formato PEM direttamente nel browser: Subject, SAN, Issuer, scadenza, seriale, chiave pubblica e fingerprint SHA-256.

Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/decodifica-certificato-ssl

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. **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. **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. **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. **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** si calcola dall'esterno: è l'hash (SHA-256, o SHA-1 per compatibilità) dei 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

- **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. Decodifica il certificato e si ferma lì: la validazione è un lavoro a parte. 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.

---
Uno strumento di Maurizio Fonte, senior backend engineer. Tutti gli strumenti: https://www.mauriziofonte.it/strumenti/