Inventaire des certificats VPN : ce que le registre de la CA peut prouver
Un dossier sur le serveur, un registre de la CA, une liste de révocation et une table de sessions répondent à des questions différentes. Gardez-les séparés lorsque vous inventoriez les identités VPN.
Votre passerelle accepte un certificat client qu’elle n’a jamais vu, parce que ce avec quoi elle est configurée est un émetteur de confiance, et le certificat arrive pendant le handshake. C’est ainsi que le protocole est censé fonctionner, et c’est aussi pourquoi une liste de répertoire sur le serveur fait un mauvais inventaire. L’émetteur sait ce qu’il a créé, le serveur sait ce qui s’est connecté, et l’état de révocation sait ce qui a été retiré. Un inventaire qui mélange ces trois registres finit par affirmer une chose qu’aucun d’eux n’a dite.
La passerelle fait confiance à un émetteur, pas à une liste de fichiers
La validation compare un certificat présenté à une ancre de confiance, de sorte qu’une identité créée hier par le même émetteur se connecte sans avoir jamais existé sur le disque du serveur. Rien n’a besoin d’être copié pour cela, et personne n’a à l’approuver à la main. Les registres propres au serveur décrivent donc des arrivées, non la population d’identités qui pourraient arriver.
L’écart inverse est tout aussi embarrassant. Un répertoire peut contenir des certificats expirés, révoqués, et des identités émises pour des appareils qui n’ont jamais été déployés. Compter les fichiers répond au nombre de fichiers présents, ce qui est une question que personne n’a posée. Partez plutôt des registres qui portent un sens.
Quatre questions, quatre registres différents
Chaque type de registre répond bien à une question et mal aux autres, c’est pourquoi un rapport qui les fusionne paraît complet tout en étant faux d’une manière précise. Le tableau ci-dessous les classe selon la question qu’ils tranchent et non selon le système qui les produit.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Une archive de certificats publics n’est pas un secret, puisqu’elle ne contient aucune clé privée, mais elle n’est pas partageable non plus. Les sujets et les noms d’appareils révèlent des détails opérationnels, et le rapport doit rester auprès du public qui en a besoin. Les clés privées restent entièrement hors de l’inventaire, car l’inventaire a besoin de métadonnées et non d’identifiants.
Émetteur et numéro de série forment la seule clé stable
Les sujets sont recyclés et les noms de fichiers réutilisés, si bien qu’un nom qui désignait un appareil l’an dernier peut en désigner un autre aujourd’hui. Ni l’un ni l’autre n’est une clé, et un rapport fondé sur l’un des deux finira par fusionner deux identités sur une seule ligne.
Le couple émetteur et numéro de série identifie un certificat de façon unique, et les deux champs proviennent du certificat lui-même. Enregistrez-les avec le sujet, les dates de validité, la source d’où vient la copie et la personne ou l’appareil responsable. Ajoutez l’état de révocation et de déploiement comme champs distincts, avec leurs propres instants d’observation, car un certificat dans sa fenêtre de validité n’est pas automatiquement autorisé. Ces deux faits vivent dans des systèmes différents, et les fusionner masque le cas où une identité a été retirée alors que son fichier semble encore à jour.
Lisez un certificat à la fois
Un joker qui s’étend sur un répertoire n’est pas une interface par lots, et il cache quel fichier a produit quelle sortie. Lisez les métadonnées certificat par certificat, et lisez le volet révocation depuis son propre artefact. La référence OpenSSL x509 énumère les champs que ces options impriment.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40Pour une PKI Easy-RSA gérée, interrogez la base d’émission par le flux de travail que l’outil prend en charge au lieu de supposer une disposition de répertoires, et gardez les originaux en lecture seule pendant que l’inventaire est assemblé. Le format du registre est assez régulier pour compter les entrées valides et lister les retirées sans ouvrir la base à la main.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Un inventaire qui survit à la prochaine émission
Un vidage ponctuel d’un répertoire devient obsolète dès que le certificat suivant est émis, alors construisez le rapport à partir du flux d’émission et laissez-le se mettre à jour dans le cadre du fonctionnement normal. Cela rend aussi le rapport reproductible, ce qui compte lorsque deux personnes ne sont pas d’accord sur ce qui a été émis.
Utilisez le résultat pour des décisions de renouvellement et de mise au rebut, et non comme un exercice de tableur. Supprimer une copie locale n’invalide pas les copies distantes qui existent déjà. Retirez l’identité par le flux de révocation et d’autorisation configuré, puis enregistrez le retrait avec sa date. Une identité qui a disparu du serveur mais à laquelle l’émetteur fait encore confiance n’a pas été retirée, et cette différence sépare un inventaire exact d’un inventaire qui ne fait que rassurer.