Stamattina ho lanciato dig CAA lucarimediotti.com sul mio dominio. Risposta: dieci record, cinque autorità di certificazione autorizzate a emettere certificati per il sito, wildcard compresi. Non le ho scelte io una per una. Poi ho interrogato i log pubblici di Certificate Transparency: oggi esistono dieci certificati validi per il dominio e i suoi sottodomini, firmati da quattro CA diverse. Sapevo di uno, forse due.

Il controllo non era curiosità. Il 6 ottobre 2026 Google ha spiegato che qualcuno ha dirottato i domini di primo livello .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane), e con quel controllo ha ottenuto certificati HTTPS validi per diversi domini Google e per altri marchi globali. Le CA non hanno sbagliato niente. Hanno fatto i controlli previsti, e i controlli sono passati.

Questa guida è per chi gestisce il dominio di una PMI, di uno studio o di qualche sito WordPress di clienti. Tre cose da fare in mezz’ora: sapere chi emette i tuoi certificati, scriverlo nel DNS con un record CAA, e farti avvisare quando qualcuno ne emette uno nuovo.

Cosa è successo con .gh, .sl e .as

Il post del team Chrome Secure Web and Networking racconta l’incidente in poche righe. La settimana prima del 6 ottobre Google si accorge di una serie di dirottamenti nei tre ccTLD. Gli attaccanti hanno preso il controllo dei registri dei tre domini nazionali e da lì hanno modificato i record DNS autoritativi dei domini scelti. A quel punto chiedere un certificato è una formalità.

Ars Technica aggiunge il dettaglio tecnico: con il registro in mano, gli attaccanti hanno cambiato gli indirizzi IP dei siti presi di mira e le deleghe dei nameserver. Ricevevano il traffico e rispondevano alle verifiche di controllo del dominio, che è esattamente ciò che una CA chiede di dimostrare prima di firmare.

Chrome ha bloccato i certificati identificati tramite CRLSet, il meccanismo con cui il browser revoca certificati senza aspettare i tempi della revoca ufficiale. Google ha poi lavorato con le CA emittenti per revocarli. Analizzando i log di Certificate Transparency ha trovato altre organizzazioni colpite, senza nominarle. Non si sa quanti certificati siano stati emessi in totale.

La frase che conta per chi gestisce un dominio è questa: «browser-side intervention should not be relied on to protect your users». Google dice di non poter garantire di aver trovato tutti i domini colpiti, e ricorda che il blocco di Chrome non protegge chi usa un altro client. Un client di posta, un’app mobile, uno script che chiama la tua API: nessuno di questi consulta i CRLSet di Chrome.

Perché i controlli automatici non ti proteggono

Un certificato TLS lega un nome di dominio a una chiave pubblica. Chi lo chiede deve dimostrare di controllare il dominio: pubblicare un file sul sito (http-01), un record TXT nel DNS (dns-01) o rispondere con un certificato speciale sulla porta 443 (tls-alpn-01). Tutti e tre i metodi presuppongono che DNS e indirizzo IP siano tuoi. Se l’attaccante controlla il DNS, li supera tutti.

C’è un secondo problema, meno visibile. Le CA possono riusare una validazione già completata per emissioni successive. Secondo il ballot SC081v3 del CA/Browser Forum, la finestra si accorcia per gradi fino a marzo 2029. Le date, riportate da DigiCert: dal 15 marzo 2026 il riuso della validazione di dominio è di 200 giorni, dal 15 marzo 2027 scende a 100, dal 15 marzo 2029 a 10. Oggi siamo nella fascia dei 200 giorni.

Tradotto: chi ha validato il tuo dominio durante un dirottamento di qualche ora può avere in mano una validazione utilizzabile per mesi, anche dopo che hai ripreso il controllo del DNS. È questo il punto su cui Google insiste. Il record CAA non ferma l’emissione mentre l’attacco è in corso, perché in quel momento il DNS che la CA legge è quello dell’attaccante. La ferma dopo, quando il DNS torna tuo e la CA, prima di firmare, rilegge il CAA e scopre che quella CA, o meglio quell’account, non è autorizzato.

La RFC 8659 è netta su questo: prima di emettere, una CA conforme deve cercare i record CAA del dominio e, se esistono, non può emettere un certificato che non sia coerente con quei record. Il controllo avviene a ogni emissione, anche quando la validazione del dominio è riusata.

Passo 1: l’inventario di chi emette i tuoi certificati

Prima di restringere devi sapere cosa funziona oggi. Se il CAA autorizza solo Let’s Encrypt e l’hosting rinnova con Sectigo, il rinnovo fallisce alla scadenza, e te ne accorgi dall’avviso del browser.

Due comandi bastano. Il primo legge il CAA pubblicato:

dig +short CAA tuodominio.it
dig +short CAA www.tuodominio.it
Se nessuno dei due restituisce niente, qualsiasi CA pubblica può emettere. Un sottodominio senza record eredita quello del dominio principale.

Il secondo interroga i log di Certificate Transparency. Ogni certificato accettato di default da Chrome deve essere registrato in log pubblici, ed è per questo che Google ha potuto trovare gli altri domini colpiti. L’API di Cert Spotter restituisce tutti i certificati non scaduti per un dominio e accetta un numero limitato di richieste senza account, per uso personale o di valutazione:

curl -s "https://api.certspotter.com/v1/issuances?domain=tuodominio.it&include_subdomains=true&expand=dns_names&expand=issuer" \
  | python3 -c "import json,sys; [print(c['not_before'][:10], c['issuer']['friendly_name'], ','.join(c['dns_names'])) for c in json.load(sys.stdin)]"
Una riga per certificato: data di emissione, CA, nomi coperti.

Sul mio dominio il risultato, il 7 ottobre 2026, è questo:

  • Sectigo: 6 certificati: cinque per altrettanti sottodomini, uno per il dominio principale e www, emesso il 16 dicembre 2025 e valido fino al 16 gennaio 2027.
  • Google Trust Services: 2 certificati wildcard *.lucarimediotti.com, emessi il 9 agosto 2026, validi 90 giorni.
  • Let’s Encrypt: 1 wildcard, emesso il 21 agosto 2026.
  • SSL.com: 1 certificato per il sottodominio di Beacon, il mio strumento di audit.

Due cose saltano all’occhio. Il certificato Sectigo da 13 mesi è stato emesso prima del 15 marzo 2026, quando il limite era ancora 398 giorni: oggi non si potrebbe più. E ogni sottodominio con un certificato valido è un nome da ricontrollare: se il progetto è chiuso, il record DNS non ha motivo di esistere.

Passo 2: un record CAA che dica qualcosa

Il record CAA ha tre proprietà utili. issue autorizza una CA per i certificati normali. issuewild autorizza una CA per i wildcard; se manca, per i wildcard vale issue. iodef indica dove la CA può segnalare una richiesta rifiutata, ma la RFC non obbliga la CA a usarlo: non contarci come allarme.

Un CAA restrittivo per un sito WordPress su hosting tradizionale con Let’s Encrypt è corto:

tuodominio.it.  CAA 0 issue "letsencrypt.org"
tuodominio.it.  CAA 0 issuewild ";"
tuodominio.it.  CAA 0 iodef "mailto:[email protected]"
Solo Let’s Encrypt, nessun wildcard. Il punto e virgola da solo vieta l’emissione.

Il CAA si eredita: un record sul dominio principale vale per tutti i sottodomini che non ne hanno uno proprio. Se un sottodominio usa un’altra CA, per esempio il servizio di posta del fornitore, gli dai un CAA suo invece di allargare quello del dominio.

Il passo successivo è quello che chiede Google: legare l’autorizzazione al tuo account, non solo alla CA. La RFC 8657 aggiunge due parametri. accounturi limita l’emissione a uno specifico account ACME. validationmethods limita i metodi di validazione accettati. La documentazione di Let’s Encrypt li supporta entrambi e spiega lo scopo con le stesse parole che servono qui: chi dirotta temporaneamente il tuo dominio ma non ha la chiave del tuo account ACME non può farsi emettere certificati.

# L'URL dell'account lo stampa certbot
sudo certbot show_account

# Poi nel DNS
tuodominio.it.  CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"
Il numero dell’account è un esempio: usa quello restituito dal tuo certbot.

Con accounturi la validazione rimasta in cache all’attaccante non serve più: è legata al suo account, e il tuo CAA non lo autorizza. È la difesa giusta per il dopo-incidente. Funziona però solo dove l’account ACME è tuo, cioè su un VPS o un server dove gira il tuo certbot. Sull’hosting condiviso l’account è del provider, e su Cloudflare è di Cloudflare.

Su validationmethods un’avvertenza: nell’attacco ai ccTLD l’attaccante controllava DNS e IP, quindi tutti e tre i metodi passavano. Restringere a dns-01 non avrebbe cambiato niente. Aiuta contro attacchi più piccoli, come il dirottamento di un singolo indirizzo IP.

Il caso Cloudflare: i record che non vedi

Se il tuo dominio è su Cloudflare, come il mio, c’è una regola da conoscere. Secondo la documentazione Cloudflare, quando hai Universal SSL e aggiungi un qualsiasi record CAA alla zona, Cloudflare aggiunge in automatico i record per le CA partner che usa. Quei record non compaiono nel dashboard: si vedono solo con dig. La documentazione cita Google Trust Services, Let’s Encrypt, SSL.com e Sectigo, e avverte che la lista può cambiare.

La mia lettura dei dieci record del mio dominio è questa: basta un CAA qualsiasi nella zona perché Cloudflare completi la lista con le sue CA partner. Fra i miei c’è anche digicert.com, che la pagina non elenca, e la documentazione stessa avverte che la lista non è esaustiva. Il risultato dice «quasi tutte le CA che contano». Non è sbagliato, ma restringe poco.

Su Cloudflare con Universal SSL quindi non scrivi un CAA a una sola CA: lo rifarebbe largo Cloudflare stesso. Ci sono due strade. Accettare l’elenco delle CA partner e puntare tutto sul monitoraggio, che è la scelta sensata per un sito di una PMI. Oppure passare ai certificati dedicati di Advanced Certificate Manager, per i quali Cloudflare dichiara di non aggiungere record CAA. Per un sito vetrina è sproporzionato.

Un dettaglio che si dimentica: i wildcard. Universal SSL copre il dominio principale e il wildcard *.tuodominio.it. Un issuewild ";" copiato da una guida generica rompe il certificato di bordo al rinnovo successivo.

Passo 3: farti avvisare dai log CT

Il CAA riduce chi può emettere. Il monitoraggio ti dice quando qualcuno lo ha fatto. Google lo chiede su tutto il portafoglio domini, compresi i domini parcheggiati e le estensioni nazionali registrate solo per difesa del marchio, che sono proprio quelli che nessuno guarda.

Su Cloudflare c’è una funzione già pronta. Certificate Transparency Monitoring è spenta di default: si attiva da SSL/TLS, Edge Certificates, aggiungendo un indirizzo email. Gli avvisi per i certificati che Cloudflare emette per conto tuo vengono filtrati, quindi ricevi solo le emissioni esterne. Non rileva i domini simili usati per phishing: un certificato per un nome con una lettera cambiata non fa scattare niente.

Se non sei su Cloudflare, o vuoi controllare più domini con un solo strumento, basta uno script giornaliero. Questo interroga Cert Spotter, ricorda l’ultimo certificato visto e segnala quelli firmati da CA che non hai messo in elenco:

#!/usr/bin/env python3
"""Segnala i certificati nuovi emessi da CA non attese per un dominio."""
import json
import pathlib
import sys
import urllib.request

DOMINIO = "tuodominio.it"
CA_ATTESE = {"Let's Encrypt", "Google Trust Services"}
STATO = pathlib.Path.home() / ".ct-ultimo-id"
BASE = ("https://api.certspotter.com/v1/issuances?domain=" + DOMINIO +
        "&include_subdomains=true&expand=dns_names&expand=issuer")

ultimo = STATO.read_text().strip() if STATO.exists() else ""
anomalie = []
while True:
    url = BASE + ("&after=" + ultimo if ultimo else "")
    with urllib.request.urlopen(url, timeout=30) as risposta:
        pagina = json.load(risposta)
    if not pagina:
        break
    for cert in pagina:
        ca = cert["issuer"]["friendly_name"]
        if ca not in CA_ATTESE:
            anomalie.append("%s %s: %s" % (cert["not_before"][:10], ca,
                                           ", ".join(cert["dns_names"])))
    ultimo = pagina[-1]["id"]

if ultimo:
    STATO.write_text(ultimo)
for riga in anomalie:
    print("CA non attesa:", riga)
sys.exit(1 if anomalie else 0)
Al primo avvio controlla tutti i certificati validi e segnala quelli di CA non attese; dalle volte successive solo quelli nuovi.

Lo lanci una volta al giorno da cron, e il codice di uscita 1 diventa l’allarme. Il primo giro mostrerà probabilmente qualche CA inattesa: aggiungila all’elenco solo quando sai chi la usa e perché.

Le richieste senza account sono poche all’ora e pensate per uso personale. Per un’agenzia che controlla trenta domini di clienti serve un account Cert Spotter, oppure l’avviso di Cloudflare su ogni zona.

Siti WordPress: dove nascono i certificati che non conosci

Su un sito WordPress i certificati arrivano da più punti, e di solito nessuno li ha scelti. Il pannello dell’hosting rinnova in automatico con la sua CA. Il CDN emette i suoi certificati di bordo. Il servizio di posta del dominio ne ha uno per mail. o autodiscover.. Un plugin per l’HTTPS può aver registrato un account ACME anni fa. Ogni ambiente di staging creato per un cliente aggiunge un sottodominio con il suo certificato.

Prima di toccare il CAA conviene fare la mappa in quest’ordine:

  1. Lista dei sottodomini che risolvono davvero, dal pannello DNS.
  2. Per ognuno, la CA che compare nei log CT negli ultimi mesi.
  3. Per ogni CA, chi la usa: hosting, CDN, posta, plugin.
  4. Per i sottodomini di progetti chiusi, cancellazione del record DNS.

L’ultimo punto vale più del CAA. Un sottodominio che punta a un servizio dismesso è un candidato al subdomain takeover, e un certificato valido su quel nome lo rende ancora più credibile.

Se i tuoi siti sono anche dietro Cloudflare, ho scritto delle scelte TLS di bordo nella guida su Cloudflare, TLS post-quantum e WordPress. Il CAA è la parte che sta prima: chi ha il diritto di firmare.

Cosa il CAA non fa

Durante un dirottamento attivo il CAA non serve: l’attaccante pubblica il CAA che vuole. Lo dice Google stesso. Il valore arriva dopo, quando hai ripreso il controllo e vuoi che le validazioni rimaste in cache non producano nuovi certificati.

Se a essere compromesso è il registro del tuo dominio di primo livello, come nei tre ccTLD, i blocchi presso il registrar e anche DNSSEC aiutano poco. La mia lettura: chi controlla il registro controlla anche la delega e le chiavi pubblicate per il dominio, quindi le difese che dipendono dalla catena DNS cadono insieme a lei. Quello che resta in piedi sono i log CT, perché sono pubblici e fuori dalla catena DNS, e il blocco lato browser.

Il CAA non protegge da una CA che non lo rispetta: saltare il controllo viola le regole e costa l’esclusione dai browser. Deterrente forte, non garanzia tecnica.

Infine, niente di tutto questo ferma un dominio simile al tuo registrato per il phishing.

La mia lettura: un’estensione di dominio è un fornitore

Nessuna delle vittime aveva un problema di sicurezza nei propri sistemi. Avevano un dominio sotto un registro nazionale che qualcuno è riuscito a controllare. È una dipendenza come un’altra, solo che non compare in nessun elenco fornitori.

Nel mondo AI la scelta di un’estensione nazionale per ragioni di marketing è diffusa: .ai è il dominio nazionale di Anguilla, .io quello del Territorio britannico dell’Oceano Indiano. Non dico che siano insicuri. Dico che chi sceglie un’estensione accetta la sicurezza del suo registro, e di solito nessuno si chiede chi sia. Per il dominio del login clienti o della posta aziendale è una domanda da farsi.

Sui tempi: fino al 2029 la finestra di riuso resta di 200 e poi 100 giorni, e il CAA con accounturi è lo strumento più netto che ha il proprietario del dominio per chiuderla da solo.

Su questo blog ho già scritto che il rischio di sicurezza delle PMI sta sempre più nei fornitori, nell’articolo sulla supply chain e i fornitori. Il registro del dominio è il fornitore più a monte di tutti.

Checklist operativa in 30 minuti

  1. Lancia dig +short CAA sul dominio principale e annota cosa c’è, inclusi i record che il dashboard non mostra.
  2. Interroga Cert Spotter o crt.sh e scrivi l’elenco delle CA che emettono oggi per dominio e sottodomini.
  3. Abbina ogni CA a chi la usa: hosting, CDN, posta, plugin. Cancella i sottodomini dei progetti chiusi.
  4. Se non sei su Cloudflare Universal SSL, pubblica un CAA con le sole CA dell’elenco e decidi in modo esplicito sui wildcard.
  5. Dove l’account ACME è tuo, aggiungi accounturi.
  6. Attiva Certificate Transparency Monitoring su Cloudflare, oppure metti in cron lo script sopra.
  7. Fai lo stesso sui domini parcheggiati e sulle estensioni registrate solo per difesa del marchio.

Il mio dominio adesso ha l’inventario fatto e un elenco di CA attese. Il CAA resta quello di Cloudflare, per i motivi spiegati sopra. Quello che è cambiato è che, se domani compare un certificato firmato da una CA che non uso, lo so il giorno stesso e non sei mesi dopo.

Fonti