KernelHost Tools SSL Checker

Verifica certificato SSL

Inserisca un dominio (o host:port) e veda subito chi ha emesso il certificato, quando scade, se copre il Suo hostname e come è costruita la catena di certificati. Nodo di Francoforte, gratuito, senza registrazione.

Verificare un dominio
Test rapido: kernelhost.com cloudflare.com github.com:443 expired.badssl.com

Cosa controlla questo test?

KernelHost SSL Checker recupera il certificato del server tramite TLS handshake dal nostro nodo di Francoforte e Le mostra i campi più importanti, senza chiamate a terzi. Vengono controllati e mostrati:

  • Emesso per e da: Common Name (Subject CN), Subject DN completo, e Issuer (quale CA ha firmato il certificato).
  • Periodo di validità: Data di inizio e fine in UTC più i giorni rimanenti. Codice colore: verde (>30 giorni), arancione (7 a 30 giorni), rosso (sotto i 7 giorni o già scaduto).
  • Subject Alternative Names (SANs): Elenco completo degli hostname coperti dal certificato, comprese le voci wildcard.
  • Corrispondenza hostname: Verifica che il dominio inserito sia effettivamente coperto dal Common Name o da un wildcard SAN (RFC 6125).
  • Chiave e firma: Algoritmo della chiave pubblica (RSA, ECDSA), dimensione chiave in bit o nome curva, e algoritmo di firma.
  • Fingerprint e seriale: Fingerprint SHA-256 e SHA-1 del certificato codificato DER più il numero di serie esadecimale.
  • Catena completa: Tutti i certificati che il server ha consegnato durante l'handshake, con subject, issuer e ruolo (leaf, intermediate, root).

Errori SSL comuni e cosa significano

I browser mostrano spesso errori criptici come NET::ERR_CERT_DATE_INVALID o SSL_ERROR_BAD_CERT_DOMAIN. Le cause più frequenti e come risolverle:

  • Certificato scaduto: La data notAfter è nel passato. I browser bloccano del tutto la pagina. Soluzione: rinnovi il certificato. Con Let's Encrypt avviene automaticamente ogni 60 giorni tramite certbot o acme.sh.
  • Hostname mismatch: L'hostname non è né nel Common Name né in alcun SAN. Soluzione: alla riemissione, aggiunga ogni dominio e sottodominio necessario come SAN.
  • Self-signed o CA sconosciuta: L'Issuer non è una root CA fidata. I browser mostrano NET::ERR_CERT_AUTHORITY_INVALID. Soluzione: ottenere un certificato da una CA riconosciuta come Let's Encrypt, ZeroSSL, Sectigo o DigiCert.
  • Catena incompleta: Il server invia solo il certificato leaf senza intermediates. Browser mobili e dispositivi più vecchi falliscono. Soluzione: configurare la catena completa (fullchain.pem) nel server web.
  • Chiave debole o firma debole: RSA sotto 2048 bit o firme SHA-1 non sono più accettate. Soluzione: riemetta con RSA 2048+ o ECDSA P-256.
  • Mixed content e trappola HSTS: Se ha inviato in precedenza un header HSTS valido e il certificato poi scade, i visitatori non possono cliccare oltre l'avviso. Azione immediata: rinnovi il certificato; in emergenza riduca HSTS max-age.

Let's Encrypt vs. certificati commerciali

Let's Encrypt è una CA gratuita e automatizzata gestita da ISRG. I certificati sono tecnicamente identici ai certificati DV commerciali e sono fidati da tutti i browser moderni.

Quando ha senso un certificato a pagamento? Solo in casi speciali:

  • Extended Validation (EV): Mostrava una barra indirizzo verde; oggi è appena visibile. Vale la pena solo per banche o piattaforme di trading quando richiesto per legge.
  • Wildcard senza DNS challenge: Let's Encrypt supporta wildcard solo tramite DNS-01 challenge. Se non ha accesso API al DNS, ZeroSSL Premium o Sectigo sono alternative.
  • Garanzia e assicurazione: Le CA commerciali offrono importi assicurativi in caso di mis-issuance. In pratica raramente rilevante, ma alcuni framework di compliance lo richiedono.

KernelHost Webhosting e cPanel includono integrazione gratuita Let's Encrypt out of the box. I certificati si rinnovano ogni 60 giorni tramite AutoSSL senza che faccia nulla. Anche i certificati wildcard tramite DNS challenge sono possibili una volta che il dominio è ospitato sul DNS KernelHost.

TLS 1.2 vs. TLS 1.3

TLS 1.2 è standard dal 2008, TLS 1.3 è stato pubblicato come RFC 8446 nel 2018 ed è ampiamente diffuso dal 2020. Le versioni più vecchie (SSL 3.0, TLS 1.0, TLS 1.1) sono insicure e dovrebbero essere disabilitate nella configurazione del server.

Cosa fa meglio TLS 1.3:

  • Handshake più veloce: 1-RTT invece di 2-RTT, più 0-RTT opzionale per resumption. Notevolmente più veloce su pagine TLS-heavy.
  • Set di cipher più pulito: Solo 5 cipher suite AEAD ammesse. Niente più scambio chiavi RSA; sempre forward secrecy.
  • Handshake cifrato: Il certificato del server stesso viene trasmesso cifrato. Con ESNI/ECH anche l'SNI è privato.
  • Backwards-compatible: I server possono offrire TLS 1.2 e 1.3 in parallelo. I browser negoziano automaticamente la versione comune più alta.

Cosa significa un certificato scaduto?

Un certificato SSL scaduto significa concretamente: i browser mostrano un avviso a schermo intero e bloccano il sito. I visitatori non possono cliccare oltre nella maggior parte dei casi, soprattutto quando è attivo un header HSTS.

Conseguenze per il gestore:

  • Perdita di ranking su Google (HTTPS è fattore di ranking e i segnali di fiducia vengono valutati).
  • I server di posta (MX/SMTP con STARTTLS) rifiutano connessioni in ingresso; le mail bouncano o vengono consegnate in ritardo.
  • Client API e app mobile con certificate pinning si rompono e potrebbero richiedere un aggiornamento.

HSTS, CAA e OCSP stapling

Un certificato valido è solo l'inizio. Tre meccanismi aggiuntivi portano la sicurezza TLS a livello best-practice:

  • HSTS (HTTP Strict Transport Security): Header che obbliga i browser a usare solo HTTPS d'ora in poi. Raccomandato: max-age=63072000; includeSubDomains; preload (due anni, tutte le sottodomeni, lista preload). Attenzione all'attivazione: una configurazione errata non è reversibile finché max-age è ancora attivo.
  • CAA (Certification Authority Authorization): Record DNS che definisce quali CA possono emettere certificati per il Suo dominio. Esempio: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' previene mis-issuance da parte di altre CA.
  • OCSP stapling: Il server web fornisce direttamente la risposta di stato di revoca della CA invece che ogni browser interroghi la CA separatamente. Più veloce per i visitatori e più leggero per l'infrastruttura CA. Apache: SSLUseStapling On, nginx: ssl_stapling on.

Privacy

KernelHost SSL Checker gira interamente nel nostro nodo di Francoforte senza chiamate a terzi:

  • Nessun inoltro del Suo input ad API esterne (niente SSL Labs, niente Hardenize, niente Cryptomon).
  • Nessuna memorizzazione del dominio verificato oltre il logging standard delle richieste (log webserver, ritenzione 14 giorni).
  • Filtro anti-SSRF blocca le richieste verso intervalli IP privati, loopback e link-local.
  • Rate limit per IP contro abuso. hCaptcha opzionale al submit.

FAQ sui certificati SSL

Supportate anche porte non standard?

Sì. Inserire come host:port, es. mail.example.com:993 per IMAPS o vpn.example.com:8443. La porta di default è 443.

Perché il test mostra un certificato scaduto anche se il mio browser non avvisa?

Probabilmente il Suo server web presenta un certificato diverso per SNI rispetto a quello che vede il test. Verifichi di testare la sottodomain corretta e che il server implementi SNI correttamente.

Perché il test fallisce per il mio dominio interno?

Il checker gira a Francoforte e può controllare solo host raggiungibili pubblicamente. IP privati (10.x, 192.168.x, 172.16-31.x), loopback e link-local sono bloccati di proposito (protezione SSRF).

Quanto spesso dovrei verificare?

Con rinnovo automatizzato (Let's Encrypt + cronjob) basta una verifica dopo il setup più uptime monitoring. Senza automazione, manualmente almeno ogni 30 giorni.

Posso verificare sottodomeni e mail server?

Sì, qualsiasi hostname è supportato. Per i mail server: smtp.example.com:25 o imap.example.com:993. Il test esegue un TLS handshake pulito con SNI corretto.

Cosa significa la nota 'self-signed certificate'?

Il server ha firmato il proprio certificato invece di usare una CA fidata. I browser non lo accettano a meno che l'utente non aggiunga manualmente il certificato al proprio trust store. Per produzione usi sempre una CA reale.

Quali dimensioni di chiave consiglia KernelHost?

RSA 2048 bit come minimo, RSA 3072 o 4096 bit per certificati di lunga durata, oppure ECDSA P-256 quando le performance contano (firme molto più piccole, handshake più veloce). RSA 1024 o inferiore è proibito da anni e viene rifiutato dai browser.

Qual è la differenza tra DV, OV e EV?

DV (Domain Validation) conferma solo che il richiedente controlla il dominio (default con Let's Encrypt). OV (Organization Validation) verifica anche l'azienda (estratto dal registro delle imprese). EV (Extended Validation) è il più rigoroso, con verifica di indirizzo fisico. Dal 2019 i browser non mostrano più una differenza visiva, quindi DV basta nel 99 % dei casi.

Tutti i prodotti KernelHost

Hai bisogno di più di semplici strumenti? Scopri la nostra offerta di hosting commerciale.

KVM-Rootserver da 4,99 €/mese Dedicated-Server da 69,99 €/mese Minecraft-Server da 4,00 €/mese Webhosting da 3,99 €/mese Private VPN-Server IP dedicato Protezione DDoS 3,2 Tbps Arbor