Certificati TLS e HTTPS: come funzionano davvero

Il lucchetto nella barra degli indirizzi dice una cosa sola: la connessione è cifrata e il server ha dimostrato di controllare quel dominio. Non dice che il sito è affidabile, non dice chi c'è dietro, non dice che i dati sono al sicuro una volta arrivati. Capire cosa certifica davvero un certificato TLS evita sia falsa sicurezza sia panico ingiustificato.

Cosa contiene un certificato

Un certificato X.509 è un file firmato che lega una chiave pubblica a uno o più nomi di dominio. I campi che contano:

• Subject / CN: il nome principale, oggi in pratica ignorato dai browser
• SAN (Subject Alternative Name): la lista effettiva dei domini validi. È questo il campo che i browser verificano
• Issuer: la CA che ha firmato
• Validità: date di inizio e fine
• Chiave pubblica: RSA 2048/4096 o ECDSA P-256
• Firma della CA: garantisce che il resto non sia stato alterato

La chiave privata non sta mai nel certificato: resta sul server ed è l'unico elemento davvero segreto. Se la chiave privata trapela, il certificato va revocato e riemesso, punto.

L'handshake in breve

Con TLS 1.3 la sequenza è compatta:

1. Il client invia ClientHello con le cipher suite supportate, l'estensione SNI (il dominio richiesto) e una chiave effimera
2. Il server risponde con ServerHello, la propria chiave effimera, il certificato e la firma
3. Client e server derivano la chiave di sessione tramite scambio Diffie-Hellman effimero
4. Il traffico applicativo parte cifrato

Due conseguenze pratiche. La prima: grazie all'SNI, un solo IP può ospitare centinaia di siti HTTPS distinti — ma il nome del dominio richiesto viaggia ancora in chiaro nel ClientHello (a meno di ECH, ancora poco diffuso). La seconda: con lo scambio effimero, chi registra il traffico oggi non potrà decifrarlo domani nemmeno rubando la chiave privata del server. È la forward secrecy, e TLS 1.3 la rende obbligatoria.

DV, OV, EV: quale serve

• DV (Domain Validation): la CA verifica solo che tu controlli il dominio, tramite record DNS o file su HTTP. Emissione in secondi, costo zero con Let's Encrypt.
• OV (Organization Validation): la CA verifica anche l'esistenza legale dell'organizzazione. I dati compaiono nel certificato, ma il browser non li mostra in evidenza.
• EV (Extended Validation): verifica più approfondita. Dal 2019 i browser hanno rimosso la barra verde con il nome dell'azienda, quindi l'utente finale non vede alcuna differenza rispetto a un DV.

Sul piano crittografico i tre tipi sono identici: stessa cifratura, stessa sicurezza del canale. OV ed EV hanno senso solo per requisiti contrattuali o di compliance, non per protezione tecnica.

Wildcard e multi-dominio

Un wildcard (*.esempio.it) copre tutti i sottodomini di primo livello — www, mail, api — ma non a.b.esempio.it né il dominio nudo esempio.it, che va aggiunto esplicitamente nei SAN. Comodo, ma con un rischio: la stessa chiave privata finisce su tutti i server che usano quel certificato, e comprometterne uno li compromette tutti.

Un certificato multi-dominio (SAN) elenca nomi anche non correlati. Preferibile quando i servizi girano su macchine diverse con livelli di esposizione diversi — o, meglio ancora, un certificato separato per host.

Per il wildcard la validazione è obbligatoriamente via DNS (record _acme-challenge TXT): serve quindi un provider DNS con API, altrimenti il rinnovo automatico non è possibile.

Rinnovo automatico: non è opzionale

La durata massima dei certificati pubblici si è progressivamente accorciata, e la direzione è chiara: cicli sempre più brevi. Il rinnovo manuale non è più sostenibile — è solo questione di tempo prima che qualcuno si dimentichi e il sito vada offline.

Lo standard di fatto è ACME, con client come certbot, acme.sh o lego. Pratiche minime:

• Rinnovo schedulato con largo anticipo rispetto alla scadenza (il default a due terzi della validità va bene)
• Reload del servizio dopo il rinnovo, non restart: un nginx -s reload non chiude le connessioni attive
• Monitoraggio della scadenza indipendente dal client ACME: un check esterno che interroga la porta 443 e allarma a 14 giorni. Se il client si rompe in silenzio, il monitoraggio è l'unica rete di sicurezza
• Su pannelli come HestiaCP o cPanel il rinnovo è integrato, ma va comunque verificato che il cron giri davvero

Errori ricorrenti

Catena incompleta. Il server invia il certificato foglia ma non l'intermedio. I browser desktop spesso recuperano l'intermedio da soli e mascherano il problema; client mobili, curl e librerie applicative falliscono. Va sempre servito il fullchain.

Mismatch del nome. Il dominio richiesto non è nei SAN. Tipico dopo aver aggiunto un sottodominio senza rigenerare il certificato.

Orologio sbagliato. Un server con data errata considera validi certificati scaduti o rifiuta quelli buoni. NTP configurato risolve la categoria intera.

Contenuto misto. La pagina è in HTTPS ma carica risorse in HTTP: il browser le blocca o degrada il lucchetto.

Redirect mal fatti. Chi forza HTTPS senza HSTS lascia una finestra al primo accesso. L'header Strict-Transport-Security con max-age di almeno un anno chiude il buco, ma va abilitato solo quando si è certi che tutto il dominio, sottodomini inclusi, sia raggiungibile in HTTPS.

Verifica rapida da riga di comando

# Catena, date di validità e SAN in un colpo solo
openssl s_client -connect esempio.it:443 -servername esempio.it </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

# Solo i giorni residui, utile in uno script di monitoraggio
echo | openssl s_client -connect esempio.it:443 -servername esempio.it 2>/dev/null \
  | openssl x509 -noout -enddate

Se openssl s_client mostra Verify return code: 0 (ok), la catena servita è completa e valida. Qualsiasi altro codice va indagato prima che lo faccia un cliente.