Configurer les certificats Sophos Firewall Let's Encrypt

Avec les certificats Let’s Encrypt sur Sophos Firewall, il est possible de créer des certificats HTTPS publics directement sur le firewall et de les renouveler automatiquement. C’est particulièrement pratique pour les publications WAF, WebAdmin, User Portal, VPN Portal comme interface web, Captive Portal, SPX Portal, les pages de connexion Hotspot et les configurations SMTP TLS.

La fonction réduit le travail manuel de certification, mais ne remplace pas une planification appropriée. DNS, accessibilité publique, port 80, noms de certificats, règles WAF, accès au portail et surveillance doivent correspondre. Si la validation ou le renouvellement échoue inaperçu, un portail ou une application Web publiée peut soudainement échouer avec un avertissement de certificat alors que la règle WAF est correcte.

Il est important de distinguer le certificat de portail du certificat VPN: un certificat Let’s Encrypt peut sécuriser proprement un VPN Portal dans le navigateur. Pour Remote Access VPN, Site-to-Site VPN et Chromebook SSO, Sophos mentionne en revanche des limitations. Ces cas doivent être planifiés séparément.

Le chemin réseau a également une limite claire : la fonction Let’s Encrypt intégrée n’est pas prise en charge sur IPv6 dans la matrice SFOS 22 actuelle. L’émission et le renouvellement nécessitent donc un chemin IPv4 fonctionnel. Prise en charge et limites d’IPv6 sur Sophos Firewall avec SFOS 22 classe les autres limites du produit.

Pour la publication proprement dite d’un serveur web, Sophos Firewall WAF: publier des serveurs web en sécurité est le bon point de départ. Cet article se concentre sur la partie certificat et l’exploitation de Let’s Encrypt sur le firewall.

Quand Let’s Encrypt a du sens sur le pare-feu

La méthode intégrée Let’s Encrypt a du sens si le Sophos Firewall lui-même fournit le service public ou se tient devant lui en tant que proxy inverse.

• WAF / Web Server Protection: applications HTTPS accessibles publiquement avec leur propre FQDN.
• WebAdmin: accès administratif avec un certificat propre lorsque WebAdmin est utilisé en externe ou en interne via FQDN.
• User Portal / VPN Portal: les utilisateurs se connectent à un portail HTTPS ou téléchargent des configurations; ce n’est pas la même chose que le certificat du tunnel VPN lui-même.
• Captive Portal / Hotspot: les utilisateurs voient une page de connexion HTTPS sans avertissement de certificat.
• SMTP TLS: Configuration de Mail Protection ou SMTP TLS avec certificat public.

Tous les services ne correspondent pas à cette voie. Pour les certificats wildcard ou les certificats devant être utilisés sur plusieurs systèmes en dehors du pare-feu, un certificat généré en externe est souvent préférable. L’émission est expliquée dans Créer un certificat wildcard Let’s Encrypt ; l’importation du certificat et son attribution sur Sophos Firewall sont décrites séparément.

Limites et différences importantes

Sophos Firewall crée des certificats Let’s Encrypt pour des noms de domaine complets spécifiques. L’intégration n’est pas la même qu’un client ACME géré librement sur un serveur Linux.

Points importants :

• Le domaine doit être spécifié comme un FQDN complet.
• Les domaines génériques ne conviennent pas au processus de pare-feu intégré.
• Les adresses IP ne sont pas des noms de certificat valides pour la validation HTTP-01.
• La validation du domaine HTTP doit pouvoir atteindre le pare-feu via le port 80.
• Le firewall crée temporairement une règle WAF pour la validation et la supprime à nouveau après validation réussie.
• Pendant cette validation, les applications web existantes protégées par des règles WAF peuvent être brièvement inaccessibles via le firewall.
• Remote Access VPN, Site-to-Site VPN et Chromebook SSO ne doivent pas être planifiés avec ce chemin de certificat.
• Les certificats sont valables 90 jours; le firewall tente le renouvellement automatique lorsqu’il reste moins de 30 jours de validité.
• Si l’enregistrement Let’s Encrypt est supprimé sur le firewall, les certificats existants ne sont plus renouvelés.

Sophos a introduit la fonctionnalité avec SFOS 21. La classification Avanet des innovations de l’époque se trouve dans le billet de blog Sophos Firewall v21 : les innovations les plus importantes. Plusieurs correctifs WAF et Let’s Encrypt sont répertoriés dans les notes de version récentes. Pour les environnements productifs, cela signifie que l’état du micrologiciel, l’état du certificat et le fonctionnement du WAF doivent être vérifiés ensemble et non isolément.

Exigences

Avant de créer un certificat, ces points doivent être clarifiés :

• Le pare-feu fonctionne sur une version SFOS avec le support Let’s Encrypt.
• Chaque nom DNS du certificat est résoluble publiquement.
• Les réponses DNS publiques pointent partout de manière cohérente vers l’adresse WAN ou vers une adresse IP qui route le port 80 vers le firewall.
• DNS ne doit pas renvoyer des cibles différentes selon la région. Des DNS checkers publics depuis plusieurs régions aident à détecter les problèmes de Split-Brain DNS ou GeoDNS avant la demande.
• Par nom, une seule adresse IP publique pertinente doit normalement répondre. Plusieurs A-Records ne sont propres que si toutes les cibles impliquées transmettent de façon fiable le trafic HTTP sur le port 80 vers le firewall.
• Le port 80 est accessible en externe pour la validation HTTP.
• Il n’y a pas de règle DNAT, WAF ou autre active sur l’IP publique concernée et le port 80 qui intercepte la demande de validation vers un autre système.
• Les filtres GeoIP, firewalls en amont, filtres fournisseur et routes SD-WAN ne bloquent pas la validation.
• Le pare-feu peut communiquer lui-même sur Internet.
• La date, l’heure et le NTP du pare-feu sont corrects.
• Pour un service ultérieur, il est clair si le certificat est utilisé dans WAF, WebAdmin, Portal ou SMTP TLS.
• Un propriétaire vérifie régulièrement l’expiration du certificat, l’état de renouvellement et les services concernés.

⚠️ Let’s Encrypt n’est pas une solution de contournement pour une accessibilité publique mal maîtrisée. Si le port 80 est bloqué par une ancienne règle DNAT, une autre règle WAF, GeoIP, un NAT en amont ou un filtre fournisseur, la demande ou le renouvellement du certificat peut échouer.

Planifier les noms de certificats

Avant la configuration technique, il convient de déterminer quels noms d’hôtes sont réellement nécessaires. Une bonne planification des certificats évite les corrections ultérieures des règles WAF, des portails et du DNS.

Exemples :

• portal.example.com: Portail utilisateur ou portail VPN.
• vpn.example.com: Chemin de téléchargement du portail VPN ou du VPN SSL.
• admin.example.com: WebAdmin, si utilisé en externe ou via la gestion FQDN.
• app.example.com: Application publiée par WAF.
• mail.example.com: SMTP TLS ou protection du courrier.

Si vous avez plusieurs applications, ne vous précipitez pas pour tout regrouper dans un seul certificat. Un certificat avec de nombreux noms peut être pratique, mais il augmente également les dépendances. Lorsqu’un certificat est renouvelé, remplacé ou annulé, tous les noms d’hôte qu’il contient sont affectés.

Pour les règles WAF, il est également important que le DNS, le certificat, les domaines de la règle WAF et le SNI correspondent. Les bases de WAF sont décrites dans Sophos Firewall WAF : publiez des serveurs Web en toute sécurité.

Créer le compte Let’s Encrypt et le certificat

La configuration se fait dans le WebAdmin dans la zone Certificats. Selon la version SFOS, la représentation exacte peut varier légèrement, mais le processus reste similaire.

Enregistrer le compte

Le firewall est d’abord enregistré auprès de Let’s Encrypt.

1. Ouvrir Certificates > Let’s Encrypt.
2. Vérifier le Subscriber Agreement et les conditions.
3. Cliquer sur Register account.
4. Contrôler que l’enregistrement est actif sans avertissement.

Si Let’s Encrypt modifie ses conditions, l’enregistrement doit être confirmé à nouveau. Sinon, les certificats existants ne sont plus renouvelés et de nouveaux certificats ne peuvent plus être créés. En pratique, ce message relève donc de la revue régulière du firewall, pas d’une note à traiter plus tard.

Sophos Firewall signale notamment les conditions modifiées par e-mail administrateur et dans Control Center. Ces indications ne doivent pas être traitées comme de simples informations: sans nouvelle confirmation, l’exploitation automatique des certificats s’arrête.

Demander le certificat

Le certificat proprement dit est ensuite créé.

1. Ouvrir Certificates > Certificates.
2. Cliquer sur Add.
3. Dans Action, sélectionner Request Let’s Encrypt certificate.
4. Attribuer un nom parlant, par exemple le-app-example-com.
5. Sous Domains, saisir les FQDN souhaités, par exemple app.example.com.
6. Sous Hosted address, sélectionner l’adresse WAN publique vers laquelle pointent ces domaines.
7. Vérifier que le port 80 pointe réellement de l’extérieur vers le firewall.
8. Cliquer sur Save.
9. Après quelques minutes, vérifier sous Certificates > Certificates que le certificat apparaît comme fiable et possède une date Valid until valide.

Lors de la validation, le pare-feu utilise le mécanisme de défi-réponse HTTP. Pour ce faire, les systèmes externes Let’s Encrypt doivent pouvoir accéder au chemin de validation. Si le pare-feu se trouve derrière un routeur, un équilibreur de charge ou un fournisseur NAT, la redirection doit pointer vers le pare-feu.

Si le nom de domaine est invalide ou n’existe pas, la correction n’est souvent pas un simple edit sur le CSR existant, selon l’état. Il est généralement plus propre de supprimer la demande erronée et de la recréer avec le FQDN corrigé.

Utiliser le certificat

Après l’émission, le certificat est seulement disponible. Il ne protège un service que lorsqu’il y est activement sélectionné.

Mission type :

• WAF: vérifier la règle WAF concernée sous Rules and policies > Firewall rules.
• WebAdmin: vérifier le certificat de la console WebAdmin dans les paramètres proches d’Administration / Device Access.
• User Portal / VPN Portal: vérifier la configuration du portail ou du VPN Portal.
• Captive Portal / Hotspot: vérifier la page de connexion et le certificat du portail.
• SMTP TLS: vérifier la configuration e-mail ou SMTP TLS.

Après la mission, vous devez non seulement enregistrer dans WebAdmin, mais également tester le service en externe. Pour les publications WAF, un test effectué en dehors de votre propre réseau local est approprié, car la vue DNS interne, le bouclage NAT ou le cache du navigateur peuvent autrement fournir une fausse sécurité.

Test de mise en ligne

Un test de mise en service réussi comprend DNS, TLS, les fonctionnalités du service et la journalisation.

Liste de contrôle :

• Le FQDN se résout publiquement à l’adresse attendue.
• Le port 80 est accessible au firewall lors de la validation.
• Le port 443 ou le port HTTPS utilisé délivre le nouveau certificat.
• Le navigateur n’affiche pas d’avertissement de certificat.
• Le certificat contient le nom d’hôte attendu.
• La date d’expiration correspond au certificat nouvellement créé.
• En plus du certificat serveur, le service délivre les certificats intermédiaires nécessaires.
• La règle WAF, le portail ou WebAdmin utilise réellement ce certificat.
• Log Viewer n’affiche aucune erreur notable de WAF, de portail ou de certificat.
• Pour les versions WAF, reverseproxy.log correspond à l’heure du test.

Un simple test TLS externe peut également montrer quel certificat est réellement délivré. Il est important d’effectuer le test depuis l’extérieur du réseau client, et pas seulement depuis le client interne.

Vérifier la chaîne de certificat

Après avoir basculé vers un nouveau certificat Let’s Encrypt, non seulement le nom commun ou l’entrée SAN doit être vérifié. Il est également crucial que le client voie la chaîne complète des certificats. Si un navigateur, une application ou un système de surveillance signale une chaîne incomplète, la cause peut être la sélection du certificat, un ancien certificat importé, une règle WAF incorrecte ou un proxy inverse intermédiaire.

En pratique, il faut vérifier ces points:

• Le test HTTPS externe affiche le FQDN attendu sans avertissement de certificat.
• Le certificat délivré est en réalité le nouveau certificat Let’s Encrypt du Sophos Firewall.
• La chaîne de certificats est complète et n’est pas remplacée par un ancien certificat backend ou proxy.
• La règle WAF, le portail ou WebAdmin utilisent le même certificat visible dans le test externe.
• Si un équilibreur de charge amont, un routeur ou un proxy inverse est impliqué, aucun autre certificat n’y sera délivré.

Cette vérification est particulièrement importante si le même domaine a déjà été exécuté via une publication différente, ou si plusieurs règles WAF, règles DNAT ou proxys externes utilisent le même nom d’hôte. Sinon, vous verrez un certificat valide dans WebAdmin, tandis que les clients extérieurs recevront toujours une chaîne différente ou incomplète.

Vérifier les chaînes YE et YR après un renouvellement

Les certificats Let’s Encrypt nouvellement émis peuvent être signés via YE1, YE2, YR1 ou YR2. SFOS 22.0 MR2 Build 546 a ajouté la prise en charge de ces nouveaux certificats racine et intermédiaires. Pour la livraison incomplète de la chaîne suivie sous la référence NC-181671, Sophos a également confirmé le déploiement d’un hotfix sur tous les appliances, sans toutefois indiquer un numéro de version unique pour ce hotfix. La vérification de la chaîne réellement délivrée depuis l’extérieur reste donc déterminante : un certificat valide dans WebAdmin ne prouve pas que WAF, le portail ou WebAdmin envoie tous les certificats intermédiaires requis.

Un symptôme typique apparaît juste après un renouvellement : le navigateur fonctionne, mais curl, une application Go, un système de supervision ou un appareil mobile ancien signale unable to get local issuer certificate ou certificate signed by unknown authority. Deux causes différentes sont possibles :

• Le firewall délivre une chaîne incomplète. Il manque au moins un certificat intermédiaire requis entre le certificat serveur et l’ancre de confiance.
• Le client ne fait pas confiance à l’ancre de confiance. La chaîne délivrée est complète, mais le magasin de confiance du système d’exploitation, du conteneur ou de l’application est obsolète.

Depuis un poste d’administration externe, cette commande en lecture seule affiche les certificats réellement envoyés par le service. Remplacer app.example.com par le FQDN à vérifier :

openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null

La sortie doit contenir le certificat de app.example.com ainsi que les certificats intermédiaires nécessaires à sa chaîne. La dernière ancre de confiance racine n’est normalement pas envoyée par le serveur ; elle doit être présente dans le magasin de confiance du client. Si la sortie contient uniquement le certificat serveur ou s’il manque un certificat intermédiaire, le problème se situe du côté de la livraison. Si la chaîne est complète mais que seuls certains clients échouent, vérifier les paquets CA de leur système d’exploitation, de leur environnement d’exécution ou de leur conteneur.

En complément, curl teste la même URL avec le magasin de confiance du poste concerné :

curl -Iv https://app.example.com/

Le bon fonctionnement du navigateur ne constitue pas à lui seul une preuve suffisante, car les navigateurs peuvent mettre en cache les certificats intermédiaires ou les valider différemment. Si le test externe renvoie un certificat différent de celui attendu, vérifier d’abord l’affectation du certificat dans la règle WAF ou le portail, ainsi que les proxys et les équilibreurs de charge placés en amont.

Pour établir la chronologie, consulter d’abord le journal Let’s Encrypt dans Advanced Shell. Arrêter la sortie avec Ctrl+C :

tail -f /log/letsencrypt.log

letsencrypt.log indique l’émission et le renouvellement. Pour les opérations générales sur les certificats, utiliser tail -f /log/vpncertificate.log ; pour le fonctionnement de WAF, utiliser tail -f /log/reverseproxy.log. Les journaux ne remplacent pas le test externe de la chaîne, mais ils aident à corréler dans le temps le renouvellement, le changement de certificat et le premier accès en échec.

Si la chaîne reste incomplète après vérification de l’affectation du service, de la version actuelle du firmware et des hotfixes disponibles, contacter Sophos Support en indiquant la référence NC-181671. Fournir la version et le build de SFOS, le service concerné, le FQDN, l’issuer, l’heure, la sortie de openssl et le message d’erreur exact du client. Ne pas supprimer de fichiers CA sur la base d’une simple suspicion, importer en bloc tous les certificats Let’s Encrypt ni redémarrer WAF sans procédure de retour documentée.

Suivre le renouvellement dans l’entreprise

Les certificats Let’s Encrypt sont valables 90 jours. La force de l’intégration est que le firewall peut effectuer le renouvellement automatiquement dès qu’un certificat a moins de 30 jours de validité restante. Néanmoins, il ne faut pas laisser le processus fonctionner à l’aveugle.

Ces points doivent être vérifiés régulièrement lors d’un audit d’entreprise :

• Le pare-feu fonctionne-t-il sur une version actuelle et stable de SFOS ?
• Le certificat est-il toujours valable ?
• Le renouvellement automatique a-t-il réussi ?
• Le port 80 est-il toujours accessible pour validation ?
• Existe-t-il de nouvelles règles DNAT ou WAF qui pourraient bloquer la validation ?
• L’enregistrement Let’s Encrypt est-il toujours actif et les conditions modifiées ont-elles été confirmées?
• Les utilisateurs ou la surveillance affichent-ils des avertissements de certificat ?
• Y a-t-il des erreurs WAF ou portail dans la visionneuse de journaux ?

Cette vérification est particulièrement importante après les mises à niveau du pare-feu, les modifications du WAF, les changements de fournisseur, les modifications du DNS et les modifications des routeurs en amont ou des proxys inverses.

Erreurs typiques

• Le certificat n’est pas créé: Le nom de domaine complet ne pointe pas vers le pare-feu ou le port 80 n’est pas accessible. Vérifiez la résolution DNS publique et le test du port externe.
• La demande de certificat échoue après le changement du WAF: règle existante intercepte la validation HTTP. Vérifiez les règles DNAT, WAF et Firewall sur le port 80.
• La validation échoue selon le pays d’origine: GeoIP, des filtres en amont ou SD-WAN peuvent bloquer certains objectifs de validation. Pour l’émission, le port 80 ne doit pas être accessible uniquement depuis son propre pays.
• DNS renvoie des IP différentes selon la région: Let’s Encrypt ne valide pas nécessairement depuis la région de l’administrateur. Les réponses DNS publiques doivent pointer globalement vers un chemin qui amène le port 80 au firewall.
• Plusieurs A-Records pointent vers des systèmes différents: la validation peut atteindre au hasard une cible qui ne transmet pas le challenge vers le firewall. Simplifier DNS ou s’assurer que toutes les cibles routent correctement le chemin HTTP challenge.
• L’application WAF est brièvement indisponible pendant l’émission: le firewall utilise temporairement une mécanique WAF pour la validation. Les publications critiques ne doivent donc pas être modifiées dans une fenêtre de production non planifiée.
• Le certificat est créé, mais le navigateur affiche l’ancien certificat: Le service utilise un autre certificat. Vérifier la sélection de la règle WAF, du portail ou du certificat WebAdmin.
• Navigateur ou rapports de surveillance chaîne de certificat incomplète: Mauvais certificat actif, la chaîne n’est pas livrée complètement ou le proxy en amont délivre un certificat différent. Comparez le test TLS externe, la règle WAF, le mappage de portail et les proxys possibles.
• Le navigateur fonctionne, mais curl, Go ou la supervision échoue après le renouvellement : vérifier depuis l’extérieur si tous les certificats intermédiaires requis sont délivrés. Si la chaîne du serveur est complète, mettre à jour le magasin de confiance du client concerné ; si elle est incomplète, vérifier le niveau du firmware et des hotfixes et, si nécessaire, citer NC-181671 auprès de Sophos Support.
• L’application WAF ne fonctionne pas correctement après un changement de certificat: Le SNI, le domaine, l’hôte back-end ou le profil de protection ne correspondent pas. Vérifiez les règles WAF, les domaines, reverseproxy.log et les journaux backend.
• Le renouvellement ne fonctionne pas: Le chemin de validation a changé depuis la création. Vérifiez le DNS, le port 80, le NAT en amont et l’état du micrologiciel.
• Le renouvellement s’arrête après des conditions modifiées: si le Let’s Encrypt Subscriber Agreement doit être confirmé à nouveau, les nouveaux certificats et renouvellements restent bloqués jusqu’à ce que Register account soit confirmé.
• Les certificats ne sont plus renouvelés après deregistration: si le compte Let’s Encrypt a été désenregistré sur le firewall, il faut vérifier l’état du compte avant le certificat individuel.
• Le certificat doit être utilisé pour Remote Access VPN ou Site-to-Site VPN: ce n’est pas l’usage pris en charge de cette intégration. Pour les certificats VPN, un chemin de certificat séparé doit être planifié.
• Le centre de contrôle affiche un avertissement WAF ou certificat: ancienne règle WAF, redémarrage du WAF ou statut du certificat problématique. Vérifiez la visionneuse de journaux, les règles WAF et la liste des certificats.

Si le WAF et le certificat sont bien visibles ensemble, vous ne devez pas vous contenter de regarder le certificat. La correspondance WAF, l’adresse hébergée, les domaines, le SNI et l’accessibilité du backend appartiennent à la même chaîne d’erreurs.

Planifier le rollback

Pour les portails publics et les applications WAF, il doit être clair comment revenir en arrière avant de modifier un certificat.

Préparation utile :

• ne supprimez pas immédiatement le certificat précédent
• Documenter la règle WAF concernée et la configuration du portail
• Avoir un accès aux tests externes disponible
• Connaître DNS TTL si les noms d’hôte sont modifiés
• Sélectionnez les fenêtres de maintenance pour les portails critiques
• Préparer les communications des utilisateurs si un portail est affecté

Si le nouveau certificat a été créé, mais qu’un service ne fonctionne pas correctement, vous pouvez généralement sélectionner à nouveau le certificat précédent. Cependant, si la cause est une validation HTTP bloquée, une restauration du certificat ne sera utile qu’à court terme. Ensuite, le chemin de validation doit être corrigé, sinon le prochain renouvellement échouera à nouveau.

Liste de contrôle

• FQDN et services documentés.
• Résolution DNS publique vérifiée.
• Le port 80 a été vérifié pour la validation HTTP.
• Conflits avec DNAT, WAF, GeoIP, SD-WAN ou NAT amont vérifiés.
• Compte Let’s Encrypt enregistré et conditions modifiées confirmées.
• Certificat Let’s Encrypt créé.
• Certificat attribué au bon service.
• Test HTTPS externe effectué avec une chaîne complète et plusieurs types de clients.
• Log Viewer et WAF reverseproxy.log vérifiés.
• Responsabilité et suivi du renouvellement définis.
• L’ancien certificat n’est supprimé qu’après une opération réussie.

FAQ