Security

SSL Checker

Ispeziona catena certificati, scadenza e algoritmo.

Hostname host or host:port (default 443)
example.com:443
TLSv1.3 expires in 34d
Verdict
  • Certificate is valid for this host and not expired.
Subject?
example.com
Issuer?
Cloudflare TLS Issuing ECC CA 3 — SSL Corporation
Valid from
2026-05-31T21:39:12Z
Valid to?
2026-08-29T21:41:26Z
Signature algorithm?
ecdsa-with-SHA256
Public key?
EC 256 bits
Negotiated cipher?
TLS_AES_256_GCM_SHA384
Chain depth?
4
Hostname matches?
yes
Self-signed?
no
Subject Alternative Names?
  • example.com
  • *.example.com
Raw certificate (PEM)
-----BEGIN CERTIFICATE----- MIID5zCCA42gAwIBAgIQGqc/6iV74zNLmilVLm+HjjAKBggqhkjOPQQDAjBRMQsw CQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSgwJgYDVQQDDB9D bG91ZGZsYXJlIFRMUyBJc3N1aW5nIEVDQyBDQSAzMB4XDTI2MDUzMTIxMzkxMloX DTI2MDgyOTIxNDEyNlowFjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjO PQIBBggqhkjOPQMBBwNCAAR3K9vg9mgByiZluphXApVAUpQtIO9MPLbbdVxu2SDI KEYKZhTqszaA9lNa6oAGtsi++/m+uwI35sAG+zkIpAeOo4ICgDCCAnwwDAYDVR0T AQH/BAIwADAfBgNVHSMEGDAWgBSDA/3n9vVKTRVB9O0iFtMyCj7KZjBsBggrBgEF BQcBAQRgMF4wOQYIKwYBBQUHMAKGLWh0dHA6Ly9pLmNmLWkuc3NsLmNvbS9DbG91 ZGZsYXJlLVRMUy1JLUUzLmNlcjAhBggrBgEFBQcwAYYVaHR0cDovL28uY2YtaS5z c2wuY29tMCUGA1UdEQQeMByCC2V4YW1wbGUuY29tgg0qLmV4YW1wbGUuY29tMCMG A1UdIAQcMBowCAYGZ4EMAQIBMA4GDCsGAQQBgqkwAQMBATATBgNVHSUEDDAKBggr BgEFBQcDATBTBgNVHR8ETDBKMEigRqBEhkJodHRwOi8vYy5jZi1pLnNzbC5jb20v YWU4MDFlZDFjNTViYjU3OWQ3OTIwOGIwZDc3MmFjZmI4Y2MzYTIwOC5jcmwwDgYD VR0PAQH/BAQDAgeAMA8GCSsGAQQBgtpLLAQCBQAwggEEBgorBgEEAdZ5AgQCBIH1 BIHyAPAAdgCUTkOH+uzB74HzGSQmqBhlAcfTXzgCAT9yZ31VNy4Z2AAAAZ6AAzGJ AAAEAwBHMEUCIQCBv0JM0mXaiiQ9efuArkk3O2t/RQ39q7O3oKtYCvOUhQIgdn2u t5rn+AWzBqZ9m1VOlMLpT/jy2M92Is6itMy9rR8AdgDIo8R/x7OtuTVrAT9qehJt 4zpOQ6XGRvmXrTl1mR3PmgAAAZ6AAzGgAAAEAwBHMEUCIQCoc8r0LVigaz6pvG8s v0+uBqzf+LPNPxwYxtgkuVdNMwIgAbK/qRNJIWljIVp30PFWjmM+SnoT80ShaPJM GdbtNLMwCgYIKoZIzj0EAwIDSAAwRQIhALDciGbviRHUIMPez2CVH+Vc0NiaT8Br FrUGD7dej3D4AiAfs90UtVHGYKTXYYPIJlVqUK1amlBBby7M2KI7pSMjxA== -----END CERTIFICATE-----
What does each field mean?

Field reference

Subject

Il campo Subject identifica il titolare del certificato. I certificati moderni si basano sul CN (Common Name) più i Subject Alternative Names. Organization (O), Organizational Unit (OU) e Locality (L) sono presenti nei certificati EV/OV e assenti nei DV semplici (gratuiti) come Let's Encrypt.

Issuer

Identifica la CA che ha garantito per il subject. I browser includono un elenco di CA root fidate; certificati firmati da un emittente non fidato (o self-signed) generano NET::ERR_CERT_AUTHORITY_INVALID. CA pubbliche comuni: Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy.

Subject Alt Names (SAN)

Un singolo certificato può coprire più hostname tramite l'estensione SAN — tipicamente wildcard (<code>*.example.com</code>) o multi-dominio (SAN). Dal 2017 i browser ignorano il Common Name e confrontano solo le voci SAN. Se il suo hostname non figura qui, il certificato non è valido per quel host.

Profondità della catena

Una catena di fiducia parte dal certificato leaf del server, passa attraverso una o più CA intermedie e termina in una CA root presente nel trust store del browser. La profondità 2 (leaf + 1 intermediate) è la più comune. Server mal configurati spesso dimenticano di inviare gli intermediate — i client vedono allora errori di "catena incompleta".

Algoritmo di firma

Descrive come la CA ha firmato il certificato. <code>sha256WithRSAEncryption</code> (RSA + SHA-256) è il default sicuro. <code>ecdsa-with-SHA256</code> usa curve ellittiche — chiavi più corte, stessa sicurezza. <code>sha1WithRSAEncryption</code> è stato compromesso dal 2017 ed è rifiutato da tutti i principali browser.

Chiave pubblica

La metà pubblica della coppia di chiavi. RSA 2048 bit è il minimo pratico oggi; 3072+ per chiavi di lunga durata. EC P-256 è più corta (~256 bit di sicurezza equivalente) e più veloce. Tutto ciò che è inferiore a RSA 2048 o anteriore a P-256 va sostituito.

Cipher negoziato

Descrive la cifratura usata per i dati effettivi: key exchange (ECDHE), cifrario (AES_256_GCM, CHACHA20_POLY1305), MAC (SHA384). Le suite con forward secrecy (ECDHE-*) sono richieste dalla maggior parte degli standard di sicurezza. Le suite basate su CBC o RC4 sono obsolete.

Corrispondenza dell'hostname

Anche un certificato perfettamente valido viene rifiutato se l'hostname richiesto non è nella lista SAN. I wildcard coprono esattamente un'etichetta DNS: <code>*.example.com</code> copre <code>www.example.com</code> ma NON <code>a.b.example.com</code> né il dominio nudo <code>example.com</code>.

Self-signed

Un certificato self-signed ha lo stesso Subject e Issuer. I browser non lo considerano fidato per default — si vedrà "NET::ERR_CERT_AUTHORITY_INVALID". Va bene per ambienti interni o di staging in cui controlla sia server sia client. Per la produzione usi Let's Encrypt (gratuito) o una CA pubblica.

Valido fino al (scadenza)

I browser rifiutano senza riserve i certificati scaduti. I certificati di CA pubbliche durano in genere 90–397 giorni. Imposti il rinnovo automatico: ACME / Let's Encrypt a 60 giorni dalla scadenza, CA commerciali a 30. Attenzione al graduale passaggio del settore a durate obbligatorie di 90 giorni entro il 2027.

Completamente valido

Tutti i controlli base sono superati: la catena di fiducia si ancora a una root fidata dal browser, l'hostname corrisponde al SAN, il certificato è nella finestra di validità e l'algoritmo di firma è accettabile. È lo stato del lucchetto verde che i browser mostrano.

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.