Créer un certificat générique Let's Encrypt

Un certificat Wildcard Let’s Encrypt est utile si plusieurs sous-domaines doivent être sécurisés avec un certificat commun, par exemple app.example.com, vpn.example.com et portal.example.com. Cela peut être utile pour Sophos ZTNA, les proxys inverses, les environnements de test ou plusieurs services Web internes.

Ce qui est important, c’est l’attente : les certificats Let’s Encrypt sont de courte durée. L’avantage ne réside pas dans le long terme, mais dans la gratuité de l’émission et l’automatisation. Si le certificat est créé manuellement à l’aide d’une entrée DNS TXT, le renouvellement ultérieur doit être planifié consciemment.

Si le certificat doit être créé directement sur un Sophos Firewall pour WAF, WebAdmin ou portails, la méthode du pare-feu intégré est généralement meilleure : Configurer les certificats Sophos Firewall Let’s Encrypt. Cet article décrit la route générique externe avec Certbot.

Quand un certificat générique a du sens

Un certificat générique couvre un niveau inférieur à un domaine. Ainsi, *.example.com convient à portal.example.com, mais pas automatiquement à example.com lui-même et pas non plus à a.b.example.com.

• Plusieurs sous-domaines sous la même zone: Le certificat Wildcard peut simplifier l’administration.
• Un seul service public: un seul certificat FQDN est souvent plus propre.
• Le certificat doit être utilisé sur plusieurs systèmes: Le certificat Wildcard peut être pratique, mais contrôle strictement la distribution des clés.
• Renouvellement entièrement automatique requis: Planifier un fournisseur DNS avec le plugin Certbot ou un autre client ACME.
• Sophos Firewall est uniquement destiné à sécuriser WAF/WebAdmin/Portals: Pare-feu intégré Vérification Let’s Encrypt.

Un certificat générique ne constitue pas un gain de sécurité en soi. En fait, si la même clé privée se trouve sur plusieurs systèmes, l’impact d’une perte de clé augmente. Par conséquent, il convient de documenter où le certificat a été importé et qui gère la clé privée.

Exigences

Pour un certificat générique, vous avez besoin de :

• votre propre zone de domaine ou de sous-domaine
• Accès aux enregistrements DNS TXT du domaine
• un serveur Linux ou un ordinateur administrateur avec Certbot
• Autorisation d’exécuter Certbot avec les privilèges root
• un plan de renouvellement, d’importation et de stockage des clés
• Accès au système cible, par exemple Sophos Central ZTNA, proxy inverse ou pare-feu

Les certificats Wildcard sont validés via le DNS-01 Challenge. Un enregistrement TXT est défini sous _acme-challenge.example.com. Let’s Encrypt vérifie cette entrée DNS puis émet le certificat. Let’s Encrypt décrit les types de défis de base dans la Documentation sur les types de défis.

Installer Certbot

La Page du projet Certbot recommande l’installation via Snap pour de nombreux environnements Linux. Sur un système Linux approprié, le processus de base ressemble à ceci :

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

Si Certbot a déjà été installé via apt, dnf ou un autre package, vous devez vérifier au préalable quel Certbot est réellement utilisé. Sinon, plusieurs chemins d’installation parallèles conduisent rapidement à des versions incorrectes ou à des tâches de renouvellement inattendues.

Créer manuellement un certificat générique

Pour la validation DNS manuelle, Certbot peut être démarré avec --manual et --preferred-challenges dns. Dans l’exemple, le certificat doit s’appliquer à 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. Si example.com et *.example.com sont demandés en même temps, Certbot crée deux défis DNS-01 distincts. Les deux valeurs TXT doivent être ajoutées comme enregistrements TXT séparés sous _acme-challenge.example.com. Ajoutez donc le deuxième enregistrement en plus du premier, sans le remplacer.

Ce n’est que lorsque toutes les entrées DNS sont visibles dans le monde entier qu’il faut confirmer dans Certbot et poursuivre la validation.

Vérification pratique :

dig TXT _acme-challenge.example.com @1.1.1.1

• certainement: Demander ou renouveler un certificat sans l’installer.
• --manual: La valeur DNS est définie manuellement.
• --preferred-challenges dns: Utiliser le défi DNS-01.
• -d example.com: Ajouter un domaine racine supplémentaire.
• -d '*.example.com': Inclure le domaine générique.

Le domaine racine et le domaine générique sont des noms distincts. Si seul *.example.com est demandé, example.com lui-même n’est pas automatiquement inclus. Si les deux noms sont demandés en même temps, plusieurs enregistrements TXT avec le même nom peuvent être nécessaires. C’est autorisé dans DNS et c’est précisément là que les validations échouent souvent, parce qu’une valeur TXT existante est remplacée par erreur.

Rechercher des fichiers de certificat

Une fois l’émission réussie, les fichiers se trouvent généralement à l’adresse :

/etc/letsencrypt/live/example.com/

Fichiers importants :

• fullchain.pem: Certificat incluant les certificats intermédiaires.
• cert.pem: juste le certificat du serveur.
• privkey.pem: clé privée.
• chain.pem: Certificats intermédiaires.

De nombreux systèmes cibles nécessitent fullchain.pem et privkey.pem. Certains masques d’importation nécessitent le certificat et la clé séparément, d’autres nécessitent également la chaîne. Avant l’importation, il convient de préciser le format attendu par le système cible.

⚠️ privkey.pem est la clé privée. Ce fichier ne doit pas se retrouver dans des tickets, des chats, des e-mails ou dans un stockage non sécurisé. Toute personne possédant la clé privée peut abuser du certificat.

Renouvellement du forfait

La méthode manuelle --manual est simple pour les tests et les actions individuelles, mais n’est que partiellement adaptée aux certificats productifs. Sans automatisation, un nouvel enregistrement DNS TXT doit être défini à chaque renouvellement.

Il existe trois variantes propres pour une utilisation productive :

• Plugin DNS pour le fournisseur DNS: si Certbot est autorisé à définir des enregistrements DNS via l’API.
• un autre client ACME avec automatisation DNS: si le fournisseur ou la plateforme est mieux pris en charge.
• renouvellement manuel avec calendrier et propriétaire: uniquement pour les tests ou les certificats rarement utilisés.

Lorsque l’accès à l’API DNS est utilisé, les informations d’identification de l’API sont particulièrement critiques. Un jeton DNS ne doit être autorisé à modifier que la zone nécessaire et, si possible, uniquement les types d’enregistrement nécessaires. L’accès administrateur de domaine étendu n’appartient pas sans protection sur un serveur Web.

Un test de renouvellement est généralement vérifié avec Certbot comme ceci :

sudo certbot renew --dry-run

Pour les certificats DNS créés manuellement, ce test n’a de sens que si le processus DNS est également automatisé ou si les hooks manuels fonctionnent correctement.

Importer dans les environnements Sophos

Si le certificat est utilisé pour Sophos ZTNA, un pare-feu, un proxy inverse ou un autre système lié à Sophos, vous devez vérifier ces points avant d’importer :

• Le nom du certificat correspond-il au nom d’hôte public ?
• Le domaine racine est-il requis en plus du caractère générique ?
• Le système cible attend-il fullchain.pem ou des composants de certificat distincts ?
• La clé privée est-elle acceptée ou doit-elle être convertie dans un autre format ?
• Existe-t-il un processus documenté pour le prochain renouvellement ?
• Est-il clair sur quels systèmes le même certificat a été importé ?

Lorsqu’il s’agit uniquement de WAF, WebAdmin ou de portails sur Sophos Firewall, le processus de pare-feu intégré est souvent plus simple car la création et le renouvellement s’effectuent directement sur le pare-feu. Cependant, la route externe Certbot ou ACME reste pertinente pour les vrais certificats génériques.

Erreurs typiques

• La validation échoue: Enregistrement TXT pas encore visible, nom de zone DNS incorrect ou l’une des valeurs TXT a été écrasée. dig TXT _acme-challenge.example.com @1.1.1.1 vérifier.
• Le certificat ne s’applique pas à example.com: uniquement *.example.com demandé. Ajoutez également un domaine racine avec -d example.com.
• Le certificat ne s’applique pas à a.b.example.com: Wildcard ne couvre qu’un seul niveau de sous-domaine. planifiez votre propre certificat ou un joker approprié pour une zone plus profonde.
• Le renouvellement ne fonctionne pas automatiquement: manière DNS manuelle sans automatisation. Vérifiez le plugin DNS ou un autre client ACME.
• L’importation échoue: mauvais fichier ou format. fullchain.pem, cert.pem, privkey.pem et comparaison de la demande de chaîne.
• Risque de sécurité dû aux copies de clés: la clé privée est sur plusieurs systèmes. Emplacements de stockage, d’accès et d’importation de documents.

Liste de contrôle

• Ensemble de niveaux de domaine et de sous-domaine.
• Domaine racine et joker délibérément sélectionnés.
• Accès DNS et autorisation d’enregistrement TXT disponibles.
• Certbot installé proprement.
• Le défi DNS-01 a été vérifié avec succès.
• Fichiers de certificat et clé privée stockés en toute sécurité.
• Système cible et format d’importation requis connus.
• Renouvellement programmé avec automatisation du propriétaire, du calendrier ou du DNS.
• Les anciens certificats et clés sont supprimés de manière contrôlée après une conversion réussie.

##FAQ