Ispettore di certificati TLS

A cosa serve un certificato

Quando il tuo browser si collega a https://example.com, qualcosa risponde. Che quel qualcosa appartenga davvero a example.com è un’altra questione. Chiunque si trovi sulla rete nel mezzo potrebbe aver risposto al suo posto.

Per questo il server deve mostrare un documento. Un certificato è un piccolo file che contiene una chiave pubblica, l’elenco dei nomi host per cui quella chiave può parlare, una data di inizio, una data di fine e la firma di un’autorità di certificazione (CA) che ha verificato chi controlla quei nomi. Il browser scorre la sua lista. Il nome nella barra degli indirizzi deve comparire nel certificato. La data di oggi deve cadere tra le due date. La firma deve risalire a un’autorità di cui il dispositivo si fida già. E il server deve dimostrare di avere la chiave privata corrispondente. Basta che ne manchi una e il visitatore vede l’avviso a tutta pagina.

La cifratura comincia solo quando tutto questo torna. Il lucchetto significa che il server ha dimostrato chi è, e la cifratura poggia su questa prova.

Cosa verifica l’ispettore

Si collega due volte alla porta 443. La prima volta accetta qualsiasi cosa, così può leggere il certificato in qualunque stato si trovi. La seconda volta verifica tutto rispetto a un elenco standard di radici fidate, come farebbe un client rigoroso.

Dopo richiede le quattro forme dell’indirizzo (http e https, con e senza www) e mostra dove finisce ognuna e se il sito invia un header HSTS. Se vuoi questa parte passaggio per passaggio, c’è il tracciamento dei redirect.

Funziona in Chrome, fallisce ovunque altrove

Le autorità non firmano il tuo certificato con la loro chiave radice. Lo firmano con un certificato intermedio, che a sua volta è stato firmato dalla radice. I dispositivi conservano solo le radici, quindi il tuo server deve inviare l’intermedio insieme al proprio certificato. I due insieme formano la catena.

Quando un server invia solo il proprio certificato, Chrome ed Edge su desktop sono indulgenti. Spesso scaricano l’intermedio mancante o ne riusano uno visto su un altro sito. Firefox con un profilo nuovo, i vecchi telefoni Android, curl, i webhook di pagamento, i server di posta e la maggior parte delle librerie di programmazione non ti fanno questo favore. È così che ti ritrovi con un sito che al proprietario sembra perfetto e che fallisce per un client API. L’ispettore lo chiama Catena incompleta e lo segnala quando la verifica fallisce ed è stato inviato un solo certificato.

Riparare i guasti tipici

• Scaduto. I certificati automatici si rinnovano circa 30 giorni prima della fine, quindi se il tuo è scaduto, il rinnovo fallisce da settimane. Con Certbot, esegui certbot renew --dry-run e leggi l’errore. Di solito è un record DNS che è cambiato, un firewall che chiude la porta 80 o un redirect che si mangia /.well-known/acme-challenge/.
• Nome non coperto. Richiedi di nuovo il certificato elencando ogni nome host: certbot -d example.com -d www.example.com. Un wildcard *.example.com copre un solo livello di sottodomini. Non copre example.com stesso, e molti ci cascano.
• Catena incompleta. Indica al server il file con la catena completa. In nginx: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;. In Apache 2.4.8 e successivi, SSLCertificateFile accetta lo stesso file.
• Autofirmato. Sostituiscilo con un certificato di un’autorità pubblica. Let’s Encrypt, ZeroSSL e Google Trust Services li rilasciano gratis.
• Protocollo vecchio. Attiva TLS 1.2 e 1.3. In nginx: ssl_protocols TLSv1.2 TLSv1.3;

Puoi vedere la stessa cosa da un terminale con openssl s_client -connect example.com:443 -servername example.com.