Importer des CRL et révoquer des certificats sur Sophos Firewall

Une Certificate Revocation List (CRL) externe s’importe sous Certificates > Certificate revocation lists > Add. Le fichier doit provenir de la CA qui a émis le certificat concerné. Avant l’import, il faut vérifier l’émetteur, la signature, thisUpdate, nextUpdate et les numéros de série révoqués. Ensuite, une entrée visible dans la liste ne suffit pas comme preuve : le service concerné doit être testé avec un certificat valide et, dans un environnement contrôlé, avec un certificat révoqué.

La procédure diffère pour les certificats signés localement. SFOS peut les révoquer lui-même et ajoute automatiquement leurs données à la CRL locale. En revanche, un certificat signé à l’extérieur doit être révoqué par la CA externe ; le pare-feu ne peut pas créer lui-même cette révocation.

Importer une CRL en huit étapes

1. Documenter le certificat concerné, son émetteur, son numéro de série et le service du pare-feu qui l’utilise.
2. Préparer une sauvegarde, un accès de gestion indépendant et un certificat de remplacement valide.
3. Obtenir une CRL complète et actuelle auprès de la CA émettrice. Ne pas utiliser la CRL d’une autre CA au nom similaire.
4. Sur un poste d’administration, lire le fichier au format DER ou PEM et vérifier l’émetteur, la signature, thisUpdate et nextUpdate.
5. Confirmer que la chaîne de CA associée est présente sous Certificates > Certificate authorities.
6. Sous Certificates > Certificate revocation lists > Add, saisir un nom explicite, sélectionner le fichier CRL et cliquer sur Save.
7. Effectuer un test positif normal avec un certificat toujours valide et un test négatif contrôlé avec un certificat de test révoqué.
8. Documenter le responsable, la source et la date de renouvellement avant nextUpdate.

⚠️ Ne pas révoquer un certificat affecté à la production ni la Default CA uniquement pour tester la fonction. WebAdmin, les portails, le VPN ou d’autres services de gestion et tunnels pourraient cesser de fonctionner. La révocation est d’abord testée avec un certificat émis spécialement à cet effet et avec une voie de récupération confirmée.

Distinguer expiration et révocation

Un certificat peut rester valable plusieurs mois tout en n’étant plus digne de confiance. Cela peut arriver si sa clé privée a été compromise, si son titulaire a perdu son autorisation ou si le certificat ne doit plus être utilisé pour son objectif initial. La CA révoque alors le numéro de série et publie cet état dans une CRL.

Une CRL contient notamment :

• l’Issuer, c’est-à-dire l’entité qui a signé la CRL ;
• thisUpdate, la date d’émission de cette liste ;
• nextUpdate, la date limite annoncée par la CA pour une nouvelle liste ;
• le numéro de série et la date de révocation des certificats révoqués ;
• une signature numérique permettant d’en vérifier l’origine et l’intégrité.

Le nom du fichier n’a aucune valeur de confiance à lui seul. Un fichier nommé vpn-current.crl peut être obsolète ou appartenir à une autre CA émettrice. L’émetteur, la signature, l’actualité et le numéro de série du certificat concerné sont déterminants.

Signature locale ou externe

SFOS sépare deux responsabilités :

• Certificat signé localement : Le pare-feu a signé le certificat avec sa CA interne. Il peut être révoqué sous Certificates > Certificates. SFOS ajoute automatiquement la révocation à la CRL locale correspondante.
• Certificat signé à l’extérieur : Une CA d’entreprise ou publique externe a émis le certificat. Seule cette CA peut publier la révocation. La CRL actuelle est ensuite chargée sur le pare-feu sous forme de fichier.

Une CRL externe ne remplace pas la chaîne de CA associée. Le certificat, la CA émettrice, les éventuelles CA intermédiaires et la CRL doivent correspondre. Importer et affecter des certificats sur Sophos Firewall explique comment distinguer certificats, clés privées, CSR et chaînes de CA.

Préparer le fichier CRL en toute sécurité

Avant toute modification, il faut relever l’état actuel :

• le nom, l’émetteur et le numéro de série du certificat concerné ;
• l’émetteur de la CRL et sa source de confiance ;
• les valeurs actuelles de thisUpdate et nextUpdate ;
• le service concerné et son test positif fonctionnel ;
• le responsable PKI ;
• la sauvegarde et la voie de récupération si la validation du certificat bloque l’accès en production.

L’heure du pare-feu doit être correcte. Une date incorrecte peut faire apparaître des certificats et des listes de révocation comme obsolètes ou pas encore valides. Si nécessaire, vérifier la source de temps et la configuration NTP avec Configurer l’heure système et NTP de Sophos Firewall.

Associer le certificat et la CRL

Sur un poste d’administration, OpenSSL affiche l’émetteur et le numéro de série d’un certificat PEM :

openssl x509 -in client-cert.pem -issuer -serial -noout

client-cert.pem est remplacé par le fichier de certificat local. La commande lit uniquement les métadonnées et n’affiche aucune clé privée.

Une CRL encodée en DER se vérifie ainsi :

openssl crl -in corp-issuing-ca.crl -inform DER -issuer -lastupdate -nextupdate -crlnumber -noout

Pour une CRL encodée en PEM, remplacer DER par PEM. corp-issuing-ca.crl est un exemple et doit être remplacé par le fichier de la CA émettrice de l’environnement. L’Issuer affiché doit correspondre à la chaîne de certificats prévue, et nextUpdate ne doit pas être dépassé pour la période d’exploitation planifiée.

Vérifier la signature et les numéros de série révoqués

La signature se vérifie avec un fichier de CA préparé :

openssl crl -in corp-issuing-ca.crl -inform DER -CAfile corp-ca-chain.pem -verify -noout

corp-ca-chain.pem contient le certificat du signataire de la CRL et la chaîne de CA nécessaire à sa vérification. Ce fichier est fourni par le responsable PKI et n’est pas assemblé à partir d’une source de téléchargement quelconque. Si la CA fournit une CRL PEM, remplacer également DER par PEM ici.

Pour afficher tous les détails de la CRL, y compris les numéros de série révoqués, utiliser :

openssl crl -in corp-issuing-ca.crl -inform DER -text -noout

Pour de grandes CA d’entreprise, la sortie peut être longue. Elle ne contient aucune clé privée, mais elle inclut des métadonnées PKI internes et des numéros de série. Elle ne doit donc pas être copiée sans filtrage dans des tickets publics, des chats ou des captures d’écran.

Importer une CRL externe dans SFOS

Une CRL externe est obtenue uniquement auprès de la CA responsable ou de son processus PKI de confiance. Un fichier provenant d’un ancien ticket ou d’un partage de fichiers non documenté n’est pas une source fiable.

1. Ouvrir Certificates > Certificate revocation lists.
2. Sélectionner Add.
3. Saisir un nom explicite, par exemple Corp-Issuing-CA-CRL.
4. Sélectionner le fichier .crl vérifié au préalable.
5. Cliquer sur Save.
6. Confirmer que la nouvelle entrée apparaît dans la liste des CRL.
7. Exécuter les tests positif et négatif prévus pour le service concerné.
8. Consigner nextUpdate, le responsable et la source dans la documentation d’exploitation.

Corp-Issuing-CA-CRL n’est qu’un exemple. Il doit être remplacé par un nom qui identifie la CA émettrice réelle et son objectif. Les noms comme Current ou New CRL sont à éviter, car ils ne permettent plus d’identifier clairement un responsable après quelques mois.

L’aide actuelle de SFOS 22 ne documente pas, sur cette page, de récupération automatique depuis une URL HTTP ou LDAP. Un import unique ne constitue donc pas un processus d’exploitation permanent. Avant nextUpdate, une nouvelle liste est obtenue auprès de la CA, vérifiée à nouveau et mise à jour sur SFOS selon le processus CRL approuvé. L’ancienne liste n’est pas supprimée avant l’acceptation du nouveau fichier et un nouveau test du service concerné.

Révoquer un certificat signé localement

Un certificat signé localement se révoque directement sur le pare-feu. Il faut d’abord déterminer s’il protège encore WebAdmin, un portail, le VPN, WAF, SMTP ou un autre service. Si c’est le cas, un certificat de remplacement valide est d’abord affecté et testé.

1. Sous Certificates > Certificates, identifier le certificat signé localement.
2. Revérifier son Subject, son Issuer, son objectif et son affectation au service.
3. Confirmer la sauvegarde et l’accès de gestion indépendant.
4. Dans la ligne du certificat, exécuter l’action de révocation pour ce certificat précis.
5. Sous Certificates > Certificate revocation lists, rechercher la CRL de la CA locale associée.
6. Sélectionner Download. SFOS fournit une archive .tar dont le fichier .crl est extrait.
7. Lire la CRL téléchargée avec OpenSSL et comparer le numéro de série du certificat de test.
8. Retester le service réel de manière positive et négative.

Sophos n’autorise cette révocation directe que pour les certificats signés localement. Si l’action de révocation n’apparaît pas pour un certificat externe, il ne s’agit pas d’une erreur de l’interface. La CA externe doit révoquer le certificat et émettre une CRL mise à jour.

Vérifier l’effet de la liste de révocation

Un import réussi confirme uniquement que SFOS a accepté le fichier. Il ne prouve pas à lui seul que le service prévu évalue la CRL dans son chemin d’authentification concret. Une validation fiable comporte donc plusieurs niveaux :

1. Fichier : L’émetteur, la signature, thisUpdate, nextUpdate et le numéro de série sont corrects.
2. Liste SFOS : L’entrée CRL attendue est visible après l’enregistrement.
3. Test positif : Un certificat toujours valide de la chaîne de confiance prévue fonctionne.
4. Test négatif : Un certificat de test émis et révoqué à cet effet est refusé pendant une fenêtre de maintenance.
5. Log du service : L’heure, le certificat et le motif de refus correspondent au test.
6. Exploitation : Après une mise à jour de CRL et un basculement HA planifié, une nouvelle connexion est établie et testée.

Le bon log dépend du service. Pour IPsec avec certificats, charon.log est une piste importante ; le flux complet se trouve dans Dépannage IPsec VPN sur Sophos Firewall. Les autres fonctions utilisent d’autres logs. Associer correctement les logs de services Sophos Firewall relie ces fonctions à access_server.log, sslvpn.log, csc.log et à d’autres fichiers.

Une capture de paquets peut montrer l’établissement et l’interruption d’une connexion, mais ne prouve pas automatiquement une décision de CRL. Le log du service, les données du certificat et le cas de test contrôlé sont plus importants pour cette vérification.

Maintenir les CRL à jour en exploitation

Une CRL a besoin d’un responsable et d’un processus de renouvellement. Avec une CA externe en particulier, la mise à jour ne doit pas dépendre de la mémoire d’une seule personne.

Les informations d’exploitation utiles sont :

• l’équipe PKI ou pare-feu responsable ;
• la CA exacte et la source de confiance ;
• l’intervalle de mise à jour attendu ;
• nextUpdate de la liste actuellement importée ;
• les services du pare-feu et cas de test concernés ;
• le dernier test positif et négatif réussi ;
• la procédure de révocation imprévue après compromission d’une clé.

Après une révocation urgente, il ne faut pas attendre la date de révision normale. La CA externe fournit une CRL mise à jour, qui est vérifiée, importée et testée sur le service concerné. Avant toute modification de certificats de production, conserver une sauvegarde actuelle du pare-feu avec une voie de récupération vérifiée.

Dans un cluster HA, une entrée visible sur les deux nœuds ne suffit pas à conclure à un comportement d’exécution identique. Après un basculement planifié, établir une nouvelle connexion et examiner le log du nœud qui a réellement traité le test.

Délimiter systématiquement les erreurs

SFOS refuse le fichier CRL

Vérifier d’abord sur le poste d’administration que le fichier est réellement une CRL et qu’il est encodé en DER ou PEM. Un certificat renommé, le téléchargement HTML d’une page d’erreur de portail ou une archive endommagée ne constitue pas une liste de révocation valide. Vérifier ensuite l’émetteur, la signature et la chaîne de CA.

Ne pas convertir le fichier avec un convertisseur en ligne ou un site web inconnu. Si un autre format est requis, effectuer la conversion localement avec OpenSSL ou demander à la CA de fournir à nouveau la CRL dans le format nécessaire.

L’import fonctionne, mais le certificat révoqué également

Vérifier les points suivants dans l’ordre :

• Le certificat et la CRL proviennent-ils réellement de la même CA émettrice ?
• Le numéro de série du certificat figure-t-il dans la CRL ?
• La CRL est-elle actuelle ou nextUpdate est-il déjà dépassé ?
• L’heure du pare-feu est-elle correcte ?
• Le test utilise-t-il réellement le certificat attendu et non un autre certificat issu d’un cache, d’un profil ou d’une affectation de service ?
• Une nouvelle connexion a-t-elle été établie ou une session existante a-t-elle simplement continué ?
• Le log spécifique au service montre-t-il une validation de certificat ou de révocation ?

Si l’un de ces éléments fondamentaux manque, ne pas expérimenter avec des redémarrages de services ou des modifications de la Default CA. Il faut d’abord prouver la CA, le numéro de série, la CRL actuelle et le chemin réel de la connexion.

Un certificat externe ne peut pas être révoqué dans SFOS

Il s’agit de la limite attendue du produit. Le pare-feu ne peut révoquer lui-même que les certificats signés localement. Pour un certificat signé à l’extérieur, la révocation est déclenchée auprès de la CA externe, puis sa nouvelle CRL est importée.

Un service tombe en panne après une révocation locale

Utiliser d’abord l’accès de gestion ou à la console préparé. Affecter au service concerné un certificat de remplacement valide préalablement vérifié. Le certificat révoqué ne doit pas être réutilisé comme solution de production. Vérifier ensuite à nouveau le service, les logs et le certificat réellement présenté.

Si les services dépendant de la CA ou de la CRL ne sont pas clairs, ne révoquer aucun autre certificat et ne supprimer aucune liste de révocation. Enregistrer plutôt la configuration, les affectations de certificats et les données de support, puis analyser le cas avec les responsables PKI ou Sophos Support.

FAQ