Configurer une autorité de certification subordonnée pour l'inspection TLS de Sophos Firewall

Pour l’inspection TLS, Sophos Firewall doit signer à nouveau les certificats des destinations HTTPS visitées. Au lieu d’utiliser l’autorité intégrée SecurityAppliance_SSL_CA, il est possible d’employer une autorité de certification d’entreprise subordonnée dédiée. Les clients administrés continuent alors de faire confiance à l’autorité racine de l’entreprise, tandis que la clé privée de l’autorité subordonnée reste sur le pare-feu.

La procédure sûre comporte six étapes :

1. Générer sur Sophos Firewall un CSR pour la nouvelle autorité subordonnée.
2. Faire signer le CSR par une Enterprise CA Microsoft AD CS avec le modèle Subordinate Certification Authority.
3. Importer le certificat d’autorité émis directement dans le CSR existant.
4. Ajouter l’autorité racine correspondante au pare-feu comme Validation only.
5. Sélectionner l’autorité subordonnée comme autorité de re-signature et ne l’utiliser d’abord que dans une règle pilote.
6. Vérifier la chaîne de certificats, le trafic HTTPS réel, les journaux et le retour arrière.

⚠️ Une autorité de re-signature peut émettre des certificats pour des domaines tiers. Sa clé privée est donc particulièrement sensible. Cette autorité doit uniquement servir au chemin d’inspection prévu et ne doit être ni exportée ni transmise dans des tickets. Elle ne doit pas être activée en production sans chemin de retour testé.

Cette procédure concerne AD CS en mode Enterprise CA. Sophos indique explicitement que la méthode documentée ne s’applique pas à une Standalone CA. Une autre PKI interne peut également émettre une autorité subordonnée, mais elle nécessite une procédure propre validée par le responsable de la PKI.

Il est également possible de générer le CSR et les autorités avec un outil externe comme OpenSSL. Les autorités subordonnée et racine générées en externe sont téléversées sous Certificates > Certificate authorities ; une autorité de signature sans CSR correspondant sur le pare-feu nécessite aussi sa clé privée via le processus PKI approuvé. La racine reste sans clé privée. Il s’agit d’un autre chemin de transfert des clés, et non de l’importation du CSR décrite ci-dessous. L’autorité subordonnée peut aussi servir aux configurations TLS des e-mails ; l’activation et la validation suivantes concernent uniquement le trafic Web et n’activent aucune configuration TLS de messagerie.

Quand une autorité subordonnée est utile

Une autorité subordonnée dédiée est particulièrement adaptée aux réseaux d’entreprise administrés dans lesquels les clients font déjà confiance à une autorité racine interne. Il n’est alors pas nécessaire de distribuer à chaque appareil une ancre de confiance Sophos supplémentaire et indépendante. La rotation, la révocation et la responsabilité peuvent être intégrées à la gouvernance de la PKI existante.

La solution n’est toutefois pas automatiquement plus simple. Le pare-feu reçoit une clé qui lui permet de signer des certificats pour l’inspection TLS. L’autorité doit donc avoir un usage strictement défini, des responsables documentés, une durée de validité limitée ainsi que des procédures de révocation et de renouvellement testées.

Dans un environnement plus petit sans PKI interne, l’autorité intégrée de Sophos reste souvent la solution la plus simple. Distribuer le certificat d’autorité de Sophos Firewall pour l’inspection TLS explique sa sélection et son déploiement sur les clients. Déployer correctement l’inspection TLS de Sophos Firewall décrit tout le processus de pilote et d’exceptions.

Préparer la conception de l’autorité et le chemin de retour

L’usage, les noms et les dépendances sont définis avant de générer le CSR. Exemple :

• nom de l’objet SFOS : SFOS-TLS-Inspection-SubCA-2026
• Common Name : SFOS TLS Inspection SubCA 2026
• autorité racine émettrice : Example Enterprise Root CA
• usage prévu : uniquement l’inspection TLS et le déchiffrement HTTPS sur FW01
• réseau pilote : 10.20.30.0/24

Ces valeurs sont des exemples de documentation et doivent être remplacées par la convention de nommage, la PKI et le groupe pilote de l’organisation. Une autorité distincte par pare-feu ou cluster d’inspection clairement délimité simplifie ensuite l’affectation, la révocation et la rotation.

Avant la modification, les éléments suivants doivent être disponibles :

• une sauvegarde de configuration actuelle et un accès d’administration indépendant fonctionnel,
• la documentation de l’autorité de re-signature actuelle et de son déploiement sur les clients,
• un accès à une Enterprise CA AD CS et l’autorisation du responsable de la PKI,
• un petit groupe de test administré avec un chemin de retour fonctionnel,
• un plan de révocation, de renouvellement et de retour contrôlé à l’ancienne autorité.

Créer et restaurer une sauvegarde Sophos Firewall explique la procédure de sauvegarde et de restauration. Une sauvegarde ne remplace pas la documentation de l’autorité de re-signature actuellement sélectionnée ni celle des clients qui lui font confiance.

Générer le CSR sur Sophos Firewall

Le CSR est généré sur le pare-feu afin que la clé privée y soit créée et qu’elle n’ait pas à circuler entre AD CS, un poste d’administration et le pare-feu.

1. Ouvrir Certificates > Certificates.
2. Sélectionner Add.
3. Sous Action, sélectionner Generate certificate signing request (CSR).
4. Saisir un nom univoque comme SFOS-TLS-Inspection-SubCA-2026.
5. Choisir le type et la longueur de clé ou la courbe ainsi que le hachage sécurisé selon la politique PKI de l’organisation. Dans son exemple, Sophos utilise RSA, 2048 bits et SHA-256 ; il s’agit d’un exemple produit, pas d’une exigence universelle.
6. Saisir les attributs de sujet et les Subject Alternative Names approuvés par la PKI interne.
7. Enregistrer le CSR et l’ouvrir à l’aide de l’icône de téléchargement.
8. Utiliser Copy to clipboard et transmettre le CSR uniquement via le processus AD CS autorisé.

Le CSR ne contient pas la clé privée. Il fait néanmoins partie du processus PKI contrôlé, car il définit l’identité, la clé publique et l’usage d’autorité demandé.

Sous Subject name attributes, le formulaire CSR contient Country name, State, Locality name, Organization name, Organization unit name, Common name et Email address. Saisir les informations d’identité approuvées par la PKI, et non celles d’un site Web quelconque visité. Subject Alternative Names accepte des noms DNS ou des adresses IP, par exemple web.exampleorg.com, fd12:3456:789a:1:: ou 203.0.113.10. Ces valeurs d’exemple du produit ne sont pas des exigences pour une autorité d’inspection ; définir les SAN avec le responsable de la PKI.

Émettre l’autorité subordonnée avec AD CS

Le CSR Sophos est soumis sur la page d’inscription Web de l’Enterprise CA AD CS responsable :

1. Ouvrir Request a certificate.
2. Sélectionner Advanced certificate request.
3. Coller le CSR complet.
4. Sous Certificate template, sélectionner Subordinate Certification Authority.
5. Contrôler la demande conformément au processus d’approbation interne et l’émettre avec Submit.
6. Sous Certificate Issued, choisir un format adapté, par exemple Base 64 encoded.
7. Sélectionner Download certificate pour télécharger le certificat de l’autorité subordonnée émis.
8. Sur la page d’accueil AD CS, ouvrir Download a CA certificate, sélectionner l’autorité racine qui a signé la subordonnée, puis sélectionner Download CA certificate et Save.

Limite EKU importante : Si le certificat d’autorité émis contient une section Extended Key Usage, celle-ci doit inclure TLS Web Server Authentication pour cet usage de signature. Si cette valeur manque, le certificat ne doit pas être utilisé comme autorité de re-signature en production. Le responsable de la PKI doit corriger le modèle d’autorité et émettre un nouveau certificat.

Avant l’importation, vérifier dans la visionneuse de certificats l’émetteur, le sujet, la validité, Basic Constraints et, le cas échéant, Extended Key Usage. Nommer clairement les fichiers racine et subordonné afin de ne pas les confondre avec des certificats serveur.

Importer les autorités subordonnée et racine

Importer l’autorité subordonnée dans le CSR existant

1. Ouvrir Certificates > Certificates.
2. Sélectionner l’action d’importation du CSR créé précédemment.
3. Choisir le certificat d’autorité subordonnée émis par AD CS.
4. Sélectionner Certificate authority only. SFOS détecte le type d’autorité et affiche les options correspondantes.
5. Contrôler le nom et sélectionner Import certificate.
6. Sous Certificates > Certificate authorities, ouvrir le filtre à côté de Name, saisir le nom de l’autorité et sélectionner Apply.

SFOS associe automatiquement à l’autorité subordonnée la clé privée correspondant au CSR. L’icône de clé privée doit donc être visible pour cette autorité dans la liste. Si elle manque, l’autorité n’est pas prête à signer. L’importation générale sous Certificates > Certificate authorities > Add peut aussi détecter un CSR existant correspondant. L’importation directement depuis le CSR décrite ici rend l’association explicite, mais n’est pas le seul chemin documenté. Sans CSR correspondant ou clé privée, téléverser à nouveau le certificat ne crée pas de clé de signature.

Ajouter l’autorité racine uniquement pour la validation

L’exemple pas à pas de Sophos appelle cet usage Validation, tandis que la référence du champ CA l’appelle Validation only. Le rôle sûr visé ici est identique : certificat racine uniquement pour la validation, sans clé privée racine ; ne pas sélectionner Signing and validation pour la racine. Pour le téléversement, choisir le fichier sous Certificate avec Browse.

1. Ouvrir Certificates > Certificate authorities et sélectionner Add.
2. Téléverser le certificat de l’autorité racine qui a émis l’autorité subordonnée.
3. Sous Use certificate for, conserver Validation only.
4. Comparer le nom et l’empreinte à la documentation approuvée de l’autorité racine.
5. Enregistrer et contrôler à nouveau la chaîne de l’autorité subordonnée.

Le pare-feu n’a pas besoin de la clé privée de l’autorité racine. Signing and validation est réservé à l’autorité subordonnée dont la clé privée se trouve déjà sur le pare-feu grâce au CSR. Importer et affecter des certificats sur Sophos Firewall explique les différences générales entre certificat, CSR, clé privée et chaîne d’autorités.

Sélectionner l’autorité pour l’inspection TLS

L’importation seule ne modifie aucun trafic. La nouvelle autorité est d’abord activée dans un pilote strictement limité. Pour DPI, il existe une sélection globale et une éventuelle dérogation par règle ; le Web Proxy dispose d’une sélection distincte :

• DPI, global : Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, par règle : le Decryption Profile attribué sous Profiles > Decryption profiles peut reprendre ou remplacer la sélection globale.
• Web Proxy : Web > General settings > HTTPS decryption and scanning

Les paramètres DPI comportent des champs distincts Re-sign RSA with et Re-sign EC with. Ils correspondent au type RSA ou EC utilisé pour signer le certificat d’origine du site Web. Dans les deux champs, SFOS accepte une autorité RSA ou EC. La même autorité subordonnée convient donc généralement aux deux. Une seconde autorité EC est surtout utile lorsqu’une application n’accepte qu’un type de certificat précis ; tous les terminaux concernés doivent également lui faire confiance.

Un Decryption Profile attribué à une Inspection Rule peut délibérément reprendre la sélection globale avec Use CAs defined in SSL/TLS settings. Si des valeurs propres sont définies pour Re-sign RSA with et Re-sign EC with, elles remplacent les paramètres globaux pour cette règle. Avant le pilote, contrôler donc la sélection globale de l’autorité ainsi que le profil réellement attribué à la règle.

Seule une autorité dont l’usage est Signing and validation et qui dispose d’une clé privée peut servir à la re-signature. Ne pas passer une autorité de signature déjà utilisée à Validation only ; elle ne serait plus utilisable pour la re-signature active. Cela ne permet pas d’affirmer si SFOS supprime la clé stockée.

Sécuriser d’abord le périmètre du pilote : Modifier l’autorité DPI globale affecte aussi les règles existantes dont les profils reprennent la sélection globale. Pour un pilote DPI isolé, utiliser un Decryption Profile dédié avec des valeurs d’autorité explicites et l’affecter uniquement à la règle pilote déjà limitée au groupe de test. Ne pas modifier un profil partagé avec la production. Une nouvelle règle pilote n’isole pas la sélection globale d’autorité du Web Proxy ; si l’analyse proxy est déjà active, une modification approuvée séparément pour tous les clients concernés est nécessaire. D’ici là, conserver l’autorité globale existante sans modification.

Pour le pilote :

1. Documenter la sélection actuelle et les règles concernées.
2. Sélectionner la nouvelle autorité pour les certificats RSA et EC dans le chemin d’inspection prévu et, pour DPI, vérifier si le Decryption Profile attribué reprend ou remplace la sélection globale.
3. Limiter la règle au groupe de test ou au réseau pilote défini.
4. Contrôler la chaîne d’autorités sur les clients pilotes. Dans un domaine AD, l’autorité racine d’entreprise devrait déjà être approuvée, mais la chaîne complète jusqu’à la nouvelle autorité subordonnée doit tout de même pouvoir être construite correctement.
5. Déclencher une requête HTTPS réelle et examiner ensemble les détails du certificat, l’Inspection Rule, le Decryption Profile et l’entrée de journal.

Le passage général en production n’a lieu qu’après la réussite du pilote. La sélection de l’autorité n’active pas automatiquement une Inspection Rule et l’approbation par le client ne prouve pas que le trafic est réellement déchiffré.

Vérification de l’API : séparer la sélection des CA des commutateurs globaux

Pour vérifier ou automatiser la sélection des CA via l’API XML, il faut distinguer les champs de l’objet SSLTLSInspectionSettings. Les références pour SFOS 22.0 et 23.0 mentionnent les mêmes champs ; cela ne prouve pas qu’un pare-feu donné a déjà appliqué une modification avec succès.

• RSACA et ECCA sélectionnent les CA utilisées pour la re-signature des certificats serveur RSA et EC, respectivement, et correspondent à Re-sign RSA with et Re-sign EC with. La valeur à fournir est le nom de l’objet CA prévu, par exemple SFOS-TLS-Inspection-SubCA-2026, et non un chemin de fichier de certificat, une clé privée ou une valeur d’activation. Cette sélection ne crée ni n’importe aucune CA et ne distribue pas la confiance aux clients. Les exigences décrites précédemment concernant l’usage de signature, la clé privée, la chaîne et les dérogations de profil restent applicables ; si deux CA différentes sont utilisées, les clients concernés doivent pouvoir valider les deux chaînes.

• SSLTLSEngine commande le moteur TLS, et SSLTLSInspection l’inspection SSL/TLS globale ; les deux acceptent Enabled ou Disabled. Ces champs ne correspondent ni à la sélection des CA ni à l’état de la règle pilote individuelle. Une rotation de CA ne justifie pas de modifier ces commutateurs globaux. La référence de l’API indique pour les deux la valeur par défaut Enabled ; toutefois, pour la modification, c’est l’état réel lu qui fait foi, et non une valeur par défaut issue de la documentation.

• TLS13Decryption définit le traitement global des connexions TLS 1.3 : Decrypt as 1.3 ou Downgrade to TLS 1.2 and decrypt, avec la valeur par défaut documentée Decrypt as 1.3. Ce champ ne sélectionne ni une CA de signature ni l’action d’une règle d’inspection individuelle. Une rétrogradation ne constitue donc pas une solution pour remédier à l’absence d’une chaîne de CA ou d’une clé de signature ; lors d’un changement de CA uniquement, le paramètre TLS 1.3 approuvé reste inchangé.

SSLv2SSLv3, SSLCompression et SSLConnectionsExceeded sont également des décisions globales distinctes concernant, respectivement, les anciens protocoles, la compression SSL et le dépassement de la capacité de connexions SSL. Chacun accepte Allow without decryption, Drop ou Reject ; l’API indique pour chacun Allow without decryption comme valeur par défaut, et non comme recommandation de sécurité. Lors d’une rotation de CA, ces décisions ne doivent pas être réinitialisées incidemment à des valeurs d’exemple.

Avant toute modification via l’API, sauvegarder les valeurs globales effectivement enregistrées, les noms des deux objets CA, les dérogations de profil et les règles concernées, puis définir la procédure exacte de retour à l’état antérieur. La référence indique que les champs mentionnés sont facultatifs ; cela ne prouve pas que les champs omis restent inchangés sur toutes les versions du micrologiciel. Ne pas exécuter d’appel d’écriture automatisé sans confirmation du comportement de mise à jour et de restauration pour le build concerné. Une réponse API documentée 200 signifie que l’opération a réussi, et 500 qu’elle a échoué ; même un message de réussite ne remplace pas une nouvelle lecture des valeurs enregistrées et un test avec de nouvelles connexions HTTPS. Toute valeur inattendue ou tout état indéterminé impose l’arrêt de l’extension du pilote.

Valider le fonctionnement et la sécurité

Un test réussi apporte plusieurs preuves :

1. Sous Certificates > Certificate authorities, l’autorité racine est présente comme Validation only.
2. L’autorité subordonnée est affectée à Signing and validation et affiche l’icône de clé privée.
3. Un client pilote fait confiance à l’autorité racine et peut construire la chaîne complète.
4. Un site HTTPS volontairement déchiffré présente un certificat serveur signé par la nouvelle autorité subordonnée.
5. Le hostname, la destination d’origine et l’état du navigateur sont corrects, sans avertissement de certificat inattendu.
6. Log Viewer affiche l’Inspection Rule SSL/TLS et l’action attendues pour ce test précis.
7. Une source hors du pilote reste sur le chemin précédent.

Tester séparément les applications avec certificate pinning, magasin de confiance propre ou chemins de mise à jour sensibles. Une requête réussie dans un navigateur ne suffit pas à valider tout le déploiement.

Pour la validation, tester un certificat serveur RSA ainsi qu’un certificat serveur EC dans le chemin DPI prévu et comparer, pour chacun, l’émetteur présenté, la chaîne complète racine/subordonnée, la confiance du client, le profil effectivement attribué et l’action consignée dans les journaux. Si les CA de signature sont différentes, vérifier séparément les deux chaînes de confiance. Confirmer également que les commutateurs globaux, le traitement de TLS 1.3 et les autres décisions globales correspondent à leur état antérieur documenté et qu’une source hors du pilote reste inchangée. Il s’agit de vérifications à effectuer dans votre propre environnement, et non d’un test réalisé ici sur un équipement.

Rotation et retour arrière

L’autorité subordonnée doit être renouvelée avant son expiration. La nouvelle et l’ancienne autorité doivent rester clairement identifiables pendant une transition contrôlée. La nouvelle autorité est d’abord émise, importée et validée sur les clients pilotes, puis sélectionnée progressivement dans le chemin d’inspection.

En cas d’échec, utiliser le chemin de retour préparé :

Pour revenir à l’ancienne autorité, privilégier la restauration de l’autorité ou du profil précédent. Désactiver une règle pilote ne garantit à lui seul ni l’autorité ni le déchiffrement précédents : une règle suivante peut prendre le relais. Vérifier le chemin de repli réel avant la modification, puis contrôler à nouveau le certificat et les journaux.

Un retour arrière de CA rétablit uniquement les modifications de CA et de profil liées au pilote à leur état antérieur sauvegardé. Définir systématiquement SSLTLSEngine ou SSLTLSInspection sur Disabled, ou modifier TLS13Decryption, ne rétablit ni la CA précédente ni le chemin de protection précédent. Relire ensuite la sélection et les dérogations enregistrées, puis contrôler la chaîne de certificats et les journaux avec de nouvelles connexions. En l’absence d’une procédure de retour à l’état antérieur dont le fonctionnement a été démontré, ne pas poursuivre le déploiement.

1. Rétablir la CA de re-signature précédente ou le profil de déchiffrement précédent, selon le cas. Ne désactiver la règle pilote que si le chemin de traitement qui prend ensuite le relais, vérifié au préalable, rétablit l’état antérieur approuvé ; ne pas désactiver systématiquement le moteur ou l’inspection à l’échelle globale.
2. Vérifier avec un nouveau processus de navigateur que l’ancien chemin de certificats est à nouveau actif.
3. Ne pas supprimer la nouvelle autorité tant que des règles, des Decryption Profiles ou des paramètres Web Proxy la référencent.
4. Faire intervenir le responsable de la PKI si l’EKU, la chaîne, le modèle ou l’état de révocation ne sont pas clairs.
5. Ne pas réutiliser une clé compromise ; révoquer l’autorité, en émettre une nouvelle et nettoyer les magasins de confiance de manière contrôlée.

Une autorité n’est supprimée que lorsqu’aucune configuration ne la référence plus, que l’ancien chemin n’est plus nécessaire et que les exigences de conservation et d’audit sont respectées.

Isoler les erreurs

L’icône de clé privée manque

Contrôler le CSR existant, le certificat émis pour celui-ci et l’association automatique de la clé. L’importation sous Certificates > Certificate authorities > Add dépend également de la détection d’un CSR correspondant par SFOS. Si ce CSR est absent ou si le certificat ne lui correspond pas, l’association n’est pas établie. Ne pas importer de clés privées depuis des tickets, des e-mails ou des stockages non contrôlés.

L’autorité ne peut pas être sélectionnée pour la re-signature

Contrôler l’usage de l’autorité, l’icône de clé privée et les extensions du certificat. Si Extended Key Usage est présent, il doit inclure TLS Web Server Authentication. Une autorité racine avec Validation only n’est volontairement pas disponible pour la re-signature.

Un client signale une chaîne non approuvée

Contrôler les autorités racine et subordonnée, leurs empreintes et le magasin de confiance du client concerné. Comparer ensuite l’émetteur réellement présenté dans le navigateur à l’autorité sélectionnée sur SFOS. La simple présence de l’autorité racine sur le pare-feu ou le client ne prouve pas que la bonne autorité de re-signature est active.

Le navigateur fonctionne, mais pas une application

L’application peut utiliser son propre magasin de confiance ou le certificate pinning. Documenter d’abord la destination, le client, l’Inspection Rule et l’heure de l’erreur. Ne pas ajouter d’exception globale Don't decrypt ; isoler le problème dans le petit pilote et n’approuver que l’exception nécessaire avec une justification documentée.

FAQ