Stormshield Network Security – Émission de certificats par une IGC (PKI) tierce

Selon la recommandation 34 du guide de l’ANSSI (ANSSI-BP-031) sur les « Recommandations pour une configuration sécurisée d’un pare-feu Stormshield Network Security (SNS) en version 3.7.17 », il est recommandé d’utiliser une Infrastructure de Gestion de Clés (IGC ou PKI en anglais) externe à l’équipement SNS. Dans ce cas-là, il faudra donc générer des demandes de signatures de certificats (CSR) à destination de l’IGC (PKI) externe.

De plus, il utile dans certains cas de signer une demande de certificat par une autorité de certification reconnue, comme Let’s Encrypt ou GlobalSign par exemple. Cela permet notamment de mettre en place un portail d’authentification (VPN SSL, portail WiFi) sans défaut de certificat.

Qu’est-ce qu’un CSR ? Un CSR (Certificate Signing Request) est un message envoyé à partir d’un demandeur à une autorité de certification afin de demander un certificat d’identité numérique.

Vous pouvez avoir besoin de certificats sur un UTM SNS pour de multiples raisons (Certificats pour des tunnels IPSEC, Webadmin, portail d’authentification, …).

Cette méthode permet de garantir la confidentialité de la clé privée. En effet, cette dernière ne quittera jamais le pare-feu.

Prérequis obligatoires :

• Avoir un accès Web sur l’UTM Stormshield
• Dans le cas de Let’s Encrypt, pouvoir éditer les zones DNS publiques associées
• Chaîne complète de certification (Autorité racine et le cas échéant l’autorité intermédiaire)

Outils :

• OpenSSL en CLI
  • Windows : https://slproweb.com/products/Win32OpenSSL.html
  • Linux : L’installer depuis le dépôt des paquets
• SCP, PSCP ou WinSCP

---

Génération du CSR sur l’UTM

Selon la recommandation 16 du guide de l’ANSSI (ANSSI-BP-031), il est recommandé d’utiliser les commandes SERVERD depuis l’interface web.

Se connecter en WebAdmin au boîtier, puis aller dans « SYSTEM > CLI » :

On vérifie en tout premier lieu si il y a des demandes de signatures de certificats en attente :

> PKI REQUEST LIST

En cas de présence de précédentes demandes, il est possible de les supprimer avec la commande suivante :

> PKI REQUEST REMOVE name="exemple"

Pour créer la demande de certificat, taper la commande suivante (en modifiant les arguments pour correspondre à votre cas) :

> PKI REQUEST CREATE type=server cn=<common_name> C=<country> ST=<state> L=<city> O=<company> OU=<IT> shortname=mycertname size=<1024,2048 ou 4096 bits>

L’ANSSI, dans son « Guide de Sélection d’Algorithmes Cryptographiques » (ANSSI-PA-079), recommande d’utiliser pour le dimensionnement du schéma asymétrique RSA, des modules RSA d’au moins 3072 bits (Recommandation R16). Oubliez donc les tailles en dessous de 4096 bits.

Le shortname est le nom convivial de votre demande.
Soit par exemple :

> PKI REQUEST CREATE type=server cn=portal.lab.info-sec.fr C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab shortname=portal.lab.info-sec.fr_20032021 size=4096

N.B : Sur les modèles SN1100, SN2100, SN3100 et SN6100, il est possible de chiffrer la clé avec une clé symétrique stockée sur le TPM présent sur ces modèles. Il s’agit du paramètre tpm=ondisk et tpmpassword=<password>

De mon côté je trouve que c’est une bonne pratique de nommer clairement votre demande, notamment en indiquant le Common Name et la date.

N.B : Il est possible de générer un certificat avec un wildcard comme Common Name (utile si vous avez des noms DNS différents pour le portail d’authentification et le webadmin). Cela donnerait par exemple :

> PKI REQUEST CREATE type=server cn=*.lab.info-sec.fr C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab shortname=*.lab.info-sec.fr_20032021 size=4096

Parallèlement, vous pouvez également choisir quel type de clé vous voulez générer :

• Chiffrement traditionnel :
  • RSA -> avec les tailles suivantes : 2048 et 4096 bits
• Chiffrement sur courbes elliptiques:
  • SECP -> avec les tailles suivantes : 256, 384 et 521 bits
  • Brainpool -> avec les tailles suivantes : 256, 384 et 512 bits

Il existe différentes manières de récupérer la demande de signature de certificat :

Télécharger directement depuis le webadmin :

C’est la méthode que je recommande. De cette façon, vous n’avez pas besoin d’initialiser une connexion SSH avec le pare-feu.

Grâce à la commande suivante, on génère un fichier à télécharger depuis le webadmin :

> PKI REQUEST GET name=portal.lab.info-sec.fr_20032021 format=pem

Le pare-feu propose ensuite de télécharger la demande de signature de certificat au format base64 :

Générer un fichier temporaire directement sur le firewall

Il faudra dans ce cas récupérer le fichier. Je ne vous recommande pas cette méthode, étant donné qu’il faudra accéder en SSH au pare-feu, et que l’on dérogerait à la recommandation n°16 :

1. Pour générer le fichier de demande, taper la commande suivante (avec le nom convivial précédemment donné) :

> PKI REQUEST GET name=portal.lab.info-sec.fr_20032021 format=pem > /tmp/ portal.lab.info-sec.fr_20032021.csr

2. En cas de réussite, la console renvoie le message : « OK » l faut ensuite récupérer le fichier généré.

• Par exemple la commande scp qui permet de copier des fichiers depuis un serveur SSH distant :

> scp [email protected]:/tmp/ portal.lab.info-sec.fr_20032021.csr portal.lab.info-sec.fr_20032021.csr

• Ou en utilisant WinSCP

---

Signature du certificat sur l’IGC (PKI)

C’est ici que l’IGC externe doit signer la demande de certificat. Ceci différera selon l’IGC utilisée, mais sous l’IGC de Microsoft AD CS (Active Directory Certificates Services), il faudra forcer le modèle utilisé pour la signature. En effet, le CSR généré par l’UTM Stormshield ne contient pas l’indication du modèle de certificat à utiliser.

Pour forcer le modèle sous ADCS :

certreq.exe -submit -attrib “CertificateTemplate:<TemplateName>” <certificateSigningRequest.csr>

Soit par exemple :

certreq.exe -submit -attrib “CertificateTemplate:SNSFirewall” portal.lab.info-sec.fr_20032021.csr

---

Import du certificat signé sur l’UTM

C’est ici que nous allons importer le certificat signé par l’IGC sur le pare-feu. Cette action liera la clé privée précédemment générée avec ce certificat, sous forme d’objet de type certificat.

Si le pare-feu SNS ne possède pas encore la chaîne de certification complète de l’IGC, il est nécessaire de l’importer. En effet, sans cette chaîne complète, certains systèmes peuvent se mettre en erreur face au certificat proposé par le pare-feu SNS. Nous ferons l’essai plus bas avec les binaires d’OpenSSL. De manière générale, sans parler de pares-feux SNS, toujours penser à bien construire la chaîne complète de certification. Certains (beaucoup) sites commerciaux l’omettent bien trop souvent.

Sur l’interface web d’administration de l’UTM, aller dans le menu latéral gauche de configuration, dans la section « Objets », puis dans « Certificats et PKI ».

• Cliquer sur « Ajouter », puis dans le menu contextuel, choisir l’option « Importer un fichier ».
• Importer dans cet ordre :
  1. Le certificat de l’autorité de certification racine
  2. Le ou les certificats de l’autorité de certification intermédiaire
  3. Le certificat de l’équipement généré par l’IGC

Une fois importée, la chaîne de certification doit ressembler à cela :

Vous pouvez également lister les certificats émis par une IGC tierce via la commande suivante :

pki certificate list caname=<ca_name>"

Soit par exemple :

pki certificate list caname="cn=intermediate-ca C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab"

⚠️ Attention : Comme l’explique le guide de l’ANSSI (ANSSI-BP-031) sur la recommandation R36, les pares-feux Stormshield Network Security ne prennent pas en compte le champ CRLDP (Certificat Revocation List Distribution Point). Je vous renvoie à mon article dédié à ce sujet : https://www.info-sec.fr/index.php/2021/11/09/stormshield-network-security-parametrage-avance-crldp/

---

Test et vérification du bon fonctionnement

Dans le cadre d’utilisation du certificat pour la sécurisation des serveurs webs embarqués (portail d’authentification et webadmin), OpenSSL permet de tester son bon fonctionnemen. Si vous êtes sur Windows, je vous recommande les binaires suivants : https://slproweb.com/products/Win32OpenSSL.html

Sur Linux, vous pouvez installer OpenSSL depuis votre gestionnaire de paquets habituel si ce dernier n’est pas déjà installé.

Par exemple, dans le cas où mon IGC serait hébergée chez GlobalSign :

> openssl s_client -connect 10.0.0.254:443 -servername portal.lab.info-sec.fr -CAfile '.\R3 GlobalSign Root Certificate.cer'

Ou par exemple, dans le cas où mon IGC est interne :

> openssl s_client -connect 10.0.0.254:443 -servername portal.lab.info-sec.fr -CAfile '.\root-ca-lab-info-sec.cer'

Ou par exemple, dans le cas où mon webadmin n’écoute pas sur un port standard :

> openssl s_client -connect 10.0.0.254:64443 -servername portal.lab.info-sec.fr -CAfile '.\root-ca-lab-info-sec.cer'

---

Quelques commandes utiles avancées

Vous pouvez renommer le nom de l’objet SNS contenant le couple certificat/clé privé avec la commande suivante (pour par exemple mettre un friendly name sur l’objet) :

pki certificate rename name=<old_name> newname=<new_name>

Soit par exemple :

pki certificate rename name="portal.lab.info-sec.fr C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab" newname="portal.lab.info-sec.fr_20032021"

Enfin, il est possible d’afficher des détails d’un certificat non présent dans le GUI :

pki certificate show name="portal.lab.info-sec.fr_20032021" caname="cn=intermediate-ca C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab"

Et pour afficher un output complet, semblable à OpenSSL :

pki certificate show name="portal.lab.info-sec.fr_20032021" caname="cn=intermediate-ca C=ES ST=Catalunya L=Barcelona O=Info-Sec OU=Lab" full=1

---

Cet article se base sur l’article de la base de documentation de Stormshield :

• https://kb.stormshield.eu/en/network-security/sns-appliance/objects/certificates-and-pki/how-can-i-create-a-csr-certificate-signing-request
• https://documentation.stormshield.eu/SNS/v4/fr/Content/CLI_Serverd_Commands_reference_Guide_v4/Commands/serverd/PKI.REQUEST.htm