Security

SSL Checker

Ispeziona catena certificati, scadenza e algoritmo.

Hostname host or host:port (default 443)
github.com:443
TLSv1.3 expires in 66d
Verdict
  • Certificate is valid for this host and not expired.
Subject?
github.com
Issuer?
Sectigo Public Server Authentication CA DV E36 — Sectigo Limited
Valid from
2026-07-03T00:00:00Z
Valid to?
2026-09-30T23:59:59Z
Signature algorithm?
ecdsa-with-SHA256
Public key?
EC 256 bits
Negotiated cipher?
TLS_AES_128_GCM_SHA256
Chain depth?
3
Hostname matches?
yes
Self-signed?
no
Subject Alternative Names?
  • github.com
  • www.github.com
Raw certificate (PEM)
-----BEGIN CERTIFICATE----- MIID7jCCA5SgAwIBAgIQcgEOA/SgZ/5OeWJmQwcY9jAKBggqhkjOPQQDAjBgMQsw CQYDVQQGEwJHQjEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5T ZWN0aWdvIFB1YmxpYyBTZXJ2ZXIgQXV0aGVudGljYXRpb24gQ0EgRFYgRTM2MB4X DTI2MDcwMzAwMDAwMFoXDTI2MDkzMDIzNTk1OVowFTETMBEGA1UEAxMKZ2l0aHVi LmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABIWWMDSOi/1sMgquP4I/obBM 735wpzcIZi4fLeiBsToXVVSwjj4OPH+W6azHzxETM0gUP7raehddpJ8uwjqYsTij ggJ5MIICdTAfBgNVHSMEGDAWgBQXmagEwW/kLXCoChA9A9PpGrgmYzAdBgNVHQ4E FgQUEKU6Ytbv1gZWnty4gvzCe2hdPWkwDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB /wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwSQYDVR0gBEIwQDA0BgsrBgEEAbIx AQICBzAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZn gQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5z ZWN0aWdvLmNvbS9TZWN0aWdvUHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURW RTM2LmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wggEF BgorBgEEAdZ5AgQCBIH2BIHzAPEAdgDXbX0Q0af1d8LH6V/XAL/5gskzWmXh0LMB cxfAyMVpdwAAAZ8lTHVtAAAEAwBHMEUCIQCkpa0ZYNwsPiMRLHz+kk1QS/W9bg/8 4yNBVGkT289dNQIgMWLgxYp6vGJXJxyD3c1NI1aZsPA7GqyLSXaZLZHgKh0AdwDI o8R/x7OtuTVrAT9qehJt4zpOQ6XGRvmXrTl1mR3PmgAAAZ8lTHVhAAAEAwBIMEYC IQDsO+TR8EVfCiObBPoDLRKzKLQ/uorsebJ2aZDIejA9RgIhAJ6dp7FqCD93tQXX AF24pDIms1fX4dZ+VPzXGuD8u8t1MCUGA1UdEQQeMByCCmdpdGh1Yi5jb22CDnd3 dy5naXRodWIuY29tMAoGCCqGSM49BAMCA0gAMEUCIB0PC2GRSurxu8gCkSNsYxmw kAtCNfCvpXRiif8PhGkmAiEAzBH4AVYAtv1FsMrJabD9FYcAql0EteKafckH2exj Uag= -----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.