A cosa serve questo strumento?
Lo SSL Certificate Checker risponde a una domanda che il browser lascia senza risposta: questo certificato HTTPS è valido, di fiducia, corrisponde al dominio e quando scade? Un browser mostra «connessione sicura» oppure «la connessione non è privata», mai il perché.
Lo strumento apre una vera connessione TLS verso l'host, ispeziona il certificato del server e la catena presentata, poi rende un verdetto a stati distinti. Niente «sembra a posto». Una risposta.
La differenza con la barra degli indirizzi sta in un punto: il browser giudica la connessione così come lui la vede, dopo aver già rimediato dietro le quinte a una catena traballante. Lo strumento giudica la catena così come il server la serve davvero, come la vedrebbe curl, un server API remoto o uno smartphone. È questa visione onesta che smaschera i guasti fantasma.
Tre usi che tornano di continuo:
- Prima di un incidente: un certificato scade tra otto giorni, nessun avviso del browser, guasto totale alla scadenza. Lo vedi arrivare.
- Dopo un rilascio: il sito si apre da te, ma il webhook del partner restituisce un errore TLS. Catena incompleta, quasi sempre.
- In audit: chiave RSA da 1024 bit o firma SHA-1 dimenticata su un vecchio servizio interno. Il verdetto la segnala.
Come leggere il verdetto
Il verdetto sta in una parola colorata, e quella parola basta per decidere. Ecco come decifrarla.
| Verdetto | Colore | Cosa significa |
|---|---|---|
| Valido | verde | Di fiducia, corrisponde al dominio, catena completa, chiave e firma aggiornate. Niente da fare. |
| Scadenza imminente | arancione | Corretto oggi, ma la scadenza si avvicina o la crittografia è debole. Da correggere senza fretta. |
| Non valido | rosso | Scaduto, non ancora valido, nome host errato o catena non verificabile. Il browser mostrerà un errore. |
| Autofirmato | rosso distinto | Il certificato ha firmato se stesso. Nessuna fiducia pubblica. |
| Irraggiungibile | tecnico | Il server non ha risposto: timeout, rifiuto o IP bloccato. |
Sotto il verdetto, il dettaglio: data di scadenza e giorni rimanenti, catena presentata in ordine, elenco dei SAN, versione TLS, cipher, tipo e dimensione della chiave, algoritmo di firma. Abbastanza per diagnosticare, non solo constatare.
Un caso merita che ci si soffermi. Non valido non significa sempre «certificato marcio». Quando l'unica anomalia è una catena servita incompleta, il messaggio passa a una diagnosi precisa: servi il fullchain. Il certificato è buono; è la sua consegna che non va.
I casi concreti che lo strumento smaschera
Catena incompleta: il server presenta solo il certificato del server
È il grande classico. Il server invia il suo certificato del server, ma dimentica l'intermedio che lo collega alla radice. Risultato: la catena non risale ad alcuna autorità riconosciuta, così com'è servita.
Chrome ed Edge se la cavano: scaricano l'intermedio mancante da soli (AIA fetching). Il sito «funziona da te». Ma curl fallisce, il client di posta fallisce, l'app mobile fallisce, la libreria HTTP del partner fallisce. Un inferno da diagnosticare senza uno strumento dedicato, perché il sintomo dipende da chi guarda.
La correzione è unica e senza sorprese: servire il fullchain, cioè il certificato del server seguito dall'intermedio o dagli intermedi, concatenati nell'ordine giusto. Let's Encrypt ti fornisce direttamente un file fullchain.pem pronto all'uso.
# Contare i certificati realmente serviti
openssl s_client -connect captaindns.com:443 -servername captaindns.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"
# 1 solo certificato = catena incompleta
Un caso particolare passa spesso per un bug dello strumento: il certificato del server servito da solo che si verifica lo stesso. Succede solo se quel certificato è stato emesso direttamente da una radice, cosa che il CA/Browser Forum ormai vieta. In pratica, un certificato pubblico servito da solo risulta non valido, e il consiglio è sempre lo stesso: fullchain.
Scadenza: il guasto che nessun browser annuncia
Un certificato che scade tra dieci giorni non attiva alcun avviso. Il giorno X, tutto crolla. HTTPS bloccato, API muta, webhook in errore e il supporto che va a fuoco.
Lo strumento mette la data di scadenza e i giorni rimanenti in cima al risultato. Sotto il mese, passa in avviso. Ma un'istantanea non previene: per questo serve una sorveglianza che gira in continuo (vedi più avanti).
Nome host: il dominio assente dai SAN
Il certificato è valido e di fiducia, ma non copre il nome richiesto. I browser ignorano il vecchio campo Common Name: leggono solo i SAN (Subject Alternative Names). Se il dominio non c'è, errore NET::ERR_CERT_COMMON_NAME_INVALID, qualunque cosa dica il CN.
La trappola più frequente è il wildcard. *.captaindns.com copre www.captaindns.com, ma non l'apex captaindns.com, né un livello più in basso come a.b.captaindns.com. Un wildcard scende solo di un gradino. La correzione: riemettere elencando tutti i nomi desiderati nei SAN.
Autofirmato: cifrato, ma senza fiducia
Un certificato autofirmato ha lo stesso emittente e lo stesso soggetto. Cifra la connessione, quindi i dati transitano al riparo. Ma nessuno garantisce a chi appartiene la chiave. Il browser rifiuta e mostra un avviso.
Perfetto per un servizio interno o un ambiente di test. Su un sito pubblico è un vicolo cieco: emetti piuttosto un certificato gratuito tramite Let's Encrypt e automatizzalo con ACME. Lo strumento isola questo caso in un verdetto a parte, per non confonderlo con un certificato guasto.
Crittografia debole: i fossili dimenticati
Una chiave RSA sotto i 2048 bit, una chiave ECDSA sotto i 256 bit, una firma SHA-1 o MD5: altrettante reliquie che si aggirano su vecchi servizi mai migrati. Il browser può tollerarle per un po', ma sono sul punto di essere respinte. Lo strumento le segnala sul certificato del server, prima che un irrigidimento lato client le faccia rifiutare da un giorno all'altro.
Automazione e sorveglianza: l'unica strategia sostenibile
Verificare a mano va bene per un incidente occasionale. Non regge nel tempo, e il calendario lo rende insostenibile.
Il CA/Browser Forum riduce la durata di vita dei certificati a tappe: 200 giorni a marzo 2026, 100 giorni nel 2027, 47 giorni nel 2029. A 47 giorni, rinnovare a mano diventa assurdo. Due riflessi si impongono.
Automatizzare l'emissione con ACME. Il protocollo ACME (quello di Let's Encrypt, tramite certbot, Caddy, Traefik, lego) rinnova e reinstalla il certificato senza intervento umano. Configurato una volta, poi dimenticato. È l'unico modo per stare al passo.
Sorvegliare la scadenza in continuo. L'automazione a volte fallisce in silenzio: quota di emissione raggiunta, DNS guasto per la validazione, hook di ricarica muto. Una sorveglianza che verifica la scadenza a intervalli regolari e avvisa in anticipo rimedia a questi buchi. L'HTTP Uptime Monitor di CaptainDNS svolge questo ruolo per i tuoi endpoint HTTPS.
Questo strumento e il monitor si rispondono: uno diagnostica all'istante, l'altro monta la guardia. Per approfondire il calendario e le sue conseguenze, leggi la nostra guida sulla riduzione della durata dei certificati a 47 giorni. E per passare dalla verifica puntuale a un approccio completo (inventario, automazione ACME, sorveglianza della scadenza), la nostra guida sulla gestione del ciclo di vita dei certificati illustra il metodo.
Solo web HTTPS
Questa versione copre il web HTTPS: connessione TLS implicita su host:porta, porta 443 per impostazione predefinita. La posta è fuori perimetro. Un server SMTP negozia in genere il TLS a posteriori, tramite STARTTLS, sulle porte 25, 587 o 465: un dial diretto non ci vedrebbe nulla.
Per il certificato di un server di posta, due strumenti prendono il relè: lo SMTP/MX Tester ispeziona il certificato presentato in STARTTLS, e il verificatore DANE/TLSA conferma che corrisponda all'impronta pubblicata nel DNS. Non mescolare i due mondi: un certificato web e un certificato MX non si verificano allo stesso modo.
FAQ - Domande frequenti
D: Come verificare un certificato SSL online?
R: Inserisci il nome di dominio nel campo host e avvia la verifica. Lo strumento apre una connessione TLS verso l'host e la porta (443 per impostazione predefinita), ispeziona il certificato del server e la catena presentata, poi restituisce un verdetto: validità, corrispondenza del nome host, fiducia di sistema, scadenza, robustezza della chiave e della firma.
D: Che differenza c'è tra certificato del server, intermedio e radice?
R: Il certificato del server porta il tuo nome di dominio. L'intermedio fa da collegamento tra questo e la radice. La radice (root CA) risiede nell'archivio di fiducia del sistema. Il server deve presentare il certificato del server seguito dagli intermedi; la radice non va inviata. Questa sequenza è il fullchain.
D: Perché il mio sito funziona in Chrome ma va in errore altrove?
R: È il sintomo di un intermedio mancante. Chrome ed Edge recuperano l'intermedio assente da soli (AIA fetching), ma curl, i client di posta e molti dispositivi mobili rifiutano la connessione. Servi la catena completa (fullchain) per correggere ovunque.
D: Per quanto tempo è valido un certificato SSL?
R: Oggi fino a 398 giorni, ma la durata si assottiglia. Il CA/Browser Forum impone 200 giorni a marzo 2026, 100 giorni nel 2027, 47 giorni nel 2029. Let's Encrypt emette già su 90 giorni. A questo ritmo, rinnovare a mano non regge più: bisogna automatizzare tramite ACME.
D: Come sorvegliare la scadenza di un certificato SSL?
R: Questo strumento fornisce un'istantanea. Per essere avvisato prima del guasto, collega una sorveglianza continua con l'HTTP Uptime Monitor: verifica la scadenza a intervalli regolari e avvisa all'avvicinarsi della scadenza.
D: Cosa significa un certificato autofirmato?
R: Il suo emittente e il suo soggetto sono identici: ha firmato se stesso. Cifra la connessione ma non offre alcuna fiducia pubblica, da cui l'avviso del browser. Va bene per un uso interno; per un sito pubblico, scegli un certificato emesso da un'autorità riconosciuta come Let's Encrypt.
D: Cosa fare se il nome host non corrisponde?
R: Il dominio richiesto non è nei SAN del certificato. Caso comune: un wildcard *.captaindns.com non copre né l'apex né un sotto-sottodominio. Riemetti il certificato con tutti i nomi desiderati nei SAN. Il Common Name non conta più: si leggono solo i SAN.
Strumenti complementari
| Strumento | Utilità |
|---|---|
| Parser CSR | Decodificare un CSR prima di sottoporlo alla tua autorità di certificazione |
| Verificatore DANE/TLSA | Confermare l'impronta del certificato di posta pubblicata nel DNS |
| Verificatore TLS-RPT | Ricevere rapporti sui fallimenti TLS dei tuoi server di posta |
| HTTP Uptime Monitor | Sorvegliare la disponibilità e la scadenza dei tuoi endpoint HTTPS |
Risorse utili
- RFC 5280 - Profilo dei certificati X.509 (struttura e validazione dei certificati)
- RFC 6125 - Verifica del nome host (corrispondenza SAN e wildcard)
- CA/Browser Forum - Baseline Requirements (regole di emissione e durata di vita)
- Documentazione Let's Encrypt - Certificati di catena (fullchain e intermedi)