Deux façons de couvrir plus d'un nom. Le générique couvre tout un niveau ; le certificat SAN énumère des noms précis. Avec Let's Encrypt ils coûtent la même chose à exploiter, et la différence est opérationnelle.
SAN - une liste de noms
sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com- Fonctionne avec la validation HTTP - aucune API DNS nécessaire.
- Un nouveau sous-domaine impose une réémission, soit une seule commande.
- Le certificat publie la liste des noms : chacun de vos sous-domaines est donc public.
Générique - tout un niveau
sudo certbot certonly --manual --preferred-challenges dns \
-d example.com -d '*.example.com'- Couvre n'importe quel sous-domaine, y compris ceux qui n'existent pas encore.
- Exige la validation DNS - le renouvellement demande donc un accès API chez votre fournisseur DNS, ou quelqu'un de présent tous les soixante jours.
- Ne couvre qu'UN seul niveau : *.example.com ne couvre pas a.b.example.com.
- Ne couvre pas le domaine nu - énumérez example.com aussi, comme ci-dessus.
La différence de sécurité qui tranche
Une clé générique vaut pour tous les sous-domaines. Posez-la sur cinq serveurs : la compromission d'un seul donne à un attaquant un certificat valable pour tous, y compris le sous-domaine de paiement. Un certificat SAN par serveur garde ce rayon d'explosion étroit.
Que choisir
- Une poignée de sous-domaines sur un seul serveur - SAN. Validation plus simple et renouvellement plus simple.
- Beaucoup de sous-domaines, ou engendrés par client - générique, avec validation DNS automatisée.
- Des sous-domaines sur des serveurs différents - un certificat distinct pour chacun, quel qu'en soit le nombre.
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cf.ini \
-d example.com -d '*.example.com'Automatisez dans les deux cas. Un défi DNS manuel tous les soixante jours est un renouvellement qui finira par être oublié - voyez les sous-domaines génériques.