2026-10-30 · RESEARCH · Il team di Offensive Technology

Un certificato wildcard nasconde i tuoi sottodomini?

Un certificato wildcard nasconde i tuoi sottodomini? In gran parte sì, ma quasi nessuno lo usa davvero in questo modo. Abbiamo analizzato il certificato attuale e attivo per 660 domini di primo piano attraverso gli stessi log pubblici di Certificate Transparency che chiunque può interrogare, classificando ciò che ciascuno di essi espone. Il 63.8% enumera per nome almeno un sottodominio reale in voci SAN in chiaro, senza alcuna protezione wildcard. Solo il 22.9% si affida esclusivamente a una wildcard, nascondendo la struttura dei propri sottodomini come la tecnologia consente. Aggiungendo l'11.1% che fa entrambe le cose contemporaneamente, il 74.8% dei certificati attuali sui domini principali espone un hostname specifico, indipendentemente dal fatto che includa anche una wildcard. Una wildcard funziona esattamente come previsto. Quasi nessuno, però, la sceglie per questo motivo.

Perché questa è una decisione, non solo un'impostazione predefinita

I certificati wildcard e SAN (Subject Alternative Name) risolvono lo stesso problema, ovvero coprire più hostname con un unico certificato, ma in modi opposti. Una wildcard fa corrispondere un pattern: *.example.com è valida per qualsiasi nome di singolo livello sotto example.com, senza che tale nome compaia mai nel certificato stesso. Un certificato SAN elenca invece gli hostname in modo esplicito, un singolo certificato può coprire app.example.com, api.example.com, e admin.example.com inserendo tutti e tre nel campo SAN. Entrambi sono standard, entrambi vengono emessi da qualsiasi CA pubblica, e il subject del certificato non rivela se l'approccio adottato sia frutto di una scelta deliberata o di una mera conseguenza del tooling utilizzato.

Il caso accidentale è quello più comune. Il rilascio automatico e gratuito, quello utilizzato da quasi tutte le infrastrutture moderne, richiede in genere un certificato per l'hostname esatto con cui il server è configurato. Se attivi dieci sottodomini con dieci richieste automatiche distinte, ottieni dieci certificati SAN, ciascuno dei quali registra il proprio nome, anziché una singola wildcard che li copra tutti e dieci. Scegliere invece una wildcard richiede un passaggio in più che la maggior parte dei team non compie mai, perché il percorso predefinito produce già un certificato funzionante.

I dati: cosa scelgono realmente 660 certificati attuali

Per ciascuno dei 660 domini principali con uno storico in Certificate Transparency, abbiamo estratto il certificato più recente già presente nella nostra cache locale (zero nuove richieste a crt.sh per questa analisi, riutilizzando il dataset di tre precedenti articoli di ricerca) e ne abbiamo letto i campi Subject e SAN. Abbiamo classificato ogni certificato in base a ciò che espone oltre alla solita coppia universale formata dal dominio base e dal rispettivo www. indirizzo: una voce wildcard senza nient'altro, una wildcard più hostname specifici, hostname specifici senza alcuna wildcard, oppure nessuno dei due.

Le barre ambra indicano la presenza di un hostname specifico nel certificato; le barre verde acqua no. Solo la quota del 22.9% con sole wildcard e quella del 2.3% con solo dominio apex, pari al 25.2% complessivo del campione, mantengono la nomenclatura dei sottodomini fuori dai registri pubblici. Gli altri tre domini su quattro stanno, in questo momento, rivelando almeno un nome di sottodominio reale a chiunque consulti Certificate Transparency.

Raramente si tratta di un solo nome

Quando un certificato espone qualcosa, tende a esporre più di un singolo hostname isolato. Tra i 494 certificati che indicano almeno un sottodominio specifico, il caso tipico ne elenca solo uno o due, ma la distribuzione presenta una coda lunga: il singolo certificato con più voci nel campione enumera 70 sottodomini distinti, e 20 certificati (il 4.0% di tutti quelli che espongono informazioni) ne elencano dieci o più, con 9 di questi che ne elencano 25 o più. Un certificato di tali dimensioni non nasconde nulla, assomiglia piuttosto a una sitemap pubblica dell'infrastruttura di un'organizzazione, emessa con un'unica richiesta e registrata in un unico record.

Quest'ultima riga merita una riflessione. Un certificato nella categoria "misto" contiene 94 distinte voci wildcard associate a una singola chiave, insieme a SAN esplicite. Si tratta quasi certamente di una piattaforma o di un provider SaaS che applica la copertura wildcard a numerosi sottodomini di clienti o regionali in una sola volta. È efficiente dal punto di vista operativo. Significa anche che una singola chiave privata, in caso di compromissione, risulta valida per ogni sottodominio sotto tutti i 94 pattern contemporaneamente, presenti e futuri. L'uso delle wildcard scambia la riservatezza dei sottodomini con un rischio diverso: l'ampiezza del blast radius associato a una sola chiave.

Perché non tutti usano semplicemente una wildcard

Se una wildcard nasconde di più, perché solo il 22.9% del campione ne usa una in modo esclusivo? Ci sono diversi motivi pratici, nessuno dei quali costituisce di per sé un errore:

• L'automazione predilige i nomi espliciti, non le wildcard. Strumenti come Certbot richiedono un certificato per l'hostname a cui il server risponde già. Ottenere invece una wildcard comporta la dimostrazione del controllo del dominio tramite una challenge DNS-01, un passaggio aggiuntivo con tooling dedicato che molte infrastrutture evitano.
• Una wildcard copre un solo livello. *.example.com corrisponde a app.example.com ma non a a.app.example.com. Qualsiasi gerarchia reale di secondo livello richiede una seconda wildcard oppure voci con nome esplicito, spingendo le organizzazioni di nuovo verso l'enumerazione anche quando possiedono già una wildcard.
• Il blast radius derivante dalla compromissione della chiave è concreto. Una singola chiave privata wildcard, una volta esposta, consente di impersonare contemporaneamente qualsiasi sottodominio coperto. Una chiave compromessa specifica per host ha sempre e solo coperto quell'unico host. I team che gestiscono sottodomini critici con ownership separate scelgono talvolta certificati nominativi proprio per limitare questo blast radius, anche se al prezzo della riservatezza dei sottodomini.
• Alcuni audit richiedono una copertura esplicita. Alcuni processi di compliance e inventario risultano più semplici da verificare a fronte di un certificato che elenca esplicitamente ogni hostname coperto rispetto a uno che ne dichiara la copertura tramite un pattern.

Come verificare il proprio dominio

L'operazione richiede meno di un minuto e non necessita di altro se non di un browser, poiché legge lo stesso registro pubblico che abbiamo consultato noi.

• Interroga crt.sh per il tuo certificato attuale. Apri https://crt.sh/?q=yourdomain.com&output=json e osserva il campo name_value della voce più recente, oppure verifica direttamente il certificato del tuo server con openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Conta ciò che espone realmente. Una singola voce *.yourdomain.com senza nient'altro indica un uso esclusivo di wildcard. Qualsiasi altra cosa, qualunque host con nome esplicito oltre al dominio apex e a www., è già pubblica tramite CT, a prescindere dal possesso o meno di una wildcard altrove.
• Valuta il compromesso in modo consapevole. Se per la tua architettura la riservatezza dei sottodomini conta più del blast radius legato alla compromissione della chiave, orientati verso una wildcard e un flusso di emissione con DNS-01. In caso contrario, tratta come minimo ogni SAN nominativa come permanentemente pubblica ed evita di considerare la mancata divulgazione del nome di un sottodominio come una forma di sicurezza.

Cosa questo studio non dimostra

Limiti oggettivi, perché un dato privo di precisazioni è solo marketing.

• Abbiamo esaminato il certificato più recente per dominio, non l'intero storico. Un dominio potrebbe aver impiegato una wildcard per anni e aver aggiunto solo di recente una voce SAN con nome, o viceversa. Si tratta di un'istantanea dell'esposizione attuale, non di un'analisi storica continuativa.
• Una SAN con nome esplicito non prova che il servizio sottostante sia attivo o raggiungibile. Abbiamo classificato il testo degli hostname presenti su un certificato, nient'altro. Alcuni sottodomini con nome potrebbero puntare a infrastrutture non più esistenti.
• È un campione di 660 domini di siti grandi e consolidati. La classifica dei siti principali di Tranco è sbilanciata verso organizzazioni con infrastrutture sufficientemente ampie da richiedere più di un hostname. Una popolazione diversa produrrebbe una ripartizione differente.
• Questo studio misura l'esposizione, non la sfruttabilità. Conoscere il nome di un sottodominio è pura attività di reconnaissance. Ciò che un attaccante può fare con quel nome dipende interamente da cosa è effettivamente in esecuzione dietro di esso.

Domande frequenti

Un certificato wildcard nasconde i sottodomini?

In parte. Una wildcard per *.example.com registra solo la stringa del pattern wildcard, non le singole etichette. Tuttavia, nel nostro campione, il 63.8% dei certificati attuali indica comunque un sottodominio reale, e solo il 22.9% si affida esclusivamente a una wildcard senza esporre alcun host con nome.

I sottodomini coperti da una wildcard possono comunque comparire nei log di Certificate Transparency?

La voce wildcard in sé compare solo come pattern, non come nome specifico. Tuttavia, nel momento in cui un certificato separato indica esplicitamente un host, tale nome viene registrato per intero, anche in presenza di una wildcard esistente. L'11.1% dei certificati analizzati presenta entrambi i casi.

Qual è la differenza tra un certificato wildcard e un certificato SAN?

Una wildcard copre un pattern, *.example.com, senza nominare alcun sottodominio. Un certificato SAN elenca esplicitamente hostname specifici. Il rilascio automatizzato genera per impostazione predefinita certificati SAN per l'hostname esatto su cui gira il server, motivo per cui l'enumerazione, anziché l'uso di wildcard, rappresenta il caso più comune.

Un certificato wildcard è più sicuro rispetto all'elenco esplicito di ciascun sottodominio?

Per la riservatezza dei nomi dei sottodomini, sì. Per il blast radius legato alla compromissione della chiave, non necessariamente: una chiave wildcard sottratta è valida contemporaneamente per tutti i sottodomini che copre, mentre una chiave per singolo host compromessa copre solo quell'host.

Cosa succede se la chiave privata di un certificato wildcard viene compromessa?

Un attaccante può impersonare qualsiasi sottodominio corrispondente a quel pattern fino a quando il certificato non viene revocato e riemesso ovunque fosse distribuito. Nel nostro campione, un certificato presenta 94 voci wildcard distinte su una singola chiave, un blast radius molto ampio in caso di compromissione di tale chiave.

Una wildcard copre i sottodomini di sottodomini?

No. *.example.com corrisponde ad a.example.com ma non ad a.b.example.com. Un nome di secondo livello richiede una propria wildcard o una voce SAN esplicita, una delle ragioni per cui le organizzazioni enumerano gli hostname anche quando dispongono già di una wildcard.

In che modo gli attaccanti usano i log di Certificate Transparency per enumerare i sottodomini dagli elenchi SAN?

Ogni certificato emesso da una CA pubblica viene registrato in base a RFC 6962 ed è consultabile gratuitamente tramite crt.sh. Un certificato che enumera gli hostname per nome fornisce a un attaccante una mappa pronta dei sottodomini, senza necessità di scansioni.

Conviene scegliere wildcard o SAN per motivi di sicurezza e non solo di praticità?

Se la riservatezza dei nomi dei sottodomini è prioritaria, una wildcard rappresenta l'opzione predefinita più solida, e la maggior parte delle organizzazioni in questo campione non compie questa scelta. Se si opta per l'enumerazione, occorre considerare ogni SAN con nome come permanentemente pubblica e valutare il compromesso sul rischio di compromissione della chiave prima di effettuare il passaggio.

Letture correlate

• Come i log di Certificate Transparency rivelano i sottodomini interni Stessa cache, la questione dei contenuti: quali categorie di hostname interni compaiono effettivamente quando un certificato ne espone uno.
• Quanto tempo impiega un certificato a comparire in CT? Stesso ambito di crt.sh, il tema delle tempistiche anziché quello dell'esposizione.
• La regola dei 200 giorni per i certificati è già entrata in vigore? Una terza prospettiva sulla stessa cache di 660 domini: la durata consentita dei certificati, non ciò che espongono.