Security

SSL Checker

Ispeziona catena certificati, scadenza e algoritmo.

Hostname host or host:port (default 443)

Try: github.com cloudflare.com example.com badssl.com

Informazioni su questo strumento

SSL Checker apre una vera connessione TLS al tuo host, cattura la catena di certificati che il server presenta e riporta tutto ciò che conta: subject, issuer, date di validità, l'intera catena intermedia fino al trust anchor, algoritmo di firma, dimensione della chiave pubblica, versioni TLS e cipher suite supportate, Subject Alternative Names e stato dell'OCSP stapling. Il controllo avviene lato server dal nostro host di Francoforte così vedi esattamente ciò che vede un visitatore remoto — non ciò che il tuo browser ha nella cache.

Un certificato pulito non è solo "il lucchetto verde". Validiamo la corrispondenza dell'hostname con i SAN (il campo legacy CN è solo informativo, secondo RFC 6125), verifichiamo che ogni anello della catena sia firmato dal successivo, verifichiamo che gli intermediari siano presentati nell'ordine corretto (un errore di deploy comune), confermiamo che il leaf non sia scaduto e non sia ancora non valido, e avvisiamo se il leaf usa una firma debole (SHA-1) o una chiave sottodimensionata (RSA < 2048 bit). Tutto questo in un singolo handshake HTTPS.

Quando usare questo strumento

Verifica pre-deploy. Dopo aver effettuato il provisioning di Let's Encrypt o acquistato un certificato commerciale, conferma che la catena sia completa prima di indirizzarci utenti reali.
Monitoraggio della scadenza. Individua i certificati che scadranno nei prossimi 7/14/30 giorni e rinnova prima che scattino gli allarmi.
Debug di contenuti misti. Trova sottodomini che presentano un certificato diverso (o self-signed) rispetto al sito principale.
Sanity check post-migrazione. Dopo essere passati a una nuova CDN o a un nuovo load balancer, verifica che il nuovo certificato e la catena siano quelli che ti aspetti.

Cosa significa davvero "catena incompleta"

I browser e i trust store del sistema operativo includono qualche centinaio di root CA. Il tuo certificato leaf è firmato da un intermedio, che è firmato da un altro intermedio o direttamente da una root. Il server web deve inviare il leaf + ogni intermedio fino a (ma escluso) il root — Firefox e Chrome proveranno a recuperare gli intermedi mancanti dall'estensione AIA, ma iOS, Android più vecchi e la maggior parte dei client TLS non-browser rifiuteranno l'handshake. Il nostro ispettore della catena ti dice esattamente quale anello manca, così puoi incollare il giusto intermedio nella configurazione del server.

Domande frequenti

Il mio browser mostra il lucchetto ma il vostro strumento dice "catena incompleta" — chi ha ragione?

Entrambi. I moderni browser desktop rattoppano le catene incomplete recuperando gli intermedi mancanti tramite l'estensione AIA o dalle proprie cache — l'utente vede un lucchetto funzionante. Ma iOS Safari, molte app Android, curl, i client OpenSSL e le librerie TLS non-browser non lo fanno. Se il nostro strumento dice "incompleta" il tuo sito fallirà su una frazione non trascurabile di client; risolvi servendo la catena completa dal server.

Cos'è l'OCSP stapling?

Un modo per il server di allegare una recente prova di validità firmata dalla CA al certificato durante l'handshake TLS — così il browser non deve contattare il responder OCSP della CA a ogni connessione. Lo stapling rende i caricamenti delle pagine più veloci e protegge la privacy dell'utente (la CA non apprende mai quali siti l'utente sta visitando). La maggior parte dei moderni web server (nginx, Apache 2.4, Caddy) lo supporta; molti lo attivano per impostazione predefinita.

Quanto spesso dovrei controllare?

Una volta a settimana è più che sufficiente per la produzione. I certificati Let's Encrypt si rinnovano ogni 60–90 giorni, i certificati commerciali ogni 12 mesi; in entrambi i casi una scadenza non notata è la modalità di fallimento SSL più comune. Memorizziamo i risultati nella cache per 10 minuti così un rapido ricontrollo dopo un deploy fornisce feedback immediato. Abbina questo a un monitor automatizzato (Uptime Kuma, StatusCake) per avvisi proattivi.

Perché lo strumento non valida contro la mia CA privata?

Usiamo il bundle di trust standard delle CA pubbliche (quello di Mozilla, che usano anche la maggior parte dei sistemi operativi). Le CA private — root aziendali interne, ACME-CA su un homelab — non sono in nessun trust store pubblico, quindi la validazione della catena (correttamente) le segnalerà come non attendibili. I dettagli del certificato (subject, date, dimensione della chiave) sono comunque riportati; fallisce solo il controllo del trust anchor.