Importer et attribuer des certificats sur Sophos Firewall

Sur Sophos Firewall, un certificat n’est prêt à l’emploi que lorsque quatre éléments concordent : nom d’hôte, certificat serveur, clé privée et chaîne de CA émettrice. Il faut ensuite attribuer le certificat au bon service. Sa simple présence sous Certificates > Certificates ne modifie encore aucun portail ni aucune règle WAF.

Pour un certificat provenant d’une CA interne ou publique, la méthode standard la plus sûre consiste à :

1. Générer une Certificate Signing Request (CSR) sous Certificates > Certificates > Add.
2. Faire signer la CSR par la CA souhaitée.
3. Importer le certificat émis au moyen de l’action d’importation associée à la CSR existante.
4. Vérifier sous Trusted que la CA correspondante est installée et sous Valid until que le certificat est valide.
5. Attribuer le certificat au service souhaité et le tester depuis un client.

Avec cette méthode, la clé privée est créée sur le pare-feu et n’a pas à le quitter. Il est également possible d’uploader un certificat déjà généré en externe, mais il faut alors fournir la clé privée correspondante et, le cas échéant, les CA intermédiaires et racines manquantes.

Si un fichier PFX ou PEM est déjà disponible, la méthode rapide passe par Certificates > Certificates > Add > Upload certificate : choisir le format, uploader le certificat avec la clé privée requise et son mot de passe, puis vérifier la CA associée, la durée de validité et l’attribution au service.

Quelle méthode choisir pour le certificat ?

• CA publique ou interne, nouveau certificat : générer la CSR sur le pare-feu. Cela réduit les transferts de clés et limite le risque de confondre les paires certificat-clé.
• Certificat existant avec clé privée : uploader le certificat au format PEM, DER, CER ou PKCS12. Le format, le mot de passe et la chaîne de CA doivent correspondre.
• Let’s Encrypt pour un service public du pare-feu : le processus intégré peut prendre en charge l’émission et le renouvellement. La procédure complète est décrite dans Configurer des certificats Let’s Encrypt sur Sophos Firewall.
• Certificat wildcard externe : le créer en dehors du pare-feu, puis l’importer. La planification et la validation DNS-01 sont décrites dans Créer un certificat wildcard Let’s Encrypt.
• Automatiser DigiCert ou une autre CA publique : Renouveler un certificat Sophos Firewall via l’API XML et vérifier les services réunit l’émission, l’upload via l’API XML, l’attribution au service et le test externe du listener dans une procédure de bout en bout contrôlée.
• Uniquement pour des clients internes administrés : un certificat signé localement peut suffire si tous les clients font confiance à la CA interne émettrice.

Un certificat autosigné ou signé localement n’utilise pas automatiquement un chiffrement non sécurisé. Toutefois, sans chaîne de confiance distribuée, le client ne peut pas vérifier l’identité de manière fiable et affiche un avertissement. Une CA publique constitue donc généralement le meilleur choix pour les portails et applications WAF accessibles publiquement.

Distinguer certificat, CA, clé privée et CSR

Ces quatre éléments remplissent des fonctions différentes :

• Certificat serveur : contient l’identité, les informations de clé publique, les noms valides et la durée de validité. Il est présenté au client.
• Clé privée : prouve que le pare-feu est autorisé à utiliser le certificat. Elle ne doit jamais apparaître dans des tickets, des captures d’écran ou des espaces de stockage publics.
• Certificats de CA : forment la chaîne de confiance entre la CA intermédiaire émettrice et la CA racine. Aucune clé privée de CA n’est requise à cette fin.
• CSR : contient la demande de certificat et la clé publique. Lorsque la CSR est générée sur le pare-feu, la clé privée associée reste sur l’appareil.

Informations et actions dans la liste des certificats

Sous Certificates > Certificates, SFOS affiche le Subject, l’Issuer et le Purpose au survol du nom d’un certificat. Les actions permettent de copier le certificat ou de le télécharger sous forme de fichier .crt ; le fichier téléchargé ne contient aucune clé privée. Regenerate est disponible uniquement pour l’ApplianceCertificate intégré. Les certificats signés localement peuvent être révoqués directement ; SFOS les ajoute automatiquement à la CRL Default. La procédure de révocation contrôlée est décrite dans Certificate Revocation Lists sur Sophos Firewall.

Une CA destinée à TLS Inspection ne remplit pas la même fonction qu’un certificat serveur pour WebAdmin ou WAF. Pendant le déchiffrement, l’Inspection CA signe de nouveaux certificats pour les clients. Sa sélection et sa distribution sont expliquées dans Distribuer le certificat de CA Sophos Firewall pour TLS Inspection.

La relève chiffrée via POP3 et IMAP possède aussi une attribution TLS propre sous Email > General settings. Analyser et tester POP3 et IMAP sur Sophos Firewall explique comment la CA du serveur de messagerie, la validation du certificat, l’option d’analyse et la règle firewall interagissent.

Si le pare-feu doit être intégré à la PKI de l’entreprise à cette fin, Configurer une autorité de certification subordonnée pour l’inspection TLS de Sophos Firewall explique le processus CSR, AD CS, EKU et importation d’une autorité de re-signature dédiée.

La CA intégrée Default est le trust anchor des certificats signés localement. L’enregistrement de ses paramètres régénère la CA et peut affecter les portails, SSL VPN, les pairs IPsec et les clients qui lui font confiance. Renouveler de manière contrôlée la Default CA de Sophos Firewall fournit la procédure de changement sûre.

La durée de validité et la chaîne de confiance ne suffisent pas lorsqu’un certificat a été révoqué prématurément. La procédure CRL dédiée explique comment importer, mettre à jour et vérifier les Certificate Revocation Lists locales et externes sur Sophos Firewall.

En mode FIPS 140-3, SFOS valide en plus les certificats nouvellement générés et importés par rapport aux algorithmes de clé et de digest autorisés. L’activation de ce mode est une migration distincte avec réinitialisation, pas un changement de certificat ordinaire.

Préparer les noms, la durée de validité et la chaîne

Avant l’importation, il faut déterminer quel nom les utilisateurs et les systèmes ouvriront réellement. Les clients modernes vérifient principalement les Subject Alternative Names (SAN). Le Common Name seul ne constitue pas un remplacement fiable.

Exemple :

• URL appelée : https://vpn.example.com
• nom du certificat dans SFOS : public-vpn-example-com-2026
• SAN dans le certificat : vpn.example.com
• DNS : vpn.example.com pointe vers l’accès prévu au pare-feu ou à la WAF

vpn.example.com est un exemple à remplacer par le FQDN utilisé dans l’environnement. Si un administrateur accède au service au moyen de l’adresse IP ou d’un autre alias, le certificat ne correspond que si ce nom ou cette adresse IP figure également dans les SAN.

À vérifier avant la modification :

• La date, l’heure et le NTP du pare-feu sont corrects.
• Tous les FQDN requis figurent comme SAN dans la demande ou le certificat.
• La clé privée et le certificat forment bien une paire.
• Les CA intermédiaires et racines sont connues.
• La date d’expiration et la responsabilité du renouvellement sont documentées.
• L’ancien certificat et ses attributions restent disponibles pour permettre un retour en arrière.

Générer un certificat signé localement

Pour un service interne, SFOS peut signer directement un certificat avec la CA intégrée Default. Cette méthode n’est appropriée que si les appareils qui se connectent font déjà confiance à cette CA ou reçoivent son certificat public par un processus contrôlé. Pour les services accessibles publiquement, un certificat émis par une CA publique reste généralement préférable.

Sous Certificates > Certificates > Add, sélectionner Generate locally-signed certificate. Définir ensuite un nom sans ambiguïté et la période de validité requise ; SFOS propose un an par défaut. Key type (RSA ou Elliptic curve), la longueur de clé ou la courbe et Secure hash doivent correspondre aux exigences cryptographiques de l’organisation et aux clients.

Le Common name est obligatoire dans le Subject. SFOS préremplit initialement Country name, State, Locality name, Organization name, Organization unit name et l’adresse e-mail de contact à partir des données de licence ; vérifier chaque valeur par rapport à l’organisation réelle et à l’usage prévu avant l’enregistrement. Sous Subject Alternative Names, saisir tous les noms DNS ainsi que les adresses IPv4 ou IPv6 nécessaires.

Au moins un SAN ou un Certificate ID est requis. Le Certificate ID sous Advanced settings sert uniquement à la compatibilité avec les anciennes versions de SFOS et ne remplace pas une liste SAN correcte pour les clients HTTPS modernes. Après Save, contrôler l’émetteur Default, la validité, les SAN et l’attribution ultérieure au service.

Méthode recommandée : générer la CSR sur le pare-feu

Créer la CSR

1. Ouvrir Certificates > Certificates.
2. Sélectionner Add.
3. Sous Action, sélectionner Generate certificate signing request (CSR).
4. Attribuer un nom interne explicite, par exemple public-vpn-example-com-2026.
5. Choisir le Key type requis, la longueur de clé ou la courbe ainsi que le Secure hash selon les exigences de sécurité et de la CA.
6. Sous Common name, saisir le FQDN principal, par exemple vpn.example.com.
7. Sous Subject Alternative Names, ajouter au minimum le nom DNS réellement utilisé.
8. Enregistrer, puis télécharger la CSR au moyen de l’icône de téléchargement.

Contrôler également les autres champs du Subject et l’adresse e-mail de contact. SFOS peut les préremplir à partir des données de licence, mais ils appartiennent à cette demande de certificat précise et ne doivent pas être repris sans vérification.

Le nom interne du certificat est uniquement une désignation SFOS. Il ne doit pas nécessairement correspondre au FQDN, mais devrait permettre d’identifier l’usage et l’année de renouvellement. En revanche, les entrées SAN font partie du contrôle technique d’identité et doivent correspondre à l’URL qui sera utilisée.

Faire signer la CSR

Transmettre la CSR téléchargée à la CA publique ou interne compétente. Ne pas lui faire générer de nouveaux fichiers de clés si la clé privée créée sur le pare-feu doit être utilisée. La CA fournit ensuite le certificat serveur signé et, selon le fournisseur, des certificats intermédiaires supplémentaires.

À contrôler avant l’importation :

• La CA a signé la bonne CSR.
• La liste des SAN contient tous les noms approuvés.
• La durée de validité et l’émetteur correspondent à la commande ou à la politique interne.
• La chaîne de CA est complète.

Importer le certificat signé dans la CSR

1. Ouvrir Certificates > Certificates.
2. Dans la ligne de la CSR correspondante, sélectionner l’action d’importation sous Manage.
3. Uploader le certificat émis ou coller son texte.
4. Sélectionner la finalité correspondant à l’objet émis :
   • Certificate only : le certificat serveur ou client émis est enregistré sous Certificates > Certificates.
   • Certificate authority only : cette option s’applique à une CA émise à partir de la CSR, par exemple une CA subordonnée. Elle apparaît ensuite sous Certificates > Certificate authorities.
   • Certificate and certificate authority : l’upload contient à la fois le certificat émis et sa CA racine ou subordonnée.
5. Exécuter Import certificate.

Lors de l’importation d’une CA, SFOS utilise d’abord le Common Name comme nom de CA ; il est possible de le modifier avant l’importation. SFOS associe le certificat ou le certificat de CA émis à partir de la CSR à la clé privée correspondante stockée sur le pare-feu. Il supprime ensuite l’entrée CSR. Il faut donc vérifier soigneusement avant l’importation que la bonne ligne CSR a bien été sélectionnée.

Uploader un certificat existant avec sa clé privée

Si le certificat et la clé ont déjà été générés en dehors du pare-feu :

1. Ouvrir Certificates > Certificates > Add.
2. Sélectionner Upload certificate.
3. Attribuer un nom univoque.
4. Sélectionner le format de fichier existant.
5. Uploader le certificat et les données de clé requises par le format.
6. Si la clé privée est chiffrée, saisir son mot de passe.
7. Enregistrer.

SFOS prend en charge les formats de certificat suivants :

• PEM (.pem) : encodé en Base64 ; le certificat et la clé privée se trouvent généralement dans des fichiers distincts.
• DER (.der) et CER (.cer) : formats de certificat binaires ; la clé privée est fournie séparément.
• PKCS7 (.p7b) : peut contenir des certificats et une chaîne, mais pas de clé privée.
• PKCS12 (.pfx ou .p12) : peut contenir ensemble le certificat serveur, la chaîne de CA et la clé privée.

Les clés RSA et ECC sont prises en charge. SFOS accepte au maximum 30 caractères pour le mot de passe d’une clé privée importée. Cette limite du produit ne justifie pas l’utilisation d’une clé privée non protégée : définir pour le transfert un mot de passe robuste respectant cette limite, puis supprimer le fichier d’importation de tout espace de stockage intermédiaire non sécurisé.

Compléter une chaîne de CA incomplète

Sous Certificates > Certificates, une entrée verte dans Trusted indique que la CA associée est installée sur SFOS. Si elle manque, commencer par contrôler l’émetteur et la chaîne :

1. Ouvrir Certificates > Certificate authorities.
2. Sélectionner Add.
3. Uploader la CA intermédiaire ou racine manquante, ou coller le texte du certificat.
4. Utiliser Validation only pour une simple chaîne de confiance.
5. Enregistrer, puis contrôler à nouveau l’état Trusted du certificat serveur.

Lors de l’upload direct d’une CA, SFOS détecte automatiquement le format de fichier X.509 ; les formats .pem, .der et .cer sont pris en charge. Si la CA correspond à une CSR générée sur le pare-feu, SFOS reprend le nom de la CSR et définit la finalité sur Signing and validation, car la clé privée correspondante se trouve déjà sur le pare-feu. Contrôler ensuite le symbole de clé privée. L’utilisation comme CA de re-signature relève de la procédure distincte consacrée à la CA subordonnée pour TLS Inspection.

Une CA racine ou intermédiaire publique n’a pas besoin de clé privée pour la validation. Signing and validation est uniquement destiné à une CA avec laquelle le pare-feu doit lui-même signer des certificats et dont la clé privée doit délibérément se trouver sur le pare-feu.

Importer une CA de signature externe sans CSR correspondante sur le pare-feu

Cette procédure concerne une CA intermédiaire générée en externe que le pare-feu utilisera pour signer des certificats, pas le certificat serveur ni une chaîne destinée uniquement à la validation. Il faut disposer du certificat de CA et de la clé privée propre à cette CA, dont la correspondance a été vérifiée. Ne pas transférer la clé de la CA racine sur le pare-feu. Une CSR générée sur le pare-feu reste préférable, car elle évite le transport de clés.

Si la CA de signature contient Extended Key Usage (EKU), cette extension doit inclure TLS Web Server Authentication. Ne pas convertir une CA déjà utilisée pour la re-signature en Validation only : elle perdrait la capacité de signature nécessaire au rechiffrement du trafic SSL/TLS déchiffré. Avant la modification, conserver un backup, l’ancienne sélection de CA et ses dépendances.

1. Ouvrir Certificates > Certificate authorities et sélectionner Add, pas la liste des certificats serveur.
2. Uploader le certificat de la CA intermédiaire ou coller son texte. SFOS détecte automatiquement .pem, .der et .cer.
3. SFOS recherche une CSR correspondante sur le pare-feu. Si elle existe, son nom et Signing and validation sont repris ; la clé privée se trouve déjà sur le pare-feu. Modifier le nom proposé si nécessaire, puis sélectionner Save. Aucun upload supplémentaire de clé n’est nécessaire.
4. Sans CSR correspondante, des options supplémentaires apparaissent. Sous Use certificate for, sélectionner Signing and validation pour cette CA de signature.
5. Uploader la Private key de cette CA intermédiaire, pas la clé privée du certificat serveur. Saisir le mot de passe de la clé pour le chiffrement ; il doit contenir au maximum 30 caractères. Utiliser une clé protégée et un mot de passe robuste respectant cette limite pour le transfert.
6. Saisir un nom de CA univoque ou modifier le nom proposé, puis sélectionner Save.
7. Uploader ou coller séparément la CA racine associée sous Certificates > Certificate authorities > Add, définir Use certificate for sur Validation only, puis sélectionner Save. Elle valide la CA intermédiaire sans avoir besoin de clé privée.
8. Sous Certificates > Certificates, vérifier la coche verte dans Trusted pour le certificat serveur importé. Ensuite, sous Certificates > Certificate authorities, ouvrir le filtre à côté de Type, sélectionner Uploaded, puis cliquer sur Apply. Le symbole de clé privée doit apparaître à côté de la CA intermédiaire/subordonnée ; il confirme la présence de la clé de signature, pas la réussite d’un test de trafic.

Si Trusted manque, contrôler l’émetteur et la chaîne complète ; si le symbole de clé manque, vérifier la paire CA-clé, l’importation et le mot de passe avant d’affecter la CA. L’importation seule ne change pas la CA sélectionnée pour l’inspection TLS. La CSR d’entreprise/AD CS, la sélection du trafic et le test pilote restent dans la procédure liée de la CA subordonnée pour TLS Inspection. Lors du changement ultérieur, conserver l’ancienne sélection pour le retour en arrière ; ne supprimer les nouvelles entrées que lorsqu’elles n’ont aucune dépendance. Un retour à l’ancienne CA n’annule pas un transfert de clé : supprimer les fichiers d’importation des espaces temporaires non sécurisés et conserver des copies de récupération protégées conformément à la politique PKI.

Upgrade vers SFOS 21 : vérifier les noms de CA réservés

Lors de l’upgrade vers SFOS 21, NC-146082 peut bloquer la migration. La cause n’est pas la validité du certificat, mais une entrée de CA déjà configurée dont SFOS 21 réserve le nom aux CA Let’s Encrypt intégrées :

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Avant la fenêtre de maintenance :

1. Créer un backup récent de la configuration et disposer du mot de passe du backup ainsi que de la Secure Storage Master Key.
2. Sous Certificates > Certificate authorities, rechercher les noms exacts. En l’absence de résultat, NC-146082 n’exige aucune modification.
3. En cas de résultat, documenter le type, le Subject, l’Issuer, l’usage et la présence éventuelle du symbole de clé. Celui-ci indique que le pare-feu possède la clé privée de la CA.
4. Exporter également une CA avec clé privée sous Backup and firmware > Import export > Export selective configuration en tant que CertificateAuthority. La procédure sécurisée pour le paquet, le SSMK et le réimport est décrite dans Exporter et importer sélectivement la configuration. Identifier ensuite les certificats et services qui dépendent de cette CA, par exemple VPN, WebAdmin et portails, WAF, SMTP TLS ou TLS Inspection.
5. Supprimer uniquement une entrée configurée par l’administrateur après avoir remplacé toutes ses dépendances ou confirmé qu’elles ne sont plus nécessaires. Relancer ensuite l’upgrade.

Ne pas supprimer une CA intégrée. Si WebAdmin refuse la suppression, si la clé privée d’origine manque ou si une référence reste incertaine, interrompre l’upgrade et faire appel au support Sophos. Une modification de la base de données ou via l’Advanced Shell n’est pas une solution sûre.

Après l’upgrade, vérifier que les CA Let’s Encrypt intégrées sont présentes, que les certificats dépendants affichent à nouveau Trusted et que les services concernés fonctionnent.

Attribuer le certificat au bon service

Avant l’attribution : prévoir le retour en arrière

Un changement de certificat ne doit pas commencer par la suppression de l’ancienne entrée :

1. Importer le nouveau certificat et la chaîne de CA complète.
2. Contrôler les SAN, l’émetteur, la durée de validité et Trusted.
3. Documenter l’attribution actuelle et les services concernés.
4. Commencer par attribuer le nouveau certificat à une seule cible d’attribution. Le groupe WebAdmin/portails est modifié en bloc, tandis que les règles WAF et SMTP peuvent être modifiées individuellement.
5. Tester tous les services concernés par cette cible d’attribution avec leurs FQDN et ports réels.
6. En cas d’erreur, sélectionner immédiatement l’ancien certificat.
7. Migrer les autres cibles d’attribution une par une et les contrôler à chaque étape.
8. Ne supprimer l’ancien certificat que lorsqu’il n’est plus référencé et que le nouvel état est stable.

WAF et SMTP peuvent être migrés l’un après l’autre. En revanche, WebAdmin, User Portal, VPN Portal, Captive Portal et les deux portails SPX changent simultanément par l’intermédiaire d’une sélection de certificat commune.

La procédure complète pour le FQDN du portail, l’enregistrement du mot de passe, le Reply Portal et le flux de messagerie est décrite dans Configurer et tester le chiffrement des e-mails SPX.

Lors d’une modification de WebAdmin, conserver en outre une session administrateur existante et un autre accès de management local ouverts jusqu’à ce que la connexion et le certificat aient été contrôlés au moyen du FQDN prévu.

WebAdmin et portails

Sous Administration > Admin and user settings > Admin console and end-user interaction, un certificat commun est sélectionné pour les services suivants :

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

Dans le champ Certificate, sélectionner le nouveau certificat et enregistrer avec Apply. Le certificat doit couvrir tous les FQDN utilisés pour accéder aux services concernés. Si, par exemple, admin.example.com est utilisé pour WebAdmin et vpn.example.com pour le VPN Portal, les deux noms doivent figurer dans les SAN ou la planification des URL doit être uniformisée.

Pour une administration exclusivement interne, SFOS peut également sécuriser le nom WebAdmin avec un certificat signé localement. Sous Certificates > Certificates > Add, sélectionner Generate locally-signed certificate, puis saisir exactement le nom d’hôte du pare-feu résolu en interne dans Common name et DNS names, par exemple fw01.example.com. Définir ensuite la même valeur comme Hostname sous Administration > Admin and user settings, sélectionner le nouveau Certificate et activer Use the firewall’s configured hostname.

Pour que les navigateurs approuvent ce certificat, télécharger le certificat public de l’autorité Default sous Certificates > Certificate authorities, extraire l’archive, puis distribuer Default.der ou Default.pem sous le nom Default.crt aux terminaux administrés. Distribuer le certificat d’autorité de Sophos Firewall pour l’inspection TLS décrit la distribution et le contrôle sécurisés sous Windows, macOS et Firefox. Seul le certificat public de l’autorité est distribué, jamais une clé privée.

⚠️ Cette méthode supprime l’avertissement du navigateur uniquement sur les appareils administrés qui approuvent l’autorité Default. Elle ne rend pas le certificat publiquement approuvé. Si l’autorité Default est régénérée ultérieurement, les certificats et la distribution de confiance doivent être renouvelés de manière contrôlée.

Le certificat du VPN Portal protège le site HTTPS depuis lequel les utilisateurs récupèrent des profils et des clients. Il ne constitue pas automatiquement le Local Certificate ou Remote Certificate d’un tunnel IPsec.

Configurer un VPN IPsec Site-to-Site avec des certificats explique comment la CA, la Certificate ID, le Local Certificate et le Remote Certificate interagissent entre deux pare-feu.

Réinitialiser le certificat WebAdmin par défaut via la console

Si WebAdmin n’est plus utilisable après une mauvaise affectation de certificat, un accès fonctionnel à la Device Console peut servir de procédure break-glass. Documenter d’abord le FQDN utilisé, l’affectation précédente du certificat et le fingerprint attendu. Conserver toute session d’administration encore ouverte.

Dans la Device Console, ouvrir 2. System Configuration > 4. Reset Default Web Admin Certificate et confirmer la réinitialisation avec y. SFOS remplace le certificat de la console WebAdmin par le certificat par défaut de l’appareil. L’opération ne restaure ni le certificat précédemment sélectionné ni une ancienne clé privée de la CA Default, et elle ne régénère pas cette CA. La CA Default fournie participe également à la chaîne HTTPS des pages de blocage et d’avertissement du proxy web, mais l’option 4 ne réinitialise pas cette fonction proxy. Un avertissement du navigateur ou une erreur de nom peut donc apparaître avec le certificat par défaut signé localement.

Après le message de réussite, rouvrir WebAdmin uniquement par le chemin de gestion prévu, examiner le certificat réellement présenté et tester une nouvelle connexion. Comme WebAdmin et plusieurs portails utilisent la même sélection de certificat, tester également chaque portail exploité. Un certificat de production corrigé peut ensuite être réaffecté de manière contrôlée sous Administration > Admin and user settings. La réinitialisation par la console est une procédure de récupération, pas une solution permanente de confiance publique.

WAF

Pour une publication WAF, modifier la règle correspondante sous Rules and policies > Firewall, activer HTTPS, sélectionner le nouveau certificat sous HTTPS certificate, puis enregistrer. La règle utilise Protect with web server protection. SNI, le domaine défini dans la règle et le SAN du certificat doivent décrire le même nom d’hôte.

La modification d’une règle WAF redémarre les règles Web Server Protection et interrompt les connexions existantes. Pour les applications de production, le changement de certificat doit donc avoir lieu dans une fenêtre de maintenance. La publication complète et son contrôle sont décrits dans Sophos Firewall WAF : publier un serveur web en toute sécurité.

SMTP TLS en mode MTA

Sous Email > General settings > SMTP TLS configuration, TLS certificate utilise, selon la configuration, un certificat de CA ou de serveur pour analyser les connexions SMTP via TLS. Avant tout changement, documenter la finalité actuelle, la validation du certificat ainsi que les connexions entrantes et sortantes concernées. Si le pare-feu présente lui-même une identité serveur lors de communications SMTP publiques, il est recommandé d’utiliser à cet effet un certificat émis par une CA publique. Après Apply, tester les deux sens du trafic avec les modes TLS réellement utilisés. Le reste du flux de messagerie est décrit dans Sophos Firewall Mail Protection en mode MTA.

Après la modification, créer une nouvelle sauvegarde Sophos Firewall et documenter la date d’expiration, le responsable et le prochain renouvellement.

Contrôler le certificat et sa présentation

Contrôler le fichier avant l’importation

Sur un ordinateur d’administration, OpenSSL permet de lire et de contrôler un certificat PEM :

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Remplacer firewall.pem par le chemin local du fichier. La sortie doit afficher le Subject attendu, l’émetteur, la période de validité, les SAN requis et une empreinte SHA-256. La commande ne lit aucune clé privée.

Pour un certificat généré en externe, la clé publique dérivée de la clé privée doit correspondre à la clé publique du certificat :

(
tmpdir=$(mktemp -d)
trap 'rm -rf -- "$tmpdir"' EXIT
openssl x509 -in firewall.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
  openssl pkey -in firewall.key -pubout > "$tmpdir/key-public-key.pem" &&
  cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Remplacer firewall.key par le chemin local de la clé privée. Si la clé est chiffrée, openssl pkey demande le mot de passe de manière interactive. cmp ne produit aucune sortie lorsque les clés publiques sont identiques ; dans le cas contraire, la paire ne doit pas être importée. Les fichiers temporaires contiennent uniquement des clés publiques, mais sont tout de même supprimés après la comparaison. Ne jamais afficher ni uploader la clé privée, ni la joindre à un ticket.

Contrôler le service HTTPS depuis l’extérieur

Tester WebAdmin, les portails et WAF depuis un ordinateur d’administration avec OpenSSL :

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Remplacer le FQDN et le port par ceux du véritable service HTTPS. -servername transmet le nom via SNI afin que le bon certificat soit sélectionné lorsqu’il existe plusieurs cibles WAF ou portails. -showcerts affiche tous les certificats envoyés par le service ; le serveur ne doit normalement pas envoyer la CA racine. Le certificat serveur attendu et les CA intermédiaires nécessaires à la construction de la chaîne doivent figurer dans cette sortie. Verification: OK confirme en outre la vérification du nom d’hôte et de la chaîne par rapport au Trust Store de l’ordinateur de test. Une CA intermédiaire qui y est déjà présente peut toutefois masquer une chaîne incomplète fournie par le serveur.

Avec une CA interne, l’ordinateur d’administration doit déjà faire confiance à cette CA ou la recevoir explicitement comme ancre de confiance pour le test. Dans le cas contraire, une erreur de vérification peut provenir de l’appareil de test même si le pare-feu présente la bonne chaîne.

Contrôler SMTP avec STARTTLS

SMTP sur le port 25 ou 587 démarre généralement sans chiffrement et ne passe à TLS qu’avec STARTTLS. Un test distinct est donc nécessaire :

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Remplacer mail.example.com et le port 25 par le FQDN SMTP et le port STARTTLS réellement utilisés. Pour TLS implicite sur le port 465, ne pas utiliser -starttls smtp. Ici aussi, le certificat attendu, le nom d’hôte et Verification: OK doivent correspondre.

À contrôler également dans le navigateur ou le client :

• L’URL utilise l’un des SAN inclus dans le certificat.
• L’émetteur et la date d’expiration correspondent au nouveau certificat.
• Aucun avertissement de certificat n’apparaît.
• Le service WebAdmin, portail, WAF ou de messagerie attendu fonctionne.
• Un test externe ne voit pas encore le certificat d’un Load Balancer ou Reverse Proxy placé en amont.

Erreurs typiques et contrôle suivant

• Trusted reste vide : la CA intermédiaire manque, une mauvaise CA a été importée ou la chaîne n’appartient pas au certificat serveur. Contrôler l’Issuer et l’ordre des CA.
• L’importation est refusée : contrôler le format de fichier, le mot de passe de la clé privée, la limite de 30 caractères, la paire certificat-clé et l’heure système.
• Le navigateur signale un nom incorrect : le FQDN ou l’adresse IP appelé ne figure pas dans les SAN. Comparer l’URL, le DNS et les noms du certificat.
• Le navigateur affiche toujours l’ancien certificat : le service utilise encore l’ancienne attribution ou un proxy en amont termine TLS. Utiliser openssl s_client avec SNI pour contrôler directement la cible attendue.
• WAF présente le mauvais certificat : contrôler Hosted Address, Listen Port, Domain, SNI et l’ordre des règles WAF qui se chevauchent.
• Seuls certains clients affichent un avertissement : contrôler le Trust Store, les certificats intermédiaires, l’heure système et les éventuelles restrictions de Certificate Pinning de ces clients.
• Un portail n’est plus accessible après le changement : sélectionner à nouveau l’ancien certificat, puis contrôler séparément le FQDN, le port, Device Access et la chaîne de certificats.

FAQ