Ogni volta che vedi il lucchetto nel browser, dietro c’è un certificato e una catena di fiducia. È il vocabolario che ritorna in tutti gli howto sui certificati: qui lo mettiamo in ordine una volta per tutte — cos’è una CA, perché i certificati si incatenano, cosa cambia tra DV, OV ed EV, come si revocano, e come fai a scoprire se qualcuno ha emesso un certificato per il tuo dominio a tua insaputa.

Un certificato, in una riga

Un certificato digitale (formato X.509) lega un nome a una chiave pubblica, e questo legame è firmato da un’autorità di cui ti fidi. Dentro ci sono, in chiaro: il nome per cui vale (nel campo Subject Alternative Name), la chiave pubblica, le date di validità, chi l’ha emesso e a cosa può servire. Non c’è nessun segreto nel certificato: il segreto è la chiave privata, che resta sul server e non lascia mai il dispositivo. Il certificato dice «questa chiave pubblica appartiene a www.esempio.it»; chi possiede la chiave privata corrispondente può dimostrarlo, e nessun altro.

La CA: perché ci fidiamo di uno sconosciuto

Una Certificate Authority (CA) è un’organizzazione che firma certificati dopo aver verificato chi li chiede. Ma perché il tuo browser dovrebbe fidarsi della firma di una CA? Perché il tuo dispositivo porta con sé un trust store: un elenco di certificati radice (le root) considerati fidati, installato dal sistema operativo o dal browser. Se un certificato risale — vedremo come — a una root che è nel tuo trust store, il lucchetto è verde. Se non ci risale, scatta l’avviso di sicurezza.

La fiducia, quindi, non è magia: è un elenco. Chi controlla quell’elenco (Apple, Microsoft, Mozilla, Google) decide di fatto di quali CA si fida il mondo. Entrarci richiede audit severi e anni; uscirne — se una CA sbaglia — è questione di un aggiornamento.

La catena: root, intermedia, foglia

Un certificato non è firmato direttamente dalla root. Si forma una catena:

foglia (il tuo server)   ← firmata da →   intermedia   ← firmata da →   root (nel trust store)
  • La foglia è il certificato del tuo server, quello con il tuo nome. CA:FALSE: non può firmarne altri.
  • L’intermedia è una CA “di servizio” che firma le foglie tutti i giorni. CA:TRUE, ma con poteri ristretti: spesso pathlen:0 (non può creare altre CA sotto di sé) e un Extended Key Usage limitato (per esempio solo «TLS Web Server»).
  • La root è l’ancora di fiducia: è auto-firmata (subject uguale a issuer) e vive nel trust store.

Perché questo giro in tre passi invece di firmare tutto con la root? Per protezione. La chiave della root è troppo preziosa per usarla ogni giorno: sta spenta, in un modulo hardware, in cassaforte. A firmare il traffico quotidiano è l’intermedia; se un’intermedia viene compromessa, la si revoca e se ne mette un’altra senza dover sostituire la root in miliardi di dispositivi. La catena è anche una catena di poteri decrescenti: ogni anello può fare un po’ meno di quello sopra.

Il cross-sign: come una root nuova è fidata dal primo giorno

C’è un trucco elegante per introdurre una root nuova. Un dispositivo vecchio non la conosce, quindi non la troverebbe nel suo trust store. Soluzione: la root nuova viene cross-firmata da una root vecchia, già presente ovunque. Così il dispositivo che non riconosce la root nuova risale un gradino in più e arriva alla vecchia, che conosce — e si fida.

Esempio reale, visto in laboratorio: un certificato Let’s Encrypt del 2026 risale a ISRG Root YR (radice nuova), che a sua volta è cross-firmata da ISRG Root X1, la radice storica presente in ogni sistema da anni. Risultato: il certificato è valido anche sui dispositivi che non hanno mai sentito parlare di «Root YR».

DV, OV, EV: perché uno è gratis e un altro costa centinaia di euro

Qui c’è il paradosso che confonde tutti: ci sono certificati gratuiti e certificati che costano centinaia di euro l’anno (wildcard a parte) — eppure la cifratura è identica. Un certificato da 0 € protegge la connessione esattamente come uno da 500 €. Allora cosa paghi? Non la crittografia, ma il lavoro umano di verifica e la responsabilità che la CA si assume. I tre livelli:

  • DV — Domain Validated. La CA verifica solo che chi chiede controlla il dominio — e lo fa in modo automatico: metti un record DNS o un file sulla porta 80, una macchina controlla, fatto in secondi. Nessun umano, nessun costo: è il tipo di Let’s Encrypt (OID 2.23.140.1.2.1).
  • OV — Organization Validated. La CA verifica anche che l’azienda esista davvero e sia tua. Qui entra il lavoro manuale: controllano la ragione sociale nei registri delle imprese, l’indirizzo, e ti telefonano — a un numero che trovano loro in modo indipendente (elenchi come D-U-N-S/Dun&Bradstreet o registri pubblici, non quello che hai scritto tu nella richiesta) per sentirsi confermare da una persona reale che la richiesta è autorizzata. Giorni di tempo, qualche documento, un costo.
  • EV — Extended Validation. Lo stesso, ma con verifica legale approfondita: esistenza giuridica, anni di attività, sede fisica, firmatari autorizzati, secondo linee guida rigide del CA/Browser Forum. Più lungo, più caro.

Una parola su quell’OID: sta per Object Identifier e non c’entra con l’SNMP. È lo stesso tipo di «codice gerarchico» universale (l’albero ISO/ITU usato, sì, anche dalle MIB SNMP, ma pure da LDAP, dagli algoritmi crittografici…), qui però vive dentro il certificato per dichiarare che tipo di validazione è stata fatta. 2.23.140.1.2.1 è il codice che il CA/Browser Forum ha assegnato a «Domain Validated» (letto a pezzi: 140 = CA/Browser Forum, 1.2.1 = DV); i fratelli sono …1.2.2 per l’OV e …1.1 per l’EV. Vederlo nel certificato è un modo standard e verificabile con cui la CA dice «questo è un DV».

Ecco perché «ti chiamano al telefono»: non stanno controllando la crittografia (quella è matematica, gratis), stanno controllando che tu sia chi dici di essere. È un servizio di due diligence, non di cifratura. E nel prezzo, oltre alle persone che fanno i controlli, spesso c’è anche una garanzia/assicurazione: la CA risponde economicamente (fino a cifre dichiarate) se emette per errore a un impostore.

I lucchetti sono tutti uguali, o ce ne sono di «più prestigiosi»?

Risposta netta, e sorprendente per molti: oggi, nel browser, i lucchetti sono tutti uguali. DV, OV ed EV mostrano lo stesso identico lucchetto. Fino a qualche anno fa l’EV faceva comparire il nome dell’azienda in verde accanto alla barra degli indirizzi — era il «lucchetto prestigioso». Ma intorno al 2019 Chrome e Firefox hanno tolto quella indicazione speciale: studi avevano mostrato che quasi nessun utente la notava o la capiva, e che poteva perfino essere sfruttata per ingannare. Oggi l’unico modo per vedere chi c’è dietro un certificato OV/EV è cliccare sul lucchetto e aprire i dettagli: l’identità dell’organizzazione è lì, scritta nel campo Subject, ma non ha nessun risalto visivo in più rispetto a un DV.

Conseguenza pratica: per un sito web normale, un certificato EV da centinaia di euro e un DV gratuito sono, per l’occhio dell’utente, indistinguibili. L’OV/EV conserva senso in contesti specifici (B2B, settori regolati, gare, dove conta avere l’identità legale dentro il certificato e una garanzia contrattuale), non per il lucchetto.

E attenzione al malinteso più pericoloso: un certificato DV è cifrato esattamente come un EV, ma non dice nulla su chi è dall’altra parte, solo che la connessione verso quel nome è cifrata e integra. Per questo anche un sito di phishing può avere un lucchetto perfettamente valido (gratuito, DV, per il suo dominio). Il lucchetto certifica il canale, non l’onestà di chi lo gestisce: guarda sempre il nome, non solo il lucchetto.

Scadenza e revoca: due modi di «spegnere» un certificato

I certificati scadono apposta: più breve è la vita, meno danni fa una chiave rubata prima che nessuno se ne accorga. I certificati web oggi durano al massimo poche settimane o mesi (Let’s Encrypt: ~90 giorni), e questo obbliga all’automazione del rinnovo.

E se un certificato va invalidato prima della scadenza (chiave compromessa, errore)? Si revoca. Storicamente due meccanismi:

  • CRL (Certificate Revocation List): una lista, pubblicata dalla CA, dei certificati revocati. Il client la scarica e controlla.
  • OCSP (Online Certificate Status Protocol): il client chiede alla CA, in tempo reale, «questo è ancora valido?». Comodo, ma con problemi di privacy (la CA vede cosa visiti) e di scala.

La tendenza del 2025 è chiara: via l’OCSP. Let’s Encrypt lo ha dismesso nel 2025, puntando su certificati a vita così breve che la revoca conta meno (scadono prima che serva revocarli) più le CRL. In pratica: la vita breve è la nuova revoca.

Certificate Transparency: la luce accesa su ogni emissione

Come fai a sapere se una CA — per errore o perché ingannata — ha emesso un certificato per il tuo dominio senza che tu l’abbia chiesto? Grazie a Certificate Transparency (CT): registri pubblici, append-only (ci si aggiunge, non si cancella), in cui ogni certificato emesso dalle CA pubbliche viene registrato. I browser rifiutano un certificato che non porti la prova di essere stato loggato: quella prova sono gli SCT (Signed Certificate Timestamp) incorporati nel certificato stesso.

La conseguenza pratica è potente: puoi sorvegliare il tuo dominio. Un aggregatore come crt.sh ti mostra tutti i certificati mai emessi per i tuoi nomi:

curl 'https://crt.sh/?q=%25.tuodominio.it&output=json' | jq .

Se compare un certificato che non hai richiesto tu, hai scoperto una mis-issuance — un attacco che altrimenti sarebbe rimasto invisibile. CT trasforma un’emissione fraudolenta da segreto a fatto pubblico.

CAA: dire chi può emettere per te

Puoi anche fare prevenzione, non solo sorveglianza. Il record DNS CAA (Certification Authority Authorization) elenca quali CA sono autorizzate a emettere certificati per il tuo dominio. Una CA rispettosa delle regole, prima di emettere, legge il CAA: se non è nell’elenco, si rifiuta.

tuodominio.it.   CAA   0 issue "letsencrypt.org"

Non è una barriera crittografica (si appoggia alla correttezza della CA), ma restringe molto la superficie: un attaccante dovrebbe ingannare proprio la CA che hai autorizzato.

ACME e le sfide: come si prova di essere i proprietari

Il protocollo che automatizza tutto questo si chiama ACME (RFC 8555). Per emettere, la CA ti pone una sfida che solo il vero proprietario può superare. Le tre forme:

  • http-01: metti un file a un indirizzo preciso sul tuo server, sulla porta 80. La CA lo legge. (Serve la 80 raggiungibile.)
  • dns-01: pubblichi un record TXT nel tuo DNS. La CA lo interroga. (Non serve nessuna porta aperta — utile per i servizi interni.)
  • tls-alpn-01: rispondi sulla porta 443 con un handshake TLS speciale.

Negli howto vediamo http-01 all’opera (e perché, dal 2025, Let’s Encrypt la verifica da più punti di vista sulla rete per difendersi dai dirottamenti BGP).

Verificare tu stesso il livello di validazione

Dato che il browser non lo mostra più, se ti serve saperlo — tipico nel B2B, «sto parlando con l’azienda giusta?» — te lo leggi dal certificato. A mano, in qualunque browser: clicca sul lucchetto → mostra/visualizza certificato e guarda il campo Organization (O) del Subject: se c’è, è OV/EV; se c’è solo il nome del dominio, è DV. Da riga di comando, con openssl, leggendo le policy OID:

livello() {
  host="$1"
  cert=$(echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null)
  pol=$(echo "$cert" | openssl x509 -noout -text 2>/dev/null \
        | sed -n '/Certificate Policies/,/Signature/p' | grep -oE 'Policy: [0-9.]+')
  if   echo "$pol" | grep -q '2.23.140.1.1';   then liv="EV";
  elif echo "$pol" | grep -q '2.23.140.1.2.2'; then liv="OV";
  elif echo "$pol" | grep -q '2.23.140.1.2.1'; then liv="DV";
  else liv="?"; fi
  org=$(echo "$cert" | openssl x509 -noout -subject 2>/dev/null | grep -oE 'O = [^,/]+')
  echo "$host  ->  $liv   ${org:-(nessuna Organization)}"
}

livello www.paypal.com     #  ->  EV   O = "PayPal, Inc."
livello mikrotikdojo.com   #  ->  DV   (nessuna Organization)
livello www.ssl.com        #  ->  DV   (nessuna Organization)   <- perfino un venditore di SSL

Estensioni del browser. In Firefox si può automatizzare: un’estensione legge il certificato via l’API browser.webRequest.getSecurityInfo() (con certificateChain/rawDER), controlla O= e le policy OID, e ti avvisa — notifica o badge in barra — quando un sito non è OV/EV. In Chrome non è possibile: l’accesso al certificato è stato tolto alle estensioni, quindi lì resta solo il controllo manuale dal lucchetto.

Il tranello di questo controllo. Oggi DV è la norma, anche per siti serissimi (sopra, perfino ssl.com è DV): un avviso «non è OV/EV» suonerebbe su mezzo web legittimo, e lo impareresti a ignorare. «Non OV/EV» non significa «non fidato». Per il B2B la domanda giusta non è «è OV/EV?» ma «è proprio loro?»: se usano OV/EV, controlla che l’O= sia esattamente la ragione sociale attesa; se usano DV, verifica il dominio concordato per vie indipendenti ed eventualmente fissa l’impronta del certificato atteso (pinning) o sorveglia i loro log CT.

RSA o ECDSA: che chiave mettere nel certificato

Un certificato lega un nome a una chiave pubblica, ma quella chiave può essere di due famiglie, e la scelta ha conseguenze pratiche. Let’s Encrypt (come le altre CA) le emette entrambe; sul router scegli il tipo nel comando di emissione.

  • RSA. La famiglia storica, compatibile ovunque, anche con client molto vecchi. Le chiavi sono grandi: 2048 bit è il minimo comune, 4096 per i paranoici. Più grande = più lenta la matematica dell’handshake e più carico sulla CPU.
  • ECDSA (a curva ellittica, tipicamente la curva P-256). La crittografia a curva ellittica ottiene la stessa robustezza con chiavi molto più piccole: una chiave EC da 256 bit equivale grosso modo a una RSA da 3072 bit. Chiavi più piccole significano handshake più veloci, meno CPU e meno banda — un vantaggio concreto su un router o un apparato piccolo, e su un server molto trafficato.

La differenza non è nella sicurezza del canale (entrambe, con parametri attuali, sono solide), ma in costo e compatibilità. Oggi ECDSA P-256 è un ottimo default: leggera e supportata da tutti i client moderni. Si resta su RSA solo se bisogna parlare con client davvero datati. Molti server tengono entrambi i certificati e servono l’uno o l’altro a seconda di cosa il client dichiara di saper gestire.

Chi c’è dietro Let’s Encrypt, e perché è gratis

Let’s Encrypt è gestita da ISRG (Internet Security Research Group), un’organizzazione no-profit statunitense nata nel 2015 con un obiettivo dichiarato: rendere l’HTTPS la norma, gratis e per tutti. Si finanzia con donazioni e sponsor (grandi aziende tecnologiche, fondazioni), non facendoti pagare i certificati. Oggi è la CA più usata al mondo.

I pro: gratuita, completamente automatica (ACME), diffusissima e fidata ovunque; la vita breve dei certificati più l’automazione alza il livello di sicurezza medio della rete. I contro, da conoscere: emette solo DV (nessuna identità d’organizzazione — se ti serve quella, ti rivolgi a una CA commerciale OV/EV); i 90 giorni obbligano ad avere l’automazione funzionante (un rinnovo mancato = sito rotto); e appoggiarsi a una sola CA è una dipendenza — il CAA e un piano di ripiego aiutano.

Scheda di riferimento della serie «Certificati su RouterOS». Concetti e valori verificati sul campo in laboratorio (emissione reale Let’s Encrypt su CHR 7.25): policy DV 2.23.140.1.2.1, validità ~90 giorni, assenza di URL OCSP (solo CRL), SCT di Certificate Transparency incorporati, catena foglia → intermedia YR1 → ISRG Root YR cross-firmata da ISRG Root X1. Nessuna CVE (regola delle schede KB). Device generico.