Certificato wildcard e dominio principale

In breve: Un certificato wildcard come *.example.com semplifica la copertura di molti sottodomini di primo livello, ma non sostituisce automaticamente la copertura del dominio principale example.com. Per evitare errori, controlla sempre i nomi presenti nel SAN del certificato e testa separatamente apex e sottodomini.

In sintesi

Un certificato wildcard come *.example.com semplifica la copertura di molti sottodomini di primo livello, ma non sostituisce automaticamente la copertura del dominio principale example.com. Per evitare errori, controlla sempre i nomi presenti nel SAN del certificato e testa separatamente apex e sottodomini.

Come funziona un certificato wildcard

Nel controllo dell’identità TLS conta il nome richiesto dal client e il nome dichiarato nel certificato. Un identificatore wildcard è valido soltanto quando l’asterisco occupa l’intera etichetta più a sinistra. In pratica *.example.com può corrispondere a www.example.com, shop.example.com o mail.example.com, ma non al dominio nudo example.com e non a un nome più profondo come api.dev.example.com.

Per un sito che deve funzionare sia su example.com sia su tutti i sottodomini principali, la soluzione tipica è un certificato che includa due nomi nel Subject Alternative Name: example.com e *.example.com. Non dare per scontato che il pannello o la CA aggiungano automaticamente l’apex: verifica sempre il certificato effettivamente installato.

Controlli da eseguire

1. Verifica i SAN. Controlla che il certificato contenga esattamente tutti gli hostname pubblicati.
2. Prova apex e sottodominio separatamente. Un test positivo su www non dimostra che funzioni anche il dominio principale.
3. Controlla SNI e virtual host. Sullo stesso IP possono essere presenti più certificati; il server deve presentare quello corretto per il nome richiesto.
4. Controlla catena e scadenza. Un SAN corretto non risolve una catena incompleta, un certificato scaduto o un issuer non attendibile.
5. Verifica la procedura di rinnovo. Se il wildcard dipende da una validazione DNS automatizzata, assicurati che credenziali, API e zona DNS continuino a essere disponibili al client ACME o al sistema di rinnovo.

Da shell puoi usare openssl s_client -connect example.com:443 -servername example.com e poi ispezionare il certificato. Ripeti la prova con un sottodominio reale. Per un controllo operativo completo considera anche IPv4 e IPv6, perché due indirizzi possono terminare TLS su configurazioni differenti.

Errori comuni da evitare

• Credere che *.example.com copra automaticamente example.com.
• Usare un wildcard per coprire più livelli, per esempio aspettandosi che includa a.b.example.com.
• Guardare soltanto il Common Name e ignorare i SAN realmente usati dai client moderni.
• Correggere DNS o CAA senza prima leggere l’errore TLS: un problema di hostname mismatch richiede una correzione del certificato o del virtual host.
• Installare il certificato corretto su un nodo e dimenticare altri nodi, proxy, CDN o bilanciatori che rispondono per lo stesso hostname.

Verifica finale

La configurazione è coerente quando ogni hostname pubblico restituisce un certificato valido, la catena è completa, il SAN contiene il nome richiesto e il rinnovo è ripetibile senza interventi manuali imprevisti. Se usi sia dominio principale sia wildcard, documenta entrambi nell’inventario TLS: questo evita che un futuro cambio di proxy, CDN o web server lasci scoperto uno dei due percorsi.

Guide Xlogic correlate

• Certificato SSL dopo cambio nameserver
• CAA impedisce il rinnovo del certificato
• HTTPS obbligatorio sui domini .app e .dev

Fonti

• RFC 9525 — Service Identity in TLS
• Mozilla — Server Side TLS

Domande frequenti