Il problema dei sottodomini multipli
Un'organizzazione moderna gestisce decine di sottodomini: www, mail, blog, api, cdn, admin, staging, intranet, vpn. Ognuno richiede HTTPS, e ognuno ha cicli di vita propri. Gestire un certificato separato per ogni sottodominio diventa rapidamente ingestibile: scadenze sfalsate, automazioni eterogenee, alert da configurare separatamente.
Tre strategie principali
Esistono tre approcci consolidati alla gestione SSL multi-sottodominio:
- Certificati individuali: uno per sottodominio
- Wildcard certificate: un solo cert *.tuodominio.it copre tutti i sottodomini di primo livello
- Multidomain/SAN certificate: cert con elenco esplicito di sottodomini
Strategia 1: Certificati individuali
Pro:
- Compromissione di un cert non impatta gli altri
- Cicli di vita indipendenti
- Permette validation diversi per cert diversi (es. EV sul main, DV su staging)
Contro:
- Tante scadenze da monitorare
- Più automazioni da mantenere
- Spreco di risorse se sono tanti
Adatto per: organizzazioni con team dedicati o tooling avanzato (cert-manager, ACME automazione spinta).
Strategia 2: Wildcard
Un wildcard cert come *.tuodominio.it copre www.tuodominio.it, api.tuodominio.it, blog.tuodominio.it, qualunque sottodominio di primo livello.
Pro:
- Un solo cert da gestire
- Nuovi sottodomini coperti immediatamente
- Costo inferiore alla somma dei singoli
Contro:
- NON copre il dominio apex (tuodominio.it senza prefisso) — serve aggiungerlo come SAN
- NON copre sottodomini di secondo livello (foo.bar.tuodominio.it)
- Single point of failure: chiave privata compromessa = tutti i sottodomini esposti
- Validazione DNS obbligatoria con Let's Encrypt
Adatto per: la maggior parte dei siti con sottodomini omogenei.
Strategia 3: SAN/Multidomain
Si elencano esplicitamente i sottodomini desiderati: www, api, blog, cdn. Pro: visibilità esatta dei domini coperti, possibile sottodomini di secondo livello. Contro: ogni aggiunta richiede riemissione del cert.
Architettura consigliata
Per la maggior parte dei progetti il setup ottimale è:
- Un wildcard sul dominio apex + apex stesso come SAN (es.
tuodominio.it+*.tuodominio.it) - Per sottodomini di secondo livello specifici, un secondo wildcard (
*.staging.tuodominio.it) - Cert dedicati solo per ambienti isolati (es. ambiente PCI compliance, isolato da quello pubblico)
Wildcard + Let's Encrypt
Let's Encrypt emette wildcard gratuitamente, ma richiede validazione DNS-01 (non HTTP-01). Serve un DNS provider con API supportata da certbot (Cloudflare, Route53, OVH, AWS, Hetzner, ecc).
Esempio con Cloudflare DNS:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cf.ini -d tuodominio.it -d *.tuodominio.it
Il file credenziali contiene il token API. Il rinnovo automatico funziona se le credenziali restano valide.
Distribuzione del cert su più server
Con un wildcard centralizzato spesso devi distribuire i file su molti server (web, mail, ftp). Approcci comuni:
- Configuration management: Ansible, Puppet, Chef sincronizzano i file dopo il rinnovo
- SCP automatico: hook post-rinnovo di certbot
- Vault centrale: HashiCorp Vault o AWS Certificate Manager memorizzano i cert'e i servizi li scaricano
- Kubernetes cert-manager: gestisce automaticamente cert'e secret per tutti i deployment
Sottodomini interni
Per sottodomini non pubblici (intranet, vpn, dev) hai due opzioni:
- Wildcard su un dominio interno (es.
*.internal.tuodominio.it) emesso da Let's Encrypt via DNS-01, anche se il sottodominio non è pubblico - CA privata interna con certificati firmati da una root aziendale, distribuita via Group Policy
Monitoring
Configura un controllo unico su tutti i sottodomini critici:
for sub in www api blog cdn admin; do
echo | openssl s_client -servername $sub.tuodominio.it -connect $sub.tuodominio.it:443 2>/dev/null | openssl x509 -noout -dates
done
Integralo in un cron o in una pipeline CI per ricevere alert centralizzati.
Hai bisogno di aiuto?
Se vuoi gestione SSL dal team di G Tech Group, scrivici tramite il modulo di contatto.