Renouveler de manière contrôlée la Default CA de Sophos Firewall

La CA intégrée Default de Sophos Firewall n’est pas un simple champ descriptif. Dès que ses paramètres sont enregistrés, SFOS régénère automatiquement la CA. Une nouvelle clé et donc un nouveau trust anchor sont créés. Les relations de confiance existantes ne s’adaptent pas automatiquement.

Un renouvellement contrôlé ne commence donc pas par Save, mais par une liste exhaustive des dépendances. Elle comprend les certificats signés localement, WebAdmin et les portails, les profils SSL VPN, les pairs IPsec basés sur des certificats et les systèmes externes qui font confiance à l’ancienne CA.

⚠️ Important : Ne renouveler la CA Default qu’avec une sauvegarde vérifiée, un accès de gestion indépendant, une fenêtre de maintenance et un plan pour chaque service dépendant. Une modification cosmétique du pays, de l’organisation ou du common name ne justifie pas une régénération non planifiée.

Renouveler la Default CA en dix étapes

1. Documenter le motif technique, le responsable du changement, la fenêtre de maintenance et les critères de réussite.
2. Identifier tous les certificats, services, profils VPN, pairs et clients qui font confiance à la CA Default actuelle.
3. Vérifier si la cible réelle est uniquement l’ApplianceCertificate ou la CA distincte SecurityAppliance_SSL_CA.
4. Tester positivement la sauvegarde de configuration actuelle, le SSMK, l’accès administrateur local et le chemin de récupération.
5. Télécharger l’ancienne CA Default et enregistrer son fingerprint SHA-256, son subject, son numéro de série et sa validité.
6. Faire approuver par écrit les nouvelles données de la CA, le type de clé et la compatibilité avec tous les pairs.
7. Sous Certificates > Certificate authorities > Default, saisir les valeurs préparées et ne les enregistrer que pendant la fenêtre de maintenance.
8. Télécharger la nouvelle CA publique et la distribuer de manière contrôlée aux pairs, aux clients et aux trust stores.
9. Tester séparément WebAdmin, les portails, SSL VPN, IPsec et chaque autre service dépendant.
10. Documenter le fingerprint, les logs, les résultats des tests et les anciens profils restants. Utiliser le chemin de récupération préparé en cas d’erreur critique.

Distinguer Default CA, ApplianceCertificate et Inspection CA

Sophos Firewall contient plusieurs objets aux fonctions différentes :

• Default : CA interne pour les certificats signés localement.
• ApplianceCertificate : certificat serveur intégré utilisé par défaut pour WebAdmin, le portail utilisateur et le portail captif. Il est signé par la CA Default et peut être régénéré séparément.
• SecurityAppliance_SSL_CA : CA intégrée distincte pour HTTPS Inspection et le Re-Signing lorsqu’elle est sélectionnée dans la configuration TLS Inspection.

Ces objets ne doivent pas être confondus. Un problème avec un seul ApplianceCertificate ne prouve pas que la CA Default est défectueuse. De même, modifier la CA Default n’effectue pas automatiquement une rotation planifiée de SecurityAppliance_SSL_CA.

Importer et attribuer des certificats sur Sophos Firewall explique le travail général avec les certificats, les clés privées, les CSR et les chaînes de CA. L’Inspection CA suit une procédure distincte dans Distribuer le certificat CA pour HTTPS Scanning.

Quand une régénération est justifiée

Un changement planifié peut être nécessaire lorsque :

• la clé de l’ancienne CA est compromise de manière avérée ou plausible,
• la CA arrive à expiration et reste utilisée en production,
• l’identité, le type de clé ou les exigences cryptographiques sont migrés de manière contrôlée,
• Sophos Support exige la régénération pour un problème confirmé.

L’échec isolé d’un téléchargement VPN, un avertissement du navigateur sans analyse de la chaîne, une demande cosmétique concernant le subject ou une ancienne commande de la communauté ne sont pas des motifs suffisants. Pour un problème impliquant .ovpn et ApplianceCertificate, commencer par diagnostiquer systématiquement le téléchargement de la configuration SSL VPN.

Inventorier les dépendances avant le changement

Certificats et services attribués

Sous Certificates > Certificates, consigner au minimum le nom, le subject, l’issuer, la validité et l’attribution réelle de chaque certificat signé localement. Selon l’environnement, cela comprend :

• WebAdmin, le portail utilisateur et le portail captif,
• le certificat serveur SSL VPN,
• IPsec site-to-site et d’accès distant avec Digital certificate,
• WAF, SMTP, API ou autres services TLS,
• certificats client ou serveur générés localement hors du pare-feu.

Un certificat visible ne constitue pas automatiquement une dépendance. Il faut déterminer si un service de production l’utilise et si le pair fait confiance à la CA Default émettrice.

Systèmes de confiance et chemins de distribution

Documenter également :

• les navigateurs et systèmes d’exploitation sur lesquels l’ancienne CA est importée,
• MDM, GPO ou la distribution logicielle de la nouvelle CA,
• les pairs IPsec avec un Default.pem, une Remote CA ou une correspondance DN importés,
• les utilisateurs SSL VPN et le chemin de distribution des nouveaux profils .ovpn,
• la supervision, les clients API ou les intégrations avec certificate pinning,
• les accès de gestion HA, d’urgence et externes.

Arrêter le changement si l’on ne sait pas qui a distribué l’ancienne CA ou quels pairs lui font confiance.

Préserver l’état initial et le chemin de récupération

Avant la fenêtre de maintenance, télécharger la CA Default sous Certificates > Certificate authorities. L’archive contient la partie publique, pas automatiquement un export séparément utilisable de sa clé privée.

Les données PEM peuvent être inspectées en lecture seule sur un poste d’administration :

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Pour un fichier DER, préciser le format d’entrée :

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Conserver le fingerprint et la sortie dans l’état initial avec le nom du pare-feu, le numéro de série, le build SFOS et le ticket de changement. Ne pas joindre sans protection des fichiers de certificat et des données PKI internes à des tickets publics.

Conserver aussi à l’extérieur une sauvegarde actuelle de Sophos Firewall avec son mot de passe et son SSMK. Une restauration remplace toute la configuration, redémarre le pare-feu et peut annuler des changements ultérieurs. C’est un dernier chemin de récupération planifié, pas une fonction d’annulation rapide pour la CA.

Préparer la fenêtre de maintenance

Avant Save, tous les points suivants doivent être validés :

• compte admin local ou second administrateur testé depuis le réseau de gestion,
• console ou autre chemin de récupération indépendant disponible,
• nouvelles valeurs de CA et cryptographie compatibles avec tous les systèmes pairs,
• responsables des pairs VPN, du MDM/GPO et des portails disponibles,
• nouveaux profils, distribution aux trust stores et comptes de test préparés,
• temps suffisant pour une restauration complète de la sauvegarde si nécessaire.

Dans un cluster HA, effectuer la modification WebAdmin prise en charge sur le Primary actuel. SFOS ne documente pas de continuité ininterrompue de la CA ou des sessions pour ce changement. Après un failover planifié, tester de nouveau de nouvelles connexions et tous les services critiques. Ne pas modifier la CA indépendamment sur les deux nœuds.

Mettre à jour la Default CA dans SFOS

1. Ouvrir Certificates > Certificate authorities.
2. Cliquer sur Default. Son nom ne peut pas être modifié.
3. Vérifier Country, State, Locality, Organization, Organizational unit, Common name et l’adresse e-mail.
4. Sous Private key settings, sélectionner consciemment RSA ou Elliptic curve, la longueur de clé ou la courbe correspondante et le Secure hash.
5. Vérifier les valeurs par rapport au ticket de changement et à la liste de compatibilité.
6. Cliquer sur Save uniquement pendant la fenêtre de maintenance.

Les valeurs d’exemple CH, Zurich, Example AG, IT Security, fw01.example.com et pki@example.com sont uniquement destinées à la documentation. Les remplacer par l’organisation, la référence réelle du pare-feu et la convention de nommage PKI approuvée.

⚠️ Save est le point de bascule. SFOS régénère automatiquement la CA Default. Saisir ultérieurement les anciennes valeurs du subject ne restaure ni l’ancienne clé ni l’ancien fingerprint.

Télécharger immédiatement la nouvelle CA Default et effectuer le même contrôle OpenSSL. Un nouveau fingerprint SHA-256 est attendu après la régénération. Des champs inattendus, une erreur de téléchargement ou un état impossible à documenter sont des conditions d’arrêt.

Migrer les services dépendants de manière contrôlée

WebAdmin et portails

Vérifier le certificat sélectionné pour WebAdmin, le portail utilisateur et le portail captif sous Administration > Admin and user settings. Si un certificat signé localement avec la nouvelle CA est utilisé, les clients qui y accèdent doivent faire confiance à la nouvelle CA.

Conserver une session Full Admin existante ouverte pendant le test. De nouvelles fenêtres de navigation privée testent le FQDN, la chaîne de certificats et la connexion depuis la source de gestion prévue. La commande CLI qui réinitialise le certificat WebAdmin sur le certificat par défaut du dispositif ne constitue pas un rollback de l’ancienne clé de CA.

SSL VPN

Si SSL VPN utilise l’ApplianceCertificate ou un autre certificat serveur signé localement, les utilisateurs doivent télécharger et importer un nouveau fichier .ovpn après la modification des paramètres de la CA Default. Un nom de fichier existant ou un tunnel vert avec un ancien profil ne suffisent pas comme validation.

Au moins un utilisateur pilote télécharge le nouveau profil par le chemin de portail prévu, établit une nouvelle connexion et teste le DNS, les routes et le trafic applicatif réel. Ne retirer les anciens profils de la distribution qu’après la migration réussie de tous les utilisateurs.

Pairs IPsec basés sur des certificats

Avec Digital certificate, les pairs Sophos Firewall échangent leurs certificats de CA. Si le pair avait importé le Default.pem distant, remplacer ou ajouter la nouvelle CA publique de manière contrôlée sur le pair et revérifier la correspondance.

La configuration complète de la connexion reste décrite dans Configurer IPsec site-to-site sur Sophos Firewall. Pour le changement de CA, tester au minimum l’établissement IKE, la Child SA, les deux sens de trafic et les applications réelles. Un tunnel vert ne prouve pas à lui seul le chemin de retour.

HTTPS Inspection et autres chemins de signature

Pour HTTPS Inspection, commencer par identifier la Signing CA réellement sélectionnée sous Web > General settings. S’il s’agit de SecurityAppliance_SSL_CA ou d’une CA externe, ne pas la redistribuer uniquement parce que la CA Default a été régénérée.

N’inclure un chemin de signature dans le changement que s’il utilise effectivement la CA Default modifiée ou un certificat dépendant. Les changements de trust store restent ainsi limités aux endpoints réellement concernés.

Vérifier le résultat et les logs

La validation sépare la configuration du fonctionnement :

1. Télécharger la nouvelle CA et documenter son subject, son issuer, son numéro de série, sa validité et son fingerprint SHA-256.
2. Sous Certificates > Certificates, vérifier l’issuer, Trusted et les objets certificat concernés.
3. Tester individuellement WebAdmin, les portails, SSL VPN, IPsec et les autres services attribués.
4. Vérifier dans vpncertificate.log l’opération de CA et de certificat au moment du changement.
5. Vérifier dans configuration-audit.log l’administrateur, l’heure et les données avant/après prises en charge.
6. Corréler dans les logs de service correspondants uniquement les erreurs et réussites liées au test.

Retracer les changements de configuration avec configuration-audit.log explique l’audit trail. Tous les services n’écrivent pas le même niveau de détail dans configuration-audit.log, la validation fonctionnelle reste donc obligatoire.

Rollback et conditions d’arrêt

Une CA régénérée ne possède pas de simple commande Undo. Enregistrer à nouveau l’ancien texte ne restaure pas l’ancienne clé privée.

Le chemin de récupération est donc défini à l’avance pour chaque service :

• conserver un accès de gestion indépendant et la session administrateur existante,
• réattribuer aux portails un certificat externe indépendant déjà validé, s’il est disponible et peut être attribué en toute sécurité,
• rétablir la confiance des pairs et les profils client uniquement selon l’état précédent documenté,
• n’utiliser une restauration complète de la sauvegarde que si les effets, le redémarrage, le SSMK et la perte des changements ultérieurs sont acceptables,
• transmettre les preuves à Sophos Support lorsqu’une dépendance est inconnue ou que l’état du certificat ne peut pas être reproduit.

Ne pas effectuer de modification de base de données dans le shell, de suppression massive de certificats, de redémarrage de service ou de seconde régénération de CA sur simple soupçon. Arrêter le changement si un pair critique ne peut pas être coordonné, si le nouveau trust anchor n’est pas distribué ou si le chemin de récupération n’a pas été testé avec succès.

Erreurs courantes après la régénération

Le navigateur signale une connexion non fiable

Vérifier la chaîne de certificats réellement présentée pour le FQDN. Si le certificat serveur est signé par la nouvelle CA Default, c’est précisément cette CA qui doit être présente dans le trust store. Ne pas importer SecurityAppliance_SSL_CA sans discernement.

SSL VPN ne se connecte plus avec l’ancien profil

Corréler le certificat serveur SSL sélectionné, la nouvelle CA, le téléchargement du portail et sslvpn.log. Télécharger un nouveau fichier .ovpn et l’importer comme nouveau profil. Distinguer les anciens et nouveaux profils par le certificat et la connexion réussie, pas par le nom de fichier.

IPsec reste down après le changement de CA

Des deux côtés, vérifier l’importation de la CA, le statut Trusted, Local/Remote certificate, ID et strongswan.log. Avec DER ASN1 DN, une modification du subject de la CA peut aussi affecter l’identité. Ne pas assouplir les profils ou les ID sur simple soupçon.

HTTPS Inspection affiche des erreurs de certificat

Vérifier d’abord la Signing CA réellement sélectionnée. Si SecurityAppliance_SSL_CA est toujours utilisée et n’a pas changé, l’erreur n’est pas automatiquement causée par la nouvelle CA Default. Examiner séparément la chaîne de certificats, la Decryption Rule et la confiance de l’endpoint.

Liste de contrôle

• Le motif et le périmètre de la régénération de la CA sont documentés.
• L’ancienne CA, le fingerprint, la sauvegarde, le mot de passe et le SSMK sont conservés.
• Tous les certificats, services, pairs, clients et chemins de distribution sont inventoriés.
• Default, ApplianceCertificate et SecurityAppliance_SSL_CA ont été évalués séparément.
• La fenêtre de maintenance, le chemin de récupération administrateur et les responsables sont prêts.
• Les nouvelles valeurs de la CA et la cryptographie sont compatibles avec tous les pairs.
• La CA n’a été enregistrée que pendant la fenêtre approuvée et a été téléchargée ensuite.
• WebAdmin, les portails, SSL VPN, IPsec et les autres services ont été testés séparément.
• vpncertificate.log, configuration-audit.log et les logs de service ont été conservés.
• Un rollback ou une escalade au support est possible sans intervention incontrôlée dans le shell.

FAQ