Un CSR seul ne vaut pas inscription : ce qu’une CA VPN doit vérifier

Une demande de signature de certificat porte une clé publique et un sujet demandé, signés avec la clé privée correspondante. Cette signature prouve que le demandeur détient la clé. Elle ne prouve pas qu’il a droit au nom, à l’appareil ou au rôle VPN demandés, et la traiter comme si c’était le cas est exactement ce qui transforme un ticket de support en autorisation d’accès.

Deux modèles d’inscription méritent d’être comparés selon ce qu’ils lient, non selon le protocole qu’ils parlent.

Une demande revendique un nom, elle ne le prouve pas

Lisez la demande pour ce qu’elle contient réellement : une clé publique, un sujet choisi par le demandeur et une auto-signature sur les deux. Rien dans cette structure ne renvoie à votre inventaire, à votre annuaire de comptes ni à votre circuit de validation. Un sujet comme cn=finance-laptop est une chaîne que quelqu’un a tapée. Tant que le processus d’émission ne confronte pas cette chaîne à un enregistrement de confiance, le certificat est une affirmation assortie d’une signature. Cette distinction est toute la raison d’être d’un processus d’inscription.

Le corollaire compte sur le plan opérationnel. Une autorité de certification n’a jamais besoin de la clé privée du client pour émettre un certificat, et un circuit qui la réclame a confondu la signature avec la garde des clés. Gardez la génération sur le poste et n’envoyez que la moitié publique.

Comparez les modèles selon ce qu’ils lient

La signature manuelle lie ce dont l’opérateur se souvient de vérifier. Un service d’inscription automatisé lie une demande authentifiée à une décision que le service peut appliquer, et RFC 7030 décrit une conception de ce type où le client s’authentifie avant qu’un certificat soit renvoyé. La différence qui survit à un audit n’est pas l’automatisation ; c’est de savoir si le contrôle d’identité a lieu dans le chemin d’émission ou à côté.

Les deux modèles doivent encore répondre aux mêmes trois questions. Qui demande, sur quel appareil ou rôle, et pour combien de temps. Un système de tickets qui consigne les réponses fait un vrai travail ; une file où quelqu’un lorgne un nom commun ne le fait pas, quel que soit le soin apporté ensuite au formatage du certificat.

Choisissez le modèle selon le nombre d’inscriptions attendues et le renouvellement des appareils. Quelques serveurs par an survivent à une revue manuelle avec une liste de contrôle écrite. Un parc de portables, non.

Consignez le cycle de vie dès la première émission

Stockez l’identifiant du certificat, le propriétaire, l’usage prévu, l’expiration et le chemin de retrait au moment de l’émission, pas au premier incident. L’usage prévu appartient au certificat lui-même via une extension d’usage de clé, et l’enregistrement doit s’y accorder. Un certificat créé pour l’authentification client ne doit pas être indistinguable d’un certificat de serveur.

Planifiez le renouvellement et la révocation d’un appareil perdu avant d’émettre le dixième profil. Un certificat partagé à l’échelle d’un service transforme un retrait ciblé en panne, et revoir cette décision maintenant coûte bien moins cher qu’en pleine panne du vendredi.

Vérifiez le certificat émis, puis l’accès

Après l’inscription, inspectez ce qui a été émis et confirmez qu’il chaîne vers l’autorité attendue. Deux commandes couvrent les erreurs courantes : un certificat au mauvais usage et une chaîne qui ne fonctionne que parce que le client est configuré pour ignorer la validation.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Testez ensuite l’accès plutôt que l’artefact. Un certificat établit une identité, et la politique décide encore quels services cette identité peut atteindre. Vérifiez les deux, car un artefact correct assorti d’une politique trop large échoue quand même à une revue. Confirmez que le client s’authentifie et ne reçoit que les routes ou les ressources prévues. Notez ce que vous avez observé, non ce que le profil était censé faire.

Un profil qui fonctionne pour la mauvaise raison, comme un nom commun correspondant et aucun contrôle d’identité, continuera de fonctionner après la suppression du contrôle que vous croyiez avoir.