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.

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é.

É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. Télécharger le certificat de l’autorité subordonnée émis.
8. Télécharger également le certificat de l’autorité racine qui a signé l’autorité subordonnée.

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. Ouvrir Certificates > Certificate authorities et rechercher l’autorité importée.

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 ; téléverser à nouveau le fichier ailleurs ne rétablit pas l’association de clé manquante.

Ajouter l’autorité racine uniquement pour la validation

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é. Selon le chemin d’inspection, la sélection se trouve à différents endroits :

• DPI : Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile : Profiles > Decryption profiles
• Web Proxy : Web > General settings > HTTPS decryption and scanning

Seule une autorité dont l’usage est Signing and validation et qui dispose d’une clé privée peut servir à la re-signature. Une autorité de signature déjà utilisée ne doit pas être passée à Validation only, car le chemin actif de re-signature perdrait sa clé.

Pour le pilote :

1. Documenter la sélection actuelle et les règles concernées.
2. Sélectionner la nouvelle autorité dans le chemin d’inspection prévu.
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é.

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.

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é :

1. Désactiver la règle pilote ou revenir à l’ancienne autorité de re-signature.
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

Si le certificat n’a pas été importé via le CSR correspondant, SFOS ne peut pas l’associer à la clé créée sur le pare-feu. Contrôler le chemin d’association du CSR et le certificat émis. 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