Configurer les certificats Sophos Firewall Let's Encrypt

Avec Les certificats Let’s Encrypt sur Sophos Firewall, vous pouvez créer des certificats HTTPS publics directement sur le pare-feu et les renouveler automatiquement. Ceci est particulièrement utile pour la publication WAF, WebAdmin, le portail utilisateur, le portail VPN, le portail captif, le portail SPX, 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.

Pour la publication proprement dite d’un serveur Web, Sophos Firewall WAF: publiez des serveurs Web en toute sécurité convient en premier. Cet article se concentre sur le côté certificat et le fonctionnement de Let’s Encrypt sur le pare-feu.

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.

Tous les services ne correspondent pas à cette voie. Pour les certificats génériques 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. Il existe l’article existant Créer un certificat générique Let’s Encrypt.

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.
• La validation du domaine HTTP doit pouvoir atteindre le pare-feu via le port 80.
• Le pare-feu crée un serveur Web temporaire ou des composants WAF pour validation.
• Après une émission réussie, les composants de validation temporaires sont à nouveau supprimés.
• Les certificats sont de courte durée et doivent être renouvelés automatiquement.

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.
• Le nom DNS public pointe vers l’adresse WAN ou l’adresse hébergée du pare-feu.
• Le port 80 est accessible en externe pour la validation HTTP.
• Il n’y a pas de règle DNAT, WAF ou autre active qui intercepte la demande de validation sur le port 80.
• 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 impure. Si le port 80 est bloqué par une ancienne règle DNAT, une autre règle WAF, un NAT en amont ou un filtre de fournisseur, la demande ou le renouvellement du certificat peut échouer.

Planifier les noms de certificatsAvant 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 :

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 un compte et un certificat Let’s Encrypt

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.

Processus de base :

1. Ouvrez Certificats.
2. Ouvrez la zone Let’s Encrypt ou la demande de certificat.
3. Préparez le compte Let’s Encrypt sur le pare-feu.
4. Saisissez les FQDN souhaités.
5. Sélectionnez l’interface WAN ou l’adresse publique pour la validation HTTP.
6. Vérifiez si le port 80 pointe vers le pare-feu de l’extérieur.
7. Demander un certificat.
8. Une fois l’émission réussie, vérifiez sous Certificats > Certificats si le certificat est présent et 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.

Utiliser le certificat

Une fois délivré, le certificat n’existe plus. Il ne protège un service que lorsqu’il y a été activement sélectionné.

Mission type :

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éé.
• 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, vous devriez vérifier ces points :- Le test HTTPS externe affiche le nom de domaine complet 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.

Suivre le renouvellement dans l’entreprise

Les certificats Let’s Encrypt sont de courte durée. La force de l’intégration est que le pare-feu peut effectuer le renouvellement automatiquement. Néanmoins, vous ne devez pas laisser le processus se dérouler aveuglément.

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 ?
• 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

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.

Annulation du plan

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 ou NAT amont vérifiés.
• Certificat Let’s Encrypt créé.
• Certificat attribué au bon service.
• Test HTTPS externe effectué.
• 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