Créer un certificat wildcard Let's Encrypt

Un certificat wildcard Let’s Encrypt est utile lorsque plusieurs sous-domaines doivent être protégés par un même certificat, par exemple app.example.com, vpn.example.com et portal.example.com. Cette approche peut convenir à Sophos ZTNA, aux reverse proxies, aux environnements de test ou à plusieurs services web internes.

Il faut partir de la bonne attente : les certificats Let’s Encrypt ont une durée de validité courte. Leur intérêt ne réside pas dans une longue validité, mais dans la gratuité de l’émission et l’automatisation. Si le certificat est créé manuellement à l’aide d’un enregistrement DNS TXT, son renouvellement ultérieur doit être planifié délibérément.

Un certificat wildcard est requis pour une passerelle Sophos ZTNA. Sophos Central peut générer ce certificat, puis le gérer et le renouveler. Il est également possible de le créer avec Certbot comme décrit dans cet article et de l’importer comme certificat personnalisé. Si le certificat doit être créé directement sur Sophos Firewall pour WAF, WebAdmin ou des portails, la méthode intégrée au firewall est généralement plus adaptée : Configurer les certificats Let’s Encrypt sur Sophos Firewall.

Quand un certificat wildcard est pertinent

Un certificat wildcard couvre un niveau sous un domaine. Ainsi, *.example.com couvre portal.example.com, mais pas automatiquement example.com ni a.b.example.com.

• De nombreux sous-domaines dans la même zone : Un certificat wildcard peut simplifier l’administration.
• Un seul service public : Un certificat pour un FQDN précis est souvent plus clair.
• Le certificat doit être utilisé sur plusieurs systèmes : Un certificat wildcard peut être pratique, mais la distribution de la clé privée doit être strictement contrôlée.
• Un renouvellement entièrement automatique est nécessaire : Prévoir un fournisseur DNS avec un plugin Certbot ou un autre client ACME.
• Sophos Firewall doit uniquement protéger WAF, WebAdmin ou des portails : Vérifier la méthode Let’s Encrypt intégrée au firewall.

Un certificat wildcard n’apporte pas intrinsèquement plus de sécurité. Si la même clé privée est stockée sur plusieurs systèmes, l’impact d’une compromission augmente. Il faut donc documenter les systèmes sur lesquels le certificat a été importé et la personne responsable de la clé privée.

Prérequis

Un certificat wildcard nécessite :

• un domaine ou une zone de sous-domaine déléguée sous contrôle
• pour Sophos Central, l’autorisation de créer et de modifier l’enregistrement CNAME requis dans le DNS
• pour la méthode Certbot manuelle, l’autorisation de créer et de modifier les enregistrements DNS TXT du domaine
• pour la méthode manuelle, un serveur Linux ou un poste d’administration avec Certbot
• pour la méthode manuelle, l’autorisation d’exécuter Certbot avec les privilèges root
• un plan de renouvellement, d’importation et de stockage de la clé adapté à la méthode choisie
• un accès au système cible, par exemple Sophos ZTNA dans Sophos Fusion, un reverse proxy ou un firewall

Les certificats wildcard sont validés au moyen du challenge DNS-01. Avec la méthode Certbot manuelle, un enregistrement TXT est créé sous _acme-challenge.example.com. Avec la méthode gérée dans Sophos Central, un enregistrement CNAME délègue cette vérification à Sophos. La documentation Let’s Encrypt sur les types de challenges décrit les principaux types de challenges.

Pour Sophos ZTNA : créer le certificat dans Sophos Central

Pour une passerelle ZTNA, la méthode gérée dans Sophos Central est généralement plus simple qu’une procédure Certbot manuelle : Sophos génère le certificat Let’s Encrypt, puis prend en charge sa gestion et son renouvellement. Le domaine utilisé par la passerelle doit être connu et l’accès à son fournisseur DNS est nécessaire.

Si la zone DNS utilise des enregistrements CAA, Let’s Encrypt doit y être autorisé comme autorité de certification. Dans le cas contraire, Let’s Encrypt ne peut pas émettre de certificat, même si la validation du domaine réussit.

1. Dans Sophos Central, ouvrir Mes produits > ZTNA, puis cliquer sur Paramètres.
2. Ouvrir Domaines et certificats, puis cliquer sur Ajouter un domaine. Sophos autorise au maximum 100 domaines. Saisir le domaine au format example.com et l’ajouter.
3. Sophos génère une valeur CNAME pour ce domaine. La créer auprès du fournisseur DNS sous _acme-challenge.example.com. Remplacer example.com par le domaine de la passerelle.
4. Revenir à Domaines et certificats, cliquer sur Valider et confirmer que l’enregistrement CNAME a été créé. Sophos vérifie ainsi le contrôle du domaine.
5. Après une validation réussie, cliquer sur Générer un certificat LE, lire et accepter le Contrat d’abonnement Let’s Encrypt, puis lancer la génération. Selon Sophos, celle-ci prend environ 60 secondes ; il est possible de quitter la page pendant l’opération.

⚠️ Si un enregistrement TXT existe déjà sous _acme-challenge.example.com, il doit être supprimé pour permettre l’utilisation de l’enregistrement CNAME requis par Sophos. Vérifier d’abord si une autre application a besoin de cet enregistrement TXT. L’enregistrement CNAME doit ensuite rester dans le DNS.

Pour les domaines déjà présents dans Sophos Central, la procédure dépend de leur état de validation :

• Déjà validé au moyen d’un enregistrement DNS TXT :
  1. Sous Mes produits > ZTNA > Paramètres > Domaines et certificats, cliquer sur Générer un certificat LE.
  2. Sous Ajouter un CNAME, copier l’enregistrement CNAME et le créer auprès du fournisseur DNS sous _acme-challenge.example.com.
  3. Ne supprimer un éventuel enregistrement TXT à cet emplacement qu’après la vérification d’impact décrite ci-dessus.
  4. Confirmer la création de l’enregistrement CNAME.
  5. Accepter le Contrat d’abonnement Let’s Encrypt et cliquer sur Continuer.
  6. Terminer la génération du certificat et vérifier sous Domaines et certificats que le domaine et son enregistrement CNAME s’affichent dans le nouveau format.
• Pas encore validé : Supprimer le domaine existant, l’ajouter de nouveau avec Ajouter un domaine, le valider avec Valider, puis recréer le certificat Let’s Encrypt avec Générer un certificat LE.

Sophos ne génère qu’un seul certificat Let’s Encrypt par compte Central. Il contient tous les domaines validés. Si un domaine supplémentaire est validé par la suite, le certificat doit être généré de nouveau afin de l’inclure.

Pour associer le certificat à une passerelle existante, ouvrir Mes produits > ZTNA > Passerelles, sélectionner la passerelle et définir l’option Automatique (Let’s Encrypt) sous Domaine et certificat. Enregistrer la modification, puis vérifier la validité et la date d’expiration du certificat sur la passerelle. Si la validation ou la génération n’est pas encore terminée avec succès, ne pas encore basculer la passerelle vers le nouveau certificat ; vérifier d’abord l’enregistrement CNAME auprès du fournisseur DNS faisant autorité.

Installer Certbot

La page du projet Certbot recommande l’installation avec Snap pour de nombreux environnements Linux. Sur un système Linux adapté, la procédure de base est la suivante :

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Si Certbot a déjà été installé avec apt, dnf ou un autre gestionnaire de paquets, il faut d’abord vérifier quel exécutable est réellement utilisé. Plusieurs méthodes d’installation en parallèle peuvent sinon entraîner l’utilisation d’une version inattendue ou de tâches de renouvellement différentes de celles prévues.

Créer manuellement le certificat wildcard

Pour une validation DNS manuelle, Certbot est exécuté avec --manual et --preferred-challenges dns. Dans cet exemple, le certificat doit couvrir à la fois example.com et *.example.com :

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Certbot affiche ensuite une ou plusieurs valeurs TXT. Lorsque example.com et *.example.com sont demandés ensemble, deux challenges DNS-01 distincts sont générés. Les deux valeurs doivent être ajoutées comme enregistrements TXT séparés sous _acme-challenge.example.com. Le second enregistrement est ajouté sans remplacer le premier.

Avant de poursuivre dans Certbot, les serveurs de noms faisant autorité pour le domaine et un résolveur externe doivent au minimum renvoyer les valeurs TXT attendues. Un seul résolveur ne constitue qu’un indice, car les fournisseurs DNS peuvent propager les modifications à des vitesses différentes selon l’emplacement.

Contrôle pratique :

dig TXT _acme-challenge.example.com @1.1.1.1

Les serveurs de noms faisant autorité sont identifiables avec dig NS example.com. Le même enregistrement TXT peut ensuite être interrogé directement auprès de l’un de ces serveurs. Après une validation réussie, les valeurs TXT de challenge devenues inutiles sont supprimées. Les anciennes valeurs compliquent les contrôles ultérieurs et peuvent agrandir inutilement la réponse DNS lorsqu’elles s’accumulent.

• certonly : Obtenir ou renouveler un certificat sans l’installer.
• --manual : Définir manuellement la valeur DNS.
• --preferred-challenges dns : Utiliser le challenge DNS-01.
• -d example.com : Inclure le domaine racine.
• -d '*.example.com' : Inclure le domaine wildcard.

Le domaine racine et le domaine wildcard sont deux noms distincts. Si seul *.example.com est demandé, example.com n’est pas inclus automatiquement. Lorsque les deux noms sont demandés ensemble, plusieurs enregistrements TXT portant le même nom peuvent être nécessaires. DNS le permet, et la validation échoue souvent précisément parce qu’une valeur TXT existante est remplacée par erreur.

Localiser les fichiers du certificat

Certbot affiche le nom réel du certificat, les domaines inclus, la date d’expiration et les chemins des fichiers avec cette commande en lecture seule :

sudo certbot certificates

Après une émission réussie, les fichiers se trouvent généralement sous :

/etc/letsencrypt/live/example.com/

Fichiers importants :

• fullchain.pem : Certificat avec les certificats intermédiaires.
• cert.pem : Certificat serveur uniquement.
• privkey.pem : Clé privée.
• chain.pem : Certificats intermédiaires.

De nombreux systèmes cibles nécessitent fullchain.pem et privkey.pem. Certains formulaires d’importation attendent le certificat et la clé séparément, tandis que d’autres demandent également la chaîne. Il faut vérifier le format attendu par le système cible avant l’importation.

⚠️ privkey.pem est la clé privée. Ce fichier ne doit pas être transmis dans un ticket, un chat, un e-mail ou un stockage non protégé. Toute personne qui obtient la clé privée peut utiliser abusivement le certificat.

Planifier le renouvellement

La méthode manuelle avec --manual est simple pour les tests et les opérations ponctuelles, mais elle n’est que partiellement adaptée aux certificats de production. Sans automatisation, une nouvelle valeur DNS TXT doit être définie à chaque renouvellement.

Trois approches sont raisonnables en production :

• Plugin DNS pour le fournisseur DNS : Convient lorsque Certbot peut mettre à jour les enregistrements DNS par API.
• Autre client ACME avec automatisation DNS : Convient lorsque le fournisseur ou la plateforme est mieux pris en charge par un autre client.
• Renouvellement manuel avec un responsable et un rappel calendrier : Réservé aux tests ou aux certificats rarement utilisés.

Les identifiants de l’API DNS sont particulièrement sensibles. Un jeton DNS doit être limité à la zone nécessaire et, si possible, aux types d’enregistrements requis. Des identifiants disposant de droits d’administration étendus sur le domaine ne doivent pas être stockés sans protection sur un serveur web.

Le renouvellement est généralement testé avec :

sudo certbot renew --dry-run

Pour les certificats créés avec une validation DNS manuelle, ce test n’est pertinent que si le processus DNS est automatisé ou si les hooks manuels fonctionnent correctement.

Un renouvellement réussi sur le système Certbot ne met pas automatiquement à jour un certificat déjà importé dans Sophos Firewall, ZTNA ou un reverse proxy. Il faut soit une réimportation documentée, soit un processus de déploiement testé qui ne s’exécute qu’après un renouvellement réussi. Après chaque déploiement, les noms, la chaîne et la nouvelle date d’expiration sont vérifiés sur le système cible réel.

Importer dans les environnements Sophos

Avant d’importer le certificat dans Sophos ZTNA, un firewall, un reverse proxy ou un autre système lié à Sophos, il faut vérifier les points suivants :

• Le nom du certificat correspond-il au nom d’hôte public ?
• Le domaine racine est-il nécessaire en plus du wildcard ?
• Le système cible attend-il fullchain.pem ou des composants séparés ?
• Accepte-t-il la clé privée ou celle-ci doit-elle être convertie dans un autre format ?
• Existe-t-il une procédure documentée pour le prochain renouvellement ?
• Les systèmes sur lesquels le même certificat a été importé sont-ils connus ?

Pour Sophos ZTNA, le certificat créé avec Certbot est attribué à la passerelle dans Sophos Central : ouvrir Mes produits > ZTNA > Passerelles, cliquer sur le nom de la passerelle et sélectionner Importer un certificat personnalisé sous Domaine et certificat. Importer le certificat généré et cliquer sur Enregistrer. Vérifier ensuite sa validité et sa date d’expiration sur la passerelle ; un certificat proche de l’expiration doit être renouvelé, importé de nouveau, puis contrôlé une nouvelle fois sur la passerelle.

Si le certificat est uniquement destiné à WAF, WebAdmin ou aux portails sur Sophos Firewall, le processus intégré est souvent plus simple, car l’émission et le renouvellement ont lieu directement sur le firewall. Pour les certificats wildcard gérés en externe, la méthode Certbot ou ACME reste pertinente. Importer et attribuer des certificats sur Sophos Firewall explique ensuite comment contrôler la clé privée, la chaîne de CA et l’attribution au service.

Erreurs typiques

• La validation échoue : L’enregistrement TXT n’est pas encore visible, le nom de la zone DNS est incorrect ou l’une des valeurs TXT a été remplacée. Vérifier avec dig TXT _acme-challenge.example.com @1.1.1.1.
• Le certificat ne couvre pas example.com : Seul *.example.com a été demandé. Ajouter le domaine racine avec -d example.com.
• Le certificat ne couvre pas a.b.example.com : Le wildcard ne couvre qu’un niveau de sous-domaine. Prévoir un certificat séparé ou un wildcard adapté à la zone plus profonde.
• Le renouvellement ne s’exécute pas automatiquement : La méthode DNS manuelle n’est pas automatisée. Rechercher un plugin DNS adapté ou un autre client ACME.
• Certbot renouvelle le certificat, mais le système cible présente encore l’ancien : La réimportation ou le processus de déploiement ne s’est pas exécuté. Vérifier le numéro de série ou la date d’expiration directement sur la cible.
• L’importation échoue : Le fichier ou le format n’est pas correct. Comparer les exigences relatives à fullchain.pem, cert.pem, privkey.pem et à la chaîne de certificats.
• Les copies de clé créent un risque de sécurité : La clé privée est stockée sur plusieurs systèmes. Documenter les emplacements, les autorisations d’accès et les points d’importation.

Liste de contrôle

• Domaine et niveau de sous-domaine requis définis.
• Domaine racine et wildcard sélectionnés volontairement.
• Pour Sophos Central : accès DNS et autorisation pour l’enregistrement CNAME requis disponibles.
• Pour la méthode Certbot manuelle : accès DNS et autorisation pour les enregistrements TXT disponibles.
• Méthode d’émission par Sophos Central ou par un client ACME externe choisie délibérément.
• Certbot correctement installé pour la méthode manuelle.
• Validation du domaine au moyen du CNAME Sophos ou du challenge DNS-01 manuel contrôlée avec succès.
• Pour la méthode externe, fichiers du certificat et clé privée stockés en sécurité.
• Pour la méthode externe, système cible et format d’importation requis connus.
• Renouvellement planifié par Sophos Central ou avec un responsable, un calendrier ou une automatisation DNS.
• Pour la méthode externe, réimportation ou processus de déploiement vers le système cible testé.
• Anciens certificats et anciennes clés retirés de manière contrôlée après une migration réussie.

FAQ