Distribuer le certificat CA de Sophos Firewall pour l'inspection TLS

Lorsqu’un Sophos Firewall déchiffre les connexions HTTPS via l’inspection TLS ou le scanning HTTPS, le pare-feu crée un nouveau certificat pour la connexion inspectée et le signe avec une CA locale. Les clients doivent faire confiance à cette CA, sinon des avertissements de navigateur apparaissent ou les applications interrompent la connexion.

Dans Sophos Firewall, la CA intégrée SecurityAppliance_SSL_CA est disponible par défaut. Cette CA peut être téléchargée sous Certificates > Certificate authorities et distribuée aux clients gérés. Il ne suffit toutefois pas qu’une CA Sophos quelconque soit installée sur les clients. La CA distribuée doit correspondre à la CA réellement utilisée pour le re-signing dans la configuration TLS Inspection.

Selon le mode d’exploitation, cette sélection se vérifie à différents endroits : pour les SSL/TLS Inspection Rules basées sur DPI, la CA pertinente se trouve sous Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Pour le Web Proxy, la CA HTTPS Scanning se trouve sous Web > General settings > HTTPS decryption and scanning. Si une autre CA y est sélectionnée que celle à laquelle les clients font confiance, des erreurs de certificat apparaissent même si une CA Sophos a bien été distribuée.

L’article Introduction correcte de l’inspection TLS de Sophos Firewall décrit le déploiement complet. Ce guide se concentre sur la distribution du certificat CA aux systèmes Windows, macOS et Firefox.

Ce que fait ce certificat

Le certificat CA de Sophos Firewall n’est pas un certificat serveur pour WebAdmin, WAF ou le portail VPN. C’est la base de confiance avec laquelle les clients acceptent les connexions HTTPS nouvellement signées par le pare-feu.

Il est important de faire la distinction :

• CA du pare-feu: signe les certificats nouvellement créés lors de l’inspection TLS.
• Re-Signing CA ou HTTPS Scanning CA: la CA concrètement sélectionnée que le pare-feu utilise en mode DPI ou Web Proxy.
• Magasin de confiance du client: décide si les navigateurs et applications font confiance à cette CA.
• Règle d’inspection SSL/TLS: décide quel trafic est déchiffré.
• Profil de déchiffrement: détermine la rigueur du traitement des certificats, versions TLS et erreurs.
• Liste d’exclusion: empêche le déchiffrement pour des cibles problématiques ou intentionnellement exclues.

La distribution de la CA seule n’active donc pas l’inspection TLS. La distribution empêche seulement que les clients gérés affichent des avertissements de certificat pour le trafic HTTPS déchiffré. Que le trafic soit effectivement déchiffré dépend des règles du pare-feu, de la politique Web, des règles d’inspection SSL/TLS, des profils de déchiffrement et des exceptions.

De plus, la distribution de la CA ne remplace pas une gestion propre des protocoles. Les SSL/TLS Inspection Rules s’appliquent au trafic TCP. Si le trafic Web passe par QUIC ou HTTP/3 sur UDP 443, le contrôle suit un autre chemin et doit être traité séparément.

Avant le déploiement

Avant la distribution, il doit être clair quels clients utiliseront l’inspection TLS. Un certificat CA ne doit pas être installé sans contrôle sur chaque appareil, mais ciblé sur les clients d’entreprise gérés.

Préparation :

• Définir un groupe de test ou une unité organisationnelle de test.
• Clarifier le mode d’exploitation : mode DPI, Web Proxy ou les deux variantes.
• Documenter la CA sélectionnée dans Decryption Profile, SSL/TLS inspection settings et Web General settings.
• Documenter le processus de retour en arrière et d’exception.
• Télécharger le certificat CA uniquement depuis son propre pare-feu.
• Tester la distribution d’abord sur quelques appareils.
• Vérifier les navigateurs, applications professionnelles et mises à jour après la distribution.
• Évaluer séparément les appareils mobiles et applications avec leur propre trust store ou Certificate Pinning.
• Supprimer les anciens certificats CA ou ceux qui ne sont plus utilisés du magasin de confiance du client.

⚠️ Attention : Si la CA ou la clé privée a été compromise, une nouvelle distribution ne suffit pas. La CA doit alors être régénérée sur le pare-feu, redistribuée et l’ancienne CA retirée des clients.

Choisir la méthode de distribution

La méthode de distribution appropriée dépend de la façon dont les appareils sont gérés.

• Clients de domaine Windows: GPO dans Trusted Root Certification Authorities. propre pour les environnements Active Directory classiques.
• Windows sans domaine: MDM, Intune ou importation locale. importation locale uniquement pour les tests ou appareils individuels.
• macOS: Profil MDM ou trousseau System. installation manuelle uniquement pour les tests ou petits environnements.
• Firefox: Utiliser le magasin de confiance Windows ou les politiques d’entreprise Mozilla. le comportement de Firefox doit être vérifié séparément.
• BYOD ou appareils privés: normalement ne pas distribuer. l’inspection TLS doit être sur des appareils d’entreprise gérés.
• Serveurs: uniquement pour les charges de travail serveur intentionnellement inspectées. le trafic sortant des serveurs peut avoir d’autres risques et exceptions.

Pour l’exploitation en production, il est crucial que le même déploiement puisse également être annulé plus tard. Ceux qui distribuent la CA via GPO, MDM ou politique devraient donc également tester le retrait de l’ancienne CA.

Télécharger la CA de Sophos Firewall

Sur le Sophos Firewall, le certificat est téléchargé via l’interface Web :

1. Connectez-vous en tant qu’administrateur sur le Sophos Firewall.
2. Ouvrez Certificates > Certificate authorities.
3. Recherchez la CA SecurityAppliance_SSL_CA ou la CA personnalisée utilisée volontairement.
4. Téléchargez le certificat via l’icône de téléchargement.
5. Vérifiez ensuite si la même CA est sélectionnée dans la configuration TLS Inspection active.

Le certificat est généralement disponible sous la forme SecurityAppliance_SSL_CA.pem. Ce fichier contient la partie publique de la CA et peut être distribué aux clients. La clé privée ne doit pas être distribuée aux clients.

Le fichier doit être traité comme un élément de configuration de sécurité. La partie publique n’est pas un mot de passe, mais elle définit à quelle CA les clients feront confiance à l’avenir. Par conséquent, le fichier doit provenir de votre propre pare-feu de production, être versionné ou au moins stocké de manière traçable et ne pas être réutilisé à partir de projets anciens.

Deux chemins supplémentaires permettent de contrôler la CA active :

• Mode DPI: ouvrir Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings et comparer la CA sélectionnée avec le fichier téléchargé.
• Web Proxy: ouvrir Web > General settings > HTTPS decryption and scanning et contrôler la CA HTTPS Scanning.

Cette vérification évite une erreur de déploiement fréquente : la CA standard est distribuée aux clients alors que le pare-feu utilise déjà une autre CA dans une Decryption Policy ou dans le Web Proxy.

Windows : distribuer le certificat via GPO

Dans les environnements Active Directory, une stratégie de groupe est la méthode la plus propre. Edge, Chrome et de nombreuses applications Windows font confiance au magasin de certificats Windows.

Chemin recommandé dans la gestion des stratégies de groupe :

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procédure :

1. Ouvrez la gestion des stratégies de groupe sur un contrôleur de domaine ou un client administrateur.
2. Utilisez une GPO existante pour la base des clients ou créez une nouvelle GPO pour le groupe de test d’inspection TLS.
3. Accédez au chemin Trusted Root Certification Authorities > Certificates.
4. Faites un clic droit dans la liste des certificats.
5. Sélectionnez All Tasks > Import.
6. Importez SecurityAppliance_SSL_CA.pem.
7. Associez la GPO uniquement à l’unité organisationnelle ou au groupe de sécurité souhaité.
8. Exécutez gpupdate /force sur un client de test ou attendez la mise à jour régulière.

Pour les environnements de production, la GPO ne doit pas être appliquée directement à tous les ordinateurs. Une unité organisationnelle de test réduit le risque si un certificat est mal importé ou si une application réagit de manière inattendue.

Windows : installer le certificat localement

Pour des appareils de test individuels, le certificat peut être importé localement. Il existe deux variantes utiles :

• Local Computer Store : s’applique à tous les utilisateurs de l’appareil et est généralement correct pour les clients gérés.
• Current User Store : s’applique uniquement à l’utilisateur connecté et est parfois suffisant pour les tests.

Pour l’ordinateur local :

1. Connectez-vous en tant qu’administrateur local.
2. Démarrez certlm.msc.
3. Ouvrez Trusted Root Certification Authorities > Certificates.
4. Faites un clic droit dans la liste des certificats.
5. Sélectionnez All Tasks > Import.
6. Importez SecurityAppliance_SSL_CA.pem.

Pour l’utilisateur actuel, certmgr.msc peut être utilisé à la place.

Après l’importation, les navigateurs et applications doivent être redémarrés. Pour certaines applications, une déconnexion ou un redémarrage du client est conseillé.

macOS : faire confiance au certificat dans le trousseau

Sur macOS, le certificat est importé via la gestion du trousseau.

Procédure :

1. Copiez SecurityAppliance_SSL_CA.pem sur le Mac.
2. Ouvrez le certificat par double-clic.
3. Fournissez-le dans le trousseau System ou un profil MDM géré.
4. Ouvrez le certificat et sous Trust, définissez l’entrée Always Trust.
5. Confirmez la modification avec un compte administrateur.
6. Redémarrez les navigateurs et applications concernées.

Dans les environnements macOS plus grands, la distribution devrait se faire via MDM. L’installation manuelle est plutôt destinée aux tests ou appareils individuels.

Vérifier le certificat sur les appareils gérés

Après la distribution, il est conseillé de vérifier sur au moins un appareil de test par plateforme si la CA est bien placée dans le bon magasin de confiance.

• Windows Computer Store: Ouvrez certlm.msc et recherchez sous Trusted Root Certification Authorities > Certificates.
• Windows Current User Store: Ouvrez certmgr.msc et vérifiez le magasin de confiance de l’utilisateur.
• macOS: Ouvrez la gestion du trousseau et vérifiez le statut de confiance dans le trousseau System.
• Firefox: Ouvrez Settings > Privacy & Security > Certificates > View Certificates.

Si un certificat se trouve uniquement dans le magasin de l’utilisateur, mais qu’une application attend le magasin de l’ordinateur, le navigateur peut fonctionner tandis qu’une autre application affiche des erreurs de certificat. Inversement, les navigateurs avec leur propre magasin de confiance peuvent ignorer la distribution Windows ou macOS s’ils ne sont pas configurés en conséquence.

Firefox sous Windows

Firefox peut, selon la configuration, utiliser ses propres magasins de certificats. Dans les environnements Windows, il existe deux méthodes courantes :

• Configurer Firefox pour utiliser les CA racines de Windows.
• Distribuer les certificats via les politiques d’entreprise Mozilla.

La deuxième méthode est utile dans les environnements où Firefox est contrôlé centralement via GPO.

Télécharger les modèles GPO de Firefox

Mozilla fournit les modèles de politique sur GitHub. Les fichiers nécessaires incluent :

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Les fichiers peuvent être téléchargés depuis le Mozilla Policy Templates Repository ou sous forme de policy_templates.zip.

Importer les modèles

Les fichiers ADMX et ADML sont copiés dans le chemin central PolicyDefinitions.

Chemin local typique :

C:\Windows\PolicyDefinitions

Dans un Central Store de domaine, le dossier PolicyDefinitions sous SYSVOL est utilisé à la place.

Configurer la politique Firefox

Dans la stratégie de groupe, le certificat est ensuite inscrit sous les politiques Firefox :

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procédure :

1. Activez la politique Install Certificates.
2. Entrez le nom de fichier du certificat, par exemple SecurityAppliance_SSL_CA.pem.
3. Copiez le fichier de certificat via GPO ou distribution logicielle dans le répertoire de profil utilisateur attendu.

Selon la version de Firefox et la configuration de la politique, les certificats sont lus à partir de ces répertoires :

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Après la prochaine session Firefox, le certificat devrait être visible dans la gestion des certificats de Firefox.

Mozilla documente des chemins et variantes supplémentaires dans le Wiki : Ajouter un certificat racine à Firefox.

Vérifier le fonctionnement

Après la distribution, il ne suffit pas de vérifier si le certificat est présent. Ce qui est crucial, c’est de savoir si l’inspection TLS fonctionne correctement.

Tests utiles :

1. Redémarrez le client de test ou reconnectez l’utilisateur.
2. Ouvrez un navigateur et accédez à une page HTTPS déchiffrée par le Sophos Firewall.
3. Affichez le certificat du site Web dans le navigateur.
4. Vérifiez si la chaîne de certificats passe par SecurityAppliance_SSL_CA ou exactement par la CA Sophos choisie.
5. Sur le pare-feu, vérifiez dans Log Viewer > SSL/TLS inspection si le trafic est affiché comme déchiffré et quelle Rule ou action a été appliquée.
6. Testez les applications professionnelles importantes, les services de mise à jour, les outils de collaboration et les fournisseurs d’identité.

Si le navigateur affiche toujours le certificat public original du site Web, cette connexion n’a pas été déchiffrée. Dans ce cas, soit aucune SSL/TLS Inspection Rule appropriée ne s’applique, soit une exception prévaut, soit le trafic passe par un autre chemin, soit QUIC/HTTP/3 contourne le chemin TCP attendu.

Si l’avertissement du navigateur disparaît mais que les applications continuent de montrer des erreurs, le problème ne vient souvent pas du certificat lui-même. Souvent, le problème est lié au Certificate Pinning, à l’absence d’exceptions TLS, à un profil de déchiffrement incorrect ou à une règle d’inspection SSL/TLS inappropriée.

Pour le trafic Web, il convient également de vérifier si QUIC ou HTTP/3 contourne l’inspection attendue. L’article Bloquer correctement QUIC et HTTP/3 avec Sophos Firewall explique pourquoi Block QUIC protocol reste pertinent pour le filtrage Web, le scanning des malwares et l’inspection TLS.

Erreurs typiques

• Le navigateur affiche toujours un avertissement de certificat: CA non dans le bon magasin de confiance. Vérifiez le magasin de certificats Windows/macOS/Firefox.
• Chrome fonctionne, Firefox non: Firefox utilise son propre magasin de certificats. Vérifiez les politiques Firefox ou la gestion des certificats Firefox.
• Certaines applications échouent: Certificate Pinning ou vérification de certificat propre. Vérifiez le Log Viewer d’inspection TLS et les exceptions.
• Seuls certains clients fonctionnent: GPO ne s’applique pas ou mauvaise unité organisationnelle. Vérifiez gpresult et l’association de la GPO.
• La CA est installée, mais l’avertissement reste affiché: la CA distribuée ne correspond peut-être pas à la CA du Decryption Profile, des SSL/TLS inspection settings ou de Web General settings.
• DPI fonctionne, mais pas Web Proxy, ou inversement: les deux chemins peuvent être configurés différemment. Vérifier la CA choisie, le chemin de règle et Log Viewer pour chaque mode.
• Après régénération de la CA, des avertissements apparaissent: ancienne CA encore sur les clients ou nouvelle CA manquante. retirez l’ancienne CA, distribuez la nouvelle CA.
• Les flux URL ou le filtrage Web ne fonctionnent pas comme prévu: le chemin HTTPS n’est pas déchiffré. Vérifiez l’inspection TLS et la politique Web.
• Le certificat est présent, mais le trafic n’est pas déchiffré: pas de règle d’inspection SSL/TLS appropriée ou chemin DPI/proxy Web incorrect. Vérifiez le déploiement TLS, la règle du pare-feu et le Log Viewer.
• Seules les applications mobiles ou certains clients échouent: magasin de confiance propre, Certificate Pinning ou vérification spécifique à l’application. Le trafic Android et Mobile App en particulier doit être testé de manière ciblée et exclu si nécessaire, au lieu de distribuer la CA largement et sans discernement.

Rotation de la CA et urgence

Une CA ne doit pas être exploitée sans surveillance pendant des années sans que la date d’expiration, l’origine et la distribution soient connues. Pour les environnements de production, il devrait y avoir un petit processus de cycle de vie.

Changement planifié :

1. Préparez une nouvelle CA ou une nouvelle CA de pare-feu.
2. Distribuez la nouvelle CA à un groupe de test.
3. Vérifiez l’inspection TLS avec le groupe de test.
4. Distribuez la nouvelle CA à tous les appareils gérés concernés.
5. Contrôlez les règles du pare-feu et les profils de déchiffrement.
6. Retirez l’ancienne CA uniquement lorsque tous les appareils de production ont reçu la nouvelle CA.

Urgence en cas de compromission :

1. Limitez ou désactivez temporairement l’inspection TLS si nécessaire.
2. Remplacez la CA concernée sur le pare-feu.
3. Déployez la nouvelle CA via la méthode de distribution définie.
4. Retirez l’ancienne CA de tous les magasins de confiance.
5. Vérifiez les exceptions, le Log Viewer et les applications concernées.
6. Documentez le changement dans le système d’incident ou de changement.

Important : Une CA compromise n’est pas un problème de certificat normal. Si un attaquant contrôle la clé privée, les clients peuvent faire confiance à des certificats falsifiés. L’ancienne CA doit alors être retirée de manière conséquente.

Exploitation et maintenance

Le certificat CA doit faire partie du processus d’exploitation :

• Documentez la date d’expiration et les responsables.
• Effectuez la régénération de la CA uniquement de manière planifiée.
• Retirez l’ancienne CA des clients après la migration.
• Vérifiez régulièrement la distribution via GPO ou MDM.
• Documentez les exceptions TLS et passez-les en revue périodiquement.
• Régénérez la CA en cas de perte d’appareil ou de compromission de la CA.

Lors d’un changement d’inspection TLS, il convient également de vérifier les règles du pare-feu, les profils de déchiffrement et les listes d’exclusion concernés. Sinon, le client peut faire confiance à la CA, mais le pare-feu ne déchiffre toujours pas le trafic souhaité.

FAQ