Vai al contenuto

Verifica del certificato SSL

SSL Certificate Checker

Si collega a un host, mostra la catena servita, la scadenza, il protocollo e i cifrari supportati, e segnala i buchi nella catena.

Si collega a un host in TLS e riferisce che cosa è stato servito davvero: la catena di certificati dalla foglia alla radice, i giorni che restano a ciascuno, le versioni di protocollo che il server accetta e quelle che rifiuta, e il cifrario negoziato. Ogni rilievo viene da un handshake dal vivo e non da un database.

☁️ Usa il nostro serverssltlscertificatesecurity

Questa richiesta la fa il nostro server al posto tuo. Gli inviamo solo il nome host: nessuno dei tuoi cookie e nessuno stato di accesso parte insieme. Il server si collega soltanto a indirizzi pubblici e rifiuta quelli privati e interni.

Di default la porta 443. Le altre porte in cui la connessione parte già in TLS — 8443, 465, 993, 995, 636 e 853 — vengono accettate, e nessun’altra. Il nome host viaggia con SNI, quindi anche un IP condiviso restituisce il certificato giusto.

Come si usa

  1. Inserire l’host, con la porta se non è la 443

    example.com, oppure example.com:8443. Le porte che partono subito in TLS — 8443, 465, 993, 995, 636, 853 — funzionano tutte; le porte STARTTLS come la 587 no.

  2. Leggere il verdetto, poi i rilievi

    Il verdetto riassume i rilievi che stanno sotto, ognuno contrassegnato come buono, nota, attenzione o problema. La scadenza entro trenta giorni e una catena incompleta sono i due che contano più spesso.

  3. Controllare l’ordine della catena, non solo la foglia

    La catena è mostrata nell’ordine in cui il server l’ha inviata. Un server che omette il proprio certificato intermedio funziona in Chrome, che va a prendersi quello mancante, e fallisce in curl e sugli Android più vecchi: una classe di guasti che per settimane sembra un «da me funziona».

  4. Guardare quali versioni di protocollo sono accettate

    Ogni versione viene provata in una connessione a sé, quindi la riga è un fatto sul server e non una deduzione. TLS 1.0 e 1.1 accettati sono un rilievo su cui vale la pena intervenire: sono stati deprecati dall’RFC 8996.

Domande frequenti

Dice che il certificato è valido ma il mio browser protesta

Di solito è la catena, il nome o l’orologio. Va controllato che l’intermedio sia servito, che l’host scritto sia nell’elenco SAN — i browser ignorano del tutto il CN — e che la data del dispositivo sia giusta. Un dispositivo con l’orologio sbagliato rifiuta certificati perfettamente validi.

Posso controllare un server interno?

No. La connessione parte dal nostro server, e la corsia in uscita rifiuta gli indirizzi privati e di loopback. Per un host interno, openssl s_client -connect host:443 -servername host dà la stessa catena in locale.

Perché un IP condiviso restituisce comunque il certificato giusto?

Perché il nome host viene inviato come SNI durante l’handshake, ed è così che il server sa quale certificato presentare. È anche il motivo per cui un indirizzo IP da solo qui non si può controllare.

Controlla la revoca?

No. OCSP e CRL non vengono interrogati, quindi un certificato revocato ma non ancora scaduto qui risulta valido. È un limite vero: quello che si vede è ciò che il server ha servito e se la catena e le date tengono.

Può ricevere da

Dopo

Questi accettano ciò che produce questo strumento, così il risultato può passare direttamente.