Vérifiez le certificat CMVP derrière l'affirmation FIPS d'un VPN

Les pages de fournisseurs qui affirment FIPS validated ne sont pas une preuve que vous pouvez classer. La preuve, c'est un numéro de certificat, un nom de module, une version validée et les conditions d'exploitation qui y sont attachées, et celles-ci doivent correspondre au build que vous déployez. La FAQ du NIST CMVP est claire sur la différence entre un produit qui revendique une compatibilité et un module qui a été validé. Suivez les quatre étapes ci-dessous dans l'ordre et conservez la trace avec le déploiement.

Étape 1 : obtenir le numéro de certificat, pas le badge

Demandez au fournisseur le numéro de certificat CMVP qui couvre le module cryptographique du produit que vous comptez exploiter. Un numéro de certificat est un objet précis et vérifiable, tandis qu'un badge relève du marketing. Si la réponse décrit un algorithme au lieu d'un module, elle a répondu à une autre question. Insistez une fois de plus pour obtenir le numéro plutôt que d'accepter un PDF de badge. La fiche derrière le numéro est ce qu'un auditeur peut suivre.

Cherchez ensuite ce numéro dans la recherche officielle des modules validés et lisez la fiche, pas un résumé. La fiche nomme le fournisseur, le module, la version validée et le statut, et elle renvoie au document de politique de sécurité qui décrit comment le module doit fonctionner.

Notez ces cinq champs, car l'étape suivante les compare au build. Une colonne dans un tableur suffit.

Étape 2 : faire correspondre la version du module au build

Une version de client VPN et une version de module embarqué partagent rarement le même numéro, et c'est normal. Ce qui compte, c'est de savoir si la version du module dans votre build figure dans la fiche validée. Une mise à jour peut changer le module sans changer le nom du produit, ce qui sort discrètement le déploiement de la configuration validée.

Demandez quel composant utilise le module et comment le mode approuvé est sélectionné dans la configuration prise en charge. Un build qui peut fonctionner en mode non approuvé n'est pas la même preuve qu'un build configuré pour le mode approuvé.

Lisez le build local, pour que la comparaison porte sur l'artefact et non sur la page de téléchargement. Les commandes ci-dessous affichent exactement cela.

openssl version -a
openssl list -providers -verbose
cat /proc/sys/crypto/fips_enabled

Lorsque le module signale une version différente de celle du certificat, l'affirmation a dérivé et la fiche doit être mise à jour avant que quiconque signe quoi que ce soit.

Étape 3 : lire les conditions d'exploitation

Le certificat porte des conditions qui décrivent l'environnement couvert par la validation. Ces conditions peuvent nommer la plateforme, la configuration, les tailles de clés autorisées et les services à restreindre. Une installation ordinaire qui les ignore est un déploiement hors de la limite validée, même lorsque le binaire est identique. C'est pourquoi le document de politique de sécurité importe autant que le numéro de certificat.

Gardez les recommandations du fournisseur à côté du certificat, car elles expliquent quels réglages sélectionnent le mode approuvé et lesquels font sortir le produit de ce mode.

Si les conditions ne peuvent pas être remplies dans votre environnement, l'affirmation honnête est que ce déploiement se situe hors de la configuration validée. Nommer la condition qui ne peut pas être remplie transforme cette affirmation en quelque chose qu'une équipe peut corriger ou accepter.

Étape 4 : confirmer le statut aujourd'hui

La fiche CMVP porte un statut, et le statut n'est pas permanent. La FAQ du NIST décrit les dates de transition de FIPS 140-2 en 2026, après lesquelles seules les validations FIPS 140-3 restent sur la liste active. Un certificat actif au moment de l'approbation de l'achat peut être historique aujourd'hui.

Historique et révoqué sont deux états différents, et chacun a sa propre signification pour l'achat. Consultez la fiche en direct plutôt qu'une capture d'écran du dossier de projet, et notez la date de votre vérification.

Demandez ensuite au responsable conformité ou achats quel statut son exigence accepte, car c'est une décision de politique et non une constatation technique. Consignez la réponse avec une date.

Vérifier la fiche par rapport au déploiement

Comparez les quatre valeurs recueillies : le numéro de certificat, la version du module issue du build, les conditions d'exploitation en vigueur et le statut actuel. Tout écart est un constat, et le constat appartient au dossier de déploiement, pas à une diapositive.

Conservez la preuve avec le build, y compris la date et la personne qui a vérifié. Un répertoire par version suffit.

date -u +%FT%TZ
openssl version -a | head -3
cat /proc/sys/crypto/fips_enabled

Gardez aussi l'affirmation dans ses limites. La validation d'un module ne dit rien du traitement des protocoles du VPN, de ses décisions d'autorisation ni de sa politique de journalisation. C'est une preuve précise sur un composant cryptographique défini, et la traiter comme une note de produit est la façon dont un dossier de conformité finit par décrire quelque chose que personne n'a déployé.