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.

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. Cet article décrit la méthode wildcard externe avec Certbot.

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
• un accès aux enregistrements DNS TXT du domaine
• un serveur Linux ou un poste d’administration avec Certbot
• l’autorisation d’exécuter Certbot avec les privilèges root
• un plan pour le renouvellement, l’importation et le stockage de la clé
• un accès au système cible, par exemple Sophos Central ZTNA, un reverse proxy ou un firewall

Les certificats wildcard sont validés au moyen du challenge DNS-01. Un enregistrement TXT est créé sous _acme-challenge.example.com. Let’s Encrypt vérifie cet enregistrement DNS, puis émet le certificat. La documentation Let’s Encrypt sur les types de challenges explique les méthodes de validation de base.

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 ?

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 de véritables certificats wildcard, la méthode externe 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.
• Accès DNS et autorisation de créer des enregistrements TXT disponibles.
• Certbot installé de manière cohérente.
• Challenge DNS-01 validé avec succès.
• Fichiers du certificat et clé privée stockés en sécurité.
• Système cible et format d’importation requis connus.
• Renouvellement planifié avec un responsable, un rappel ou une automatisation DNS.
• 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