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

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.

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.

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

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 normalement Certificate only comme finalité. Si le même fichier contient également la chaîne de CA, sélectionner la finalité adaptée au certificat et à la CA.
5. Exécuter Import certificate.

SFOS associe le certificat à la clé privée présente sur le pare-feu, puis supprime 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.

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.

Upgrade vers SFOS 21 ou une version ultérieure : vérifier les noms de CA réservés

Lors du premier upgrade d’une installation plus ancienne vers SFOS 21 ou une version ultérieure, 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 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. 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 à un seul service.
5. Tester ce service avec son FQDN et son port réels.
6. En cas d’erreur, sélectionner immédiatement l’ancien certificat.
7. Migrer les autres services un par un 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.

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.

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.

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

Pour Mail Protection, sélectionner le nouveau certificat serveur dans le champ TLS certificate sous Email > General settings > SMTP TLS configuration, puis enregistrer avec Apply. Un certificat émis par une CA publique est recommandé pour les communications SMTP publiques afin que les systèmes distants puissent vérifier l’identité sans qu’une CA leur soit distribuée. 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.

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 -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. Le contrôle réussit lorsque le certificat attendu s’affiche, que le nom d’hôte correspond et que la sortie se termine par Verification: OK.

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