Certificats VPN : faites-le correctement sans la douleur des autosignés permanents

Ce que vous construisez réellement (et ce que « autosigné » coûte vraiment)

Quand on parle de « certificats VPN », on mélange généralement trois problèmes distincts :
identité, sécurité du transport et cycle de vie. Le tunnel VPN est le transport ; le certificat est le document d’identité ; la PKI est le moteur du cycle de vie.
Si vous ne résolvez que le transport (chiffrer les paquets) et ignorez le cycle de vie (émission, rotation, révocation, audit), vous obtenez le classique « ça marchait depuis des années »
jusqu’à ce qu’une expiration un lundi matin prenne toute la main-d’œuvre distante en otage.

Les certificats autosignés ne sont pas intrinsèquement mauvais. Ils sont simplement une promesse que vous êtes désormais l’opérateur CA, le répondeur d’incident et le programme conformité.
Si vous le faites une fois et que vous le documentez, cela peut aller. Si vous le faites de manière occasionnelle, vous finirez dans un endroit où la moitié de la flotte fait confiance à « vpn-ca-old.crt »,
un quart fait confiance à « vpn-ca-final2.crt », et le dernier quart utilise une empreinte épinglée provenant d’un message Slack.

En production, l’objectif n’est pas « utiliser une CA publique » ou « utiliser autosigné ». L’objectif est : un ancrage de confiance stable, un rayon d’impact minimal, un renouvellement automatisé,
et une histoire de révocation qui correspond à la réalité. La plupart des déploiements VPN devraient utiliser une CA privée avec une racine hors ligne et une ou plusieurs intermédiaires en ligne.
C’est le même schéma que la PKI web ; nous le faisons en privé et avec moins d’avocats.

Une règle nette : ne traitez jamais les certificats comme une configuration statique. Ce sont des identifiants avec des dates d’expiration, des contraintes cryptographiques et des conséquences opérationnelles.
Si votre intégration VPN consiste à « copier ce fichier .ovpn depuis un wiki », vous n’avez pas un programme VPN. Vous avez un programme folklorique.

Faits intéressants et contexte historique

• X.509 date de 1988, conçu pour des services d’annuaire, pas pour les flux de travail DevOps modernes. Nous l’avons hérité malgré tout, comme un ERP legacy.
• TLS a remplacé SSL en nom et en évolution du protocole ; « VPN SSL » reste utilisé en marketing longtemps après que SSL soit devenu une mauvaise idée.
• RSA a dominé pendant des décennies ; aujourd’hui, ECDSA est souvent préféré pour les performances et des certificats plus compacts, mais la compatibilité compte encore dans les clients d’entreprise.
• La dépréciation de SHA-1 n’était pas théorique — les chaînes de certificats se sont cassées à travers les écosystèmes quand les magasins de confiance et les politiques se sont durcis.
• Let’s Encrypt (2015) a normalisé l’automatisation via ACME ; même si vous ne pouvez pas utiliser des certificats publics pour le VPN, l’état d’esprit d’automatisation est le vrai cadeau.
• Le stapling OCSP est devenu courant sur le web pour réduire la latence et la charge de révocation ; les VPN sautent souvent la révocation complètement, puis s’en étonnent plus tard.
• L’ère « certificate transparency » de Chrome a forcé les CA publiques dans des logs audités ; la PKI privée n’a pas cela gratuitement, vous devez donc journaliser vos émissions vous-même.
• Heartbleed (2014) a appris aux équipes ops que « tout faire pivoter » est facile à dire et brutal à réaliser sans automatisation et inventaire.
• Les VPN étaient autrefois majoritairement site-à-site ; l’accès distant à grande échelle a rendu les identifiants par utilisateur/appareil et les durées courtes beaucoup plus importants.

Modèles PKI qui fonctionnent pour les VPN

Modèle A : PKI privée avec racine hors ligne + intermédiaire en ligne (recommandé)

C’est le modèle adulte. Vous gardez une CA racine hors ligne (idéalement littéralement éteinte, stockée en sécurité et utilisée rarement).
Vous émettez un certificat d’intermédiaire à partir de la racine. L’intermédiaire signe les certificats serveurs et clients.
Si la clé de l’intermédiaire est compromise, vous la révoquez et la remplacez sans devoir re-faire confiance à une nouvelle racine à travers le monde.

Opérationnellement, ce modèle supporte :
des certificats finaux à durée courte, un renouvellement automatisé, un déploiement progressif de nouveaux intermédiaires, et une réponse à compromission gérable.
Il rend aussi les auditeurs moins grognons, ce qui est un objectif légitime SRE.

Modèle B : CA autosignée unique utilisée pour tout (acceptable seulement à petite échelle)

Une clé CA signe tous les certificats serveur et client. Facile. Aussi : une compromission de la clé signifie « tout brûler et réenrôler la planète ».
Certaines équipes vivent ici pendant des années parce que « ça marche », jusqu’à ce qu’un ordinateur portable avec la clé CA dans un dossier Téléchargements soit volé.

Modèle C : CA publique pour l’identité serveur + CA privée pour l’identité client (parfois utile)

Si votre point d’accès VPN est accessible depuis Internet et que vous voulez éviter la distribution d’ancrages de confiance pour le certificat serveur, utiliser une CA publique pour le serveur
peut avoir du sens. Mais les certificats clients sont toujours un système d’identité privé ; les CA publiques n’émettront pas de certificats « employee-laptop-3421 » pour votre mTLS.
Vous gérerez toujours une CA privée pour l’authentification client.

Faites attention : ce modèle en deux volets crée deux cycles de vie parallèles. Si vous ne pouvez pas opérer un cycle de vie correctement, vous ne pourrez pas en opérer deux.

Modèle D : pas de certificats du tout (clé de type WireGuard)

WireGuard n’utilise pas X.509. Il utilise des clés publiques/privées statiques avec un modèle de confiance différent : vous approvisionnez les clés pairs et les IP autorisées.
Cela peut être plus simple et plus fiable — jusqu’au moment où vous avez besoin de fonctionnalités de cycle de vie d’entreprise comme l’émission centralisée, l’attestation, les durées courtes,
ou des métadonnées d’identité cohérentes entre systèmes.

Si vous êtes déjà complètement sur WireGuard, vous faites toujours du « cycle de vie des identifiants ». Vous l’avez simplement sorti de la PKI pour le placer dans la gestion des clés et l’inventaire.
La discipline opérationnelle est toujours requise.

Décisions de conception qui changent les résultats

Choisissez votre stratégie d’ancrage de confiance : une racine, plusieurs intermédiaires

Les ancres de confiance sont coûteuses à changer. Traitez la CA racine comme une dépendance plateforme : stable, ennuyeuse et rarement touchée.
Faites tourner les intermédiaires plus souvent. Faites tourner les certificats leaf fréquemment. Voilà la pyramide.

Utilisez des certificats leaf à courte durée (et automatisez le renouvellement)

Les certificats clients de longue durée semblent pratiques. Ils ne le sont pas. Ils transforment le désenrôlement en théâtre de révocation et rendent la compromission de clé plus précieuse.
Une bonne cible pour les certificats leaf clients est de quelques jours à quelques mois, selon la maturité de la gestion des appareils et la vitesse de réenrôlement.

Décidez ce que « identité » signifie : utilisateur, appareil, ou les deux

Si l’identité du certificat correspond uniquement à un utilisateur, tout appareil détenant la clé peut l’usurper. Si elle correspond uniquement à un appareil, le contrôle d’accès au niveau utilisateur est plus difficile.
Beaucoup d’organisations font les deux : certificat d’appareil pour l’enrôlement et les vérifications de posture, plus authentification utilisateur (SSO/OIDC) pour l’identité de session.
Ne laissez pas le CN du certificat devenir votre base RH. Mettez des identifiants stables dans SAN/URI ou des extensions personnalisées, et gardez l’autorisation ailleurs.

Révocation : faites-le correctement ou n’en faites pas semblant

CRL et OCSP existent pour une raison. Mais la révocation est opérationnellement compliquée dans les VPN car les clients peuvent être hors ligne, et les serveurs VPN doivent récupérer et mettre en cache le statut.
Si vous ne pouvez pas garantir une information de révocation fraîche, votre véritable contrôle de sécurité devient la durée des certificats. Des durées courtes réduisent le besoin de révocation.

Choix d’algorithme : ECDSA vs RSA, et ce que vos clients supportent réellement

ECDSA est rapide et compact. RSA est omniprésent et banal. La bonne réponse est souvent « RSA pour une compatibilité maximale » sauf si vous avez prouvé que votre parc client
supporte ECDSA proprement. Mixer les algorithmes dans différents éléments de la chaîne peut aussi déstabiliser les piles plus anciennes. Testez avec les pires appareils que vous supportez encore.

Une citation à tatouer sur vos runbooks

L’espoir n’est pas une stratégie. (idée paraphrasée souvent utilisée en ingénierie et opérations)

Si votre plan de certificats repose sur l’espoir que les gens renouvellent avant l’expiration, que les révocations se propagent, ou que personne ne copie la clé CA,
vous ne faites pas de la PKI. Vous faites des vibes.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que vous pouvez exécuter aujourd’hui. Chacune inclut : la commande, ce que la sortie signifie, et la décision à prendre en conséquence.
Utilisez-les pendant les incidents, les audits, et les conversations « pourquoi ce client échoue alors que d’autres fonctionnent ? ».

Tâche 1 : Vérifier quand expire le certificat serveur VPN (certificat leaf)

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.internal
issuer=CN = vpn-intermediate-01
notBefore=Sep 10 00:00:00 2025 GMT
notAfter=Dec  9 00:00:00 2025 GMT

Sens : C’est le certificat serveur leaf, émis par votre intermédiaire. Il expire le 9 déc.
Décision : Si « notAfter » est dans votre fenêtre de rotation (par exemple 14–30 jours), renouvelez maintenant et planifiez le déploiement.
S’il est déjà expiré, votre incident est probablement « les clients ne peuvent pas se connecter » avec des erreurs TLS.

Tâche 2 : Vérifier une chaîne de certificats par rapport au bundle CA utilisé par le client

cr0x@server:~$ openssl verify -CAfile /etc/openvpn/pki/ca-bundle.pem /etc/openvpn/pki/issued/vpn-server.crt
/etc/openvpn/pki/issued/vpn-server.crt: OK

Sens : Le certificat serveur fait correctement chaîne jusqu’au bundle CA fourni (racine + intermédiaires).
Décision : Si vous obtenez « unable to get local issuer certificate », votre bundle est incorrect ou incomplet ; corrigez le packaging avant de toucher la crypto.

Tâche 3 : Inspecter les SAN et Extended Key Usage (EKU) pour l’authentification serveur

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -text | sed -n '/Subject Alternative Name/,+2p;/Extended Key Usage/,+1p'
            X509v3 Subject Alternative Name:
                DNS:vpn.example.internal, DNS:vpn
            X509v3 Extended Key Usage:
                TLS Web Server Authentication

Sens : Les clients qui valident le nom d’hôte utiliseront le SAN, pas le CN. EKU inclut l’authentification serveur.
Décision : Si le SAN ne contient pas le nom utilisé par les clients, corrigez les modèles d’émission. Si l’EKU est faux, certains clients refuseront le certificat entièrement.

Tâche 4 : Confirmer que la clé privée correspond au certificat

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/vpn-server.crt -noout -modulus | openssl md5
MD5(stdin)= 4c3c9c0d27a8e8b6d1a6c5f4e0a1b2c3

cr0x@server:~$ openssl rsa -in /etc/openvpn/pki/private/vpn-server.key -noout -modulus | openssl md5
MD5(stdin)= 4c3c9c0d27a8e8b6d1a6c5f4e0a1b2c3

Sens : Des hachages correspondants signifient que la clé et le certificat correspondent.
Décision : S’ils diffèrent, vous avez déployé une paire clé/cert incorrecte. Corrigez cela avant de dépanner autre chose.

Tâche 5 : Tester la poignée de main TLS depuis un point de vue réseau client

cr0x@server:~$ openssl s_client -connect vpn.example.internal:443 -servername vpn.example.internal -showcerts -verify 5
depth=2 CN = vpn-root
verify return:1
depth=1 CN = vpn-intermediate-01
verify return:1
depth=0 CN = vpn.example.internal
verify return:1
Verify return code: 0 (ok)

Sens : La poignée de main réussit, la chaîne est vérifiée et le SNI est correct.
Décision : Si la vérification échoue ici mais fonctionne sur le serveur, vous avez probablement un middlebox, un point de terminaison erroné, ou un certificat servi incorrect par le load balancer.

Tâche 6 : Voir quel certificat votre point d’accès VPN sert réellement (vérification load balancer)

cr0x@server:~$ echo | openssl s_client -connect 203.0.113.10:443 -servername vpn.example.internal 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = vpn-old.example.internal
issuer=CN = vpn-intermediate-00
notBefore=Jun  1 00:00:00 2025 GMT
notAfter=Sep  1 00:00:00 2025 GMT

Sens : Votre IP publique sert un ancien certificat d’un ancien intermédiaire et il est expiré.
Décision : Arrêtez de faire des rotations de certificats sur l’hôte backend en oubliant la porte d’entrée. Mettez à jour immédiatement le certificat du load balancer/ingress.

Tâche 7 : Vérifier les logs du serveur OpenVPN pour erreurs TLS-auth et vérification de certificat

cr0x@server:~$ sudo tail -n 30 /var/log/openvpn/server.log
VERIFY ERROR: depth=0, error=certificate has expired: CN=alice-laptop-17
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error

Sens : Le certificat client a expiré ; le serveur le refuse.
Décision : Ré-émettez le certificat client (ou réenrôlez via votre gestion des appareils). Si beaucoup d’utilisateurs rencontrent cela, votre programme de rotation est cassé.

Tâche 8 : Inspecter un certificat client pour l’expiration et l’EKU (authentification client)

cr0x@server:~$ openssl x509 -in /tmp/alice.crt -noout -subject -dates -ext extendedKeyUsage
subject=CN = alice-laptop-17
notBefore=Oct  1 00:00:00 2025 GMT
notAfter=Oct 31 00:00:00 2025 GMT
X509v3 Extended Key Usage:
    TLS Web Client Authentication

Sens : Certificat client à durée courte avec EKU correct.
Décision : Si l’EKU n’inclut pas « client authentication », certains serveurs le rejettent. Si l’expiration est trop courte pour votre pipeline d’enrôlement, augmentez la durée ou corrigez l’automatisation.

Tâche 9 : Valider la CRL que vous distribuez (et sa fraîcheur)

cr0x@server:~$ openssl crl -in /etc/openvpn/pki/crl.pem -noout -lastupdate -nextupdate -issuer
lastUpdate=Dec 27 00:00:00 2025 GMT
nextUpdate=Jan  3 00:00:00 2026 GMT
issuer=CN = vpn-intermediate-01

Sens : Votre CRL est à jour et a un next update dans une semaine.
Décision : Si nextUpdate est passé, de nombreux serveurs traiteront la CRL comme périmée et soit échoueront en mode fermé (bonne sécurité, mauvais lundi), soit échoueront en mode ouvert (mauvaise sécurité, moins de tickets).

Tâche 10 : Confirmer que votre serveur VPN utilise réellement la CRL

cr0x@server:~$ sudo grep -R "crl-verify" -n /etc/openvpn/server.conf
42:crl-verify /etc/openvpn/pki/crl.pem

Sens : OpenVPN est configuré pour vérifier les révocations.
Décision : Si c’est manquant, votre désenrôlement repose entièrement sur l’expiration. Cela peut être acceptable avec des certificats leaf très courts ; sinon c’est un trou de sécurité que vous devriez admettre ouvertement.

Tâche 11 : Vérifier le magasin de confiance système pour la bonne racine/intermédiaire (client/serveur Linux)

cr0x@server:~$ sudo openssl x509 -in /usr/local/share/ca-certificates/vpn-root.crt -noout -subject -fingerprint -sha256
subject=CN = vpn-root
sha256 Fingerprint=7A:3B:1E:2C:9F:11:5D:AA:0B:1C:44:3D:9E:8F:2A:67:0E:91:2B:7C:7B:77:64:93:2F:10:9C:54:48:99:AA:01

Sens : Vous pouvez obtenir l’empreinte de la racine attendue.
Décision : Si l’empreinte ne correspond pas à ce que vous souhaitez, arrêtez-vous. Vous pourriez faire confiance à la mauvaise CA. Corrigez la distribution, puis revalidez les chaînes.

Tâche 12 : Énumérer les certificats qui vont bientôt expirer sur le serveur VPN

cr0x@server:~$ find /etc/openvpn/pki/issued -name "*.crt" -print0 | xargs -0 -n1 -I{} sh -c 'printf "%s " "{}"; openssl x509 -in "{}" -noout -enddate | cut -d= -f2' | sort -k2
/etc/openvpn/pki/issued/vpn-server.crt Dec  9 00:00:00 2025 GMT
/etc/openvpn/pki/issued/metrics-exporter.crt Jan 15 00:00:00 2026 GMT

Sens : Un inventaire rapide des dates d’expiration des certificats leaf.
Décision : Si vous ne pouvez pas produire cette sortie à la demande, vous n’avez pas de gestion de certificats — juste des surprises de certificats.

Tâche 13 : Détecter les échecs « mauvaise heure » sur les clients (sanité NTP)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:42:11 UTC
           Universal time: Sun 2025-12-28 10:42:11 UTC
                 RTC time: Sun 2025-12-28 10:42:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : L’heure est synchronisée. Les certificats sont sensibles au temps ; « not yet valid » est souvent juste une horloge cassée.
Décision : Si synchronized est « no », corrigez NTP avant de blâmer la PKI. Un portable avec une horloge déréglée ne peut pas être raisonnablement dépanné.

Tâche 14 : Confirmer les contraintes de l’intermédiaire CA (basicConstraints, keyCertSign)

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/ca/vpn-intermediate-01.crt -noout -text | sed -n '/Basic Constraints/,+3p;/Key Usage/,+2p'
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

Sens : Ce certificat est réellement autorisé à être une CA et à signer des certificats leaf et des CRL. Un path length à 0 signifie qu’il ne peut pas créer un autre intermédiaire en dessous.
Décision : Si CA:FALSE ou si l’usage clé est manquant, vous verrez des échecs de chaîne déconcertants. Ré-émettez l’intermédiaire correctement ; ne bricolez pas autour.

Blague #1 : Les certificats sont comme le lait — corrects jusqu’à ce qu’ils ne le soient plus, et alors votre matinée devient étrange très vite.

Procédure de diagnostic rapide

Quand les connexions VPN tombent, les gens sortent des incantations OpenSSL au hasard et commencent à faire tourner des clés comme un rituel. Ne le faites pas. Diagnostiquez comme un SRE :
confirmez le domaine de panne, isolez la couche, puis changez la plus petite chose qui peut la réparer.

Premier : est-ce la connectivité ou TLS ?

• Vérifiez la reachabilité du port (groupe de sécurité, pare-feu, route, DNS). Si les clients n’atteignent pas la socket, les certificats sont hors sujet.
• Puis vérifiez la poignée de main avec openssl s_client ou les logs verbeux du client VPN.

Second : identifiez quel certificat est réellement présenté

• Interrogez le point d’accès/IP public directement avec SNI et exportez le certificat leaf servi.
• Si vous êtes derrière un load balancer ou un contrôleur d’ingress, supposez que le LB sert le certificat jusqu’à preuve du contraire.

Troisième : validez la chaîne et les contraintes de nom

• Le client fait-il confiance à la bonne racine et aux intermédiaires ?
• Le certificat serveur a-t-il le SAN correspondant au nom utilisé par les clients ?
• Les EKU et usages de clé sont-ils corrects pour l’authentification serveur ?

Quatrième : vérifiez l’heure et la révocation

• Horloges client : « not yet valid » signifie presque toujours une mauvaise heure.
• CRL/OCSP : une CRL périmée ou un OCSP inaccessible peut causer des échecs intermittents selon le comportement du client.

Cinquième : décidez si vous échouez ouvert ou fermé

Certaines piles VPN traitent les échecs de révocation comme des échecs durs ; d’autres laissent passer la connexion. Aucune n’est universellement correcte.
Ce qui est inacceptable, c’est de ne pas savoir quel comportement vous exécutez en production.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : « certificate verify failed » sur certains clients seulement

Cause racine : Intermédiaire manquant dans la chaîne servie, ou magasin de confiance client manquant l’intermédiaire/la racine.

Correction : Servez la chaîne complète depuis le point d’accès VPN (leaf + intermédiaire). Distribuez un bundle CA stable aux clients et versionnez-le.

2) Symptom : tout le monde casse en même temps, juste après un weekend tranquille

Cause racine : Certificat serveur expiré ou intermédiaire CA expiré.

Correction : Surveillez les dates d’expiration ; faites la rotation avant la fenêtre. Gardez un chevauchement : déployez de nouveaux certificats tant que les anciens sont encore valides, et testez le point d’accès réel servi.

3) Symptom : « not yet valid » ou échecs intermittents étranges sur un seul portable

Cause racine : Dérive d’horloge client ou NTP défaillant.

Correction : Imposez NTP via la gestion des appareils. Pour les appareils non gérés, ajoutez une étape « vérifiez votre heure » dans les scripts de support et n’en soyez pas timide.

4) Symptom : la poignée de main échoue après que vous ayez « renforcé la sécurité » vers ECDSA

Cause racine : Clients legacy ou bibliothèques TLS qui ne supportent pas vos courbes/ciphers choisis de manière cohérente.

Correction : Validez avec votre pire client supporté. Si vous devez utiliser ECDSA, gardez RSA comme option de compatibilité ou mettez à jour les clients.

5) Symptom : les utilisateurs révoqués peuvent encore se connecter pendant des jours

Cause racine : Pas de vérification de révocation, CRL périmée, ou serveur VPN ne recharge pas la CRL.

Correction : Activez la vérification CRL, actualisez la CRL selon un planning, et rechargez le service VPN (ou confirmez qu’il se recharge automatiquement). Ou passez à des certificats à courte durée et acceptez l’expiration comme contrôle.

6) Symptom : après renouvellement, les clients obtiennent « hostname mismatch »

Cause racine : Le SAN n’inclut pas le DNS que les clients utilisent ; le CN est ignoré par la validation moderne.

Correction : Émettez des certificats serveur avec les SAN corrects. Standardisez le nom de connexion (une entrée DNS canonique) et arrêtez de laisser les gens se connecter à des alias aléatoires.

7) Symptom : « private key does not match certificate » lors du déploiement

Cause racine : L’automatisation a tiré la clé d’une exécution et le certificat d’une autre ; ou quelqu’un a copié des fichiers manuellement.

Correction : Déployez clé+cert comme une paire atomique, avec des vérifications dans le CI/CD (modulus ou empreinte de clé publique). Arrêtez le PKI basé sur SCP.

8) Symptom : échecs soudains de confiance après « nettoyage des anciennes CA »

Cause racine : Vous avez supprimé un intermédiaire/une racine encore nécessaire des magasins de confiance clients alors que les certificats leaf en dépendaient toujours.

Correction : Planifiez les transitions de CA comme des migrations : chevauchez les intermédiaires, ré-émettez les leaf, validez l’adoption par la flotte, puis retirez les anciens ancres de confiance.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exécutait OpenVPN derrière un load balancer. Ils ont renouvelé le certificat VPN sur les hôtes OpenVPN, testé depuis l’intérieur du VPC,
vu des poignées de main réussies, et fermé le ticket. Puis lundi est arrivé et les utilisateurs distants ne pouvaient plus se connecter.

La mauvaise hypothèse était subtile : « le serveur présente le certificat ». En réalité, le load balancer terminait le TLS et présentait son propre certificat.
Les serveurs OpenVPN backend n’ont jamais compté pour la présentation du certificat, donc leur renouvellement n’avait aucun effet sur l’expérience utilisateur.

Le support a passé des heures à collecter des logs clients. Les ingénieurs ont fait tourner les configurations client, redémarré OpenVPN, et même rollbacké une mise à jour noyau apparemment sans rapport.
Rien n’a changé le fait que l’IP publique servait toujours un certificat expiré du trimestre précédent.

La correction a pris des minutes : téléversez la chaîne de certificats renouvelée sur le load balancer, confirmez avec openssl s_client depuis un portable hors réseau,
puis planifiez un postmortem où « tester le point d’accès réel » est devenu une règle, pas un conseil.

Mini-récit 2 : L’optimisation qui s’est retournée

Une autre organisation a décidé que la validation des certificats était « lente ». Ils avaient un fort churn de connexions VPN dû aux clients mobiles, et quelqu’un a noté des pics CPU
lors des fenêtres de reconnexion. L’optimisation proposée : désactiver les vérifications de révocation et augmenter la durée des certificats clients de 30 jours à deux ans.

Les performances se sont améliorées. Les tickets ont diminué. L’équipe s’est félicitée d’avoir « réduit la complexité ». Puis l’ordinateur portable d’un sous-traitant a disparu.
Le départ a été enregistré chez RH, les comptes ont été désactivés dans le SSO, et tout le monde a supposé que l’accès VPN était aussi coupé.

Ce n’était pas le cas. Le VPN dépendait du certificat client, pas du SSO. Sans vérification de révocation et avec une durée de deux ans, la clé VPN de l’ordinateur volé restait
un jeton valide. L’organisation a eu de la chance : des motifs de trafic inhabituels ont été détectés et cela a été contenu avant devenir un titre.

La réponse à la compromission a été douloureuse : ré-émission d’urgence de la CA, réenrôlement forcé, et beaucoup de réunions « pourquoi avons-nous fait ça ».
La leçon était ennuyeuse : si vous « optimisez » en supprimant des contrôles de cycle de vie de sécurité, vous n’optimisez pas — vous déplacez le coût vers la réponse aux incidents.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise globale gérait une PKI privée avec une racine hors ligne et deux intermédiaires : « current » et « next ». Chaque trimestre, ils émettaient de nouveaux certificats serveurs
et déployaient l’intermédiaire « next » aux clients avant qu’il ne soit utilisé pour quoi que ce soit.

Cela ressemblait à de la bureaucratie. Cela impliquait de maintenir un bundle CA, d’écrire du code de distribution pour les endpoints, et de garder l’inventaire.
Personne n’aimait ça, mais c’était prévisible.

Un jour, la clé d’un intermédiaire a été suspectée d’exposition à cause d’un processus de sauvegarde mal configuré. Pas de compromission confirmée, mais assez de fumée pour agir.
Ils ont révoqué l’intermédiaire, promu l’intermédiaire « next » en « current », et ré-émis les certificats serveurs et clients selon un calendrier serré.

L’activité a à peine remarqué. L’accès VPN a continué parce que les clients faisaient déjà confiance au nouvel intermédiaire, et les certificats leaf étaient de toute façon à durée courte.
La pratique trimestrielle « ennuyeuse » a transformé une situation effrayante en un événement de maintenance contrôlé. Voilà à quoi ressemble une bonne opération : silencieuse.

Blague #2 : La PKI est le seul endroit où « faites-moi confiance » est mis en œuvre comme un fichier que vous devez distribuer à chaque appareil sur Terre.

Listes de contrôle / plan étape par étape

Plan étape par étape : construire une PKI VPN qui ne vous détestera pas

1. Définissez le périmètre.
   Décidez si les certificats identifient les utilisateurs, les appareils, ou les deux. Écrivez-le. Si vous ne pouvez pas l’expliquer en deux phrases, vous inscrirez de la confusion dans les certificats.
2. Créez une CA racine hors ligne.
   Générez une clé racine sur une machine sécurisée. Gardez-la hors ligne. Utilisez-la uniquement pour émettre des intermédiaires. Stockez les sauvegardes en sécurité avec contrôles d’accès.
3. Créez un intermédiaire CA en ligne pour l’émission VPN.
   Utilisez-le pour signer les certificats leaf serveurs et clients. Mettez pathlen:0 pour empêcher la prolifération accidentelle d’intermédiaires.
4. Standardisez votre nommage.
   Choisissez un nom DNS canonique pour le point d’accès VPN. Mettez-le dans le SAN. Arrêtez de laisser les gens se connecter à des noms d’hôtes et IP aléatoires.
5. Fixez les durées volontairement.
   Racine : longue (années). Intermédiaire : moyenne (1–3 ans). Leaf serveur : plus courte (mois). Leaf client : courte (jours à quelques mois).
6. Automatisez l’émission et le renouvellement.
   L’émission manuelle est OK pour un labo. En production, cela devient une file d’attente. Intégrez avec votre gestion des appareils ou portail d’enrôlement.
7. Décidez d’une stratégie de révocation.
   Si vous pouvez maintenir des CRL fraîches et appliquées, faites-le. Sinon, reposez-vous sur des certificats à courte durée et acceptez que la révocation soit limitée.
8. Instrumentez la surveillance des expirations.
   Alertes pour : expiration des leaf serveurs, expiration des intermédiaires, nextUpdate des CRL. N’alertez pas à 180 jours restants ; alertez sur des fenêtres actionnables.
9. Testez le véritable bord.
   Validez ce que le point d’accès public sert réellement (LB, ingress). Faites-en une porte de sortie de déploiement.
10. Entraînez la rotation.
    Planifiez des rotations de certificats de routine. Si la rotation n’arrive qu’en urgence, ce sera toujours une urgence.
11. Journalisez les émissions et les enrôlements.
    Conservez une piste d’audit : qui a demandé un certificat, quelle identité il représente, quand il a été émis, quand il a été révoqué ou expiré.
12. Documentez la procédure « break glass ».
    Qui peut signer un nouvel intermédiaire, où vit la racine, comment distribuer de nouveaux bundles de confiance, et ce dont les clients ont besoin pour se réenrôler.

Checklist de déploiement : renouveler le certificat serveur VPN sans interruption

• Confirmer le certificat servi actuellement depuis l’extérieur du réseau (LB vs backend).
• Émettre un nouveau certificat leaf serveur avec les SAN et EKU corrects.
• Déployer la chaîne complète (leaf + intermédiaire) là où le TLS est terminé.
• Recharger/redémarrer le service en toute sécurité ; confirmer que le nouveau certificat est servi.
• Exécuter des vérifications de poignée de main depuis au moins deux réseaux (corp + externe).
• Surveiller le taux de réussite des connexions et les logs d’erreurs pendant 30–60 minutes.

Checklist de désenrôlement : retirer l’accès VPN lorsqu’un collaborateur part

• Désactiver l’authentification utilisateur (SSO) si utilisée.
• Révoquer le certificat client (si la révocation est appliquée) et publier la CRL mise à jour.
• Si la révocation n’est pas fiable, assurez-vous que la durée du certificat client est courte et forcez le réenrôlement au prochain usage.
• Invalidation de la posture de l’appareil ou de l’enrôlement MDM si applicable.
• Audit : confirmez que l’identité ne peut plus établir de session VPN après les actions de désenrôlement.

FAQ

1) Dois-je utiliser un certificat CA public pour mon serveur VPN ?

Parfois. Si vous avez beaucoup de clients non gérés et que vous voulez qu’ils fassent confiance au serveur sans distribuer une racine privée, une CA publique peut aider pour le serveur.
Mais les certificats clients (mTLS) nécessitent toujours une émission privée et un cycle de vie, donc ne confondez pas « certificat serveur public » avec « PKI résolue ».

2) « Autosigné » est-ce la même chose qu’« CA privée » ?

Pas exactement. Une feuille autosignée est une impasse que vous épinglez manuellement. Une CA privée est un ancrage de confiance géré qui signe d’autres certificats et peut supporter la rotation et la politique.
Les gens utilisent « autosigné » pour dire « pas une CA publique », mais opérationnellement la différence est énorme.

3) Ai-je vraiment besoin d’une CA racine hors ligne ?

Si vous tenez au rayon d’impact, oui. Une racine hors ligne est une assurance peu coûteuse : vous la touchez rarement, et elle transforme une compromission d’intermédiaire d’apocalypse en migration.
Si vous êtes tout petit et entièrement managé, vous pouvez commencer sans — mais ne prétendez pas que c’est l’architecture finale.

4) Quelle durée pour les certificats clients ?

Assez courte pour que les clés volées expirent vite, assez longue pour que votre pipeline d’enrôlement ne fonde pas. Beaucoup d’équipes se situent entre 7 et 90 jours.
Si vous pouvez renouveler automatiquement via la gestion des appareils, vous pouvez aller plus court.

5) Si j’utilise des certificats à courte durée, puis-je sauter la révocation ?

Vous pouvez, mais assumez le compromis. Des durées courtes réduisent la valeur de la révocation mais ne l’éliminent pas — surtout pour les rôles à haut risque.
Si vous sautez la révocation, raccourcissez les durées et ayez un chemin pour forcer le réenrôlement quand nécessaire.

6) Pourquoi certains clients échouent après une rotation de CA alors que d’autres fonctionnent ?

Parce que la distribution de confiance est inégale. Certains appareils ont reçu le nouveau bundle CA ; d’autres non. Ou ils ont mis en cache une ancienne chaîne.
C’est pourquoi vous devez versionner les bundles CA, suivre l’état d’enrôlement et déployer les ancres de confiance avant de changer l’émission.

7) Quelle est la cause la plus courante de « hostname mismatch » ?

Entrées SAN manquantes. La validation TLS moderne utilise le SAN ; le CN n’est pas fiable.
Corrigez vos modèles d’émission et standardisez le nom DNS du point d’accès VPN.

8) Puis-je stocker les clés clients VPN dans le profil utilisateur sur les portables ?

Vous pouvez, mais c’est moins sûr que le stockage matériel. Si la clé privée peut être copiée, elle peut être réutilisée ailleurs.
Préférez les keychains OS, les clés protégées par TPM, ou les certificats gérés par les appareils quand c’est possible.

9) Pourquoi activer la vérification CRL a-t-il causé une panne ?

Généralement parce que la CRL a expiré ou est devenue inaccessible et que votre serveur/client échoue en mode fermé. Ce n’est pas une raison pour désactiver la révocation ;
c’est une raison d’automatiser la publication de la CRL, surveiller nextUpdate, et tester le comportement de recharge.

10) Ai-je besoin d’OCSP pour les VPN ?

Pas toujours. Les CRL sont souvent plus simples opérationnellement dans de nombreux environnements privés. OCSP ajoute des composants mobiles et des dépendances de disponibilité.
Si vous ne pouvez pas garantir une haute disponibilité OCSP, cela peut devenir une auto-infligée déni de service.

Conclusion : prochaines étapes réalisables cette semaine

Bien gérer les certificats VPN ne consiste pas à acheter un produit ou à mémoriser des flags OpenSSL. Il s’agit de choisir un modèle de confiance que vous pouvez exploiter sous stress,
puis de bâtir un cycle de vie autour : émission, rotation, révocation (ou durées courtes), et vérification au véritable bord.

Prochaines étapes pratiques :

1. Exécutez la commande d’inventaire des expirations sur vos serveurs VPN et notez ce qui expire dans les 60 prochains jours.
2. Depuis l’extérieur de votre réseau, confirmez quel certificat votre point d’accès public sert réellement.
3. Décidez d’une racine hors ligne + intermédiaire en ligne, et planifiez la migration si vous n’en êtes pas encore là.
4. Fixez les durées des certificats clients à quelque chose que vous pouvez faire tourner sans héroïsme, puis automatisez le renouvellement.
5. Choisissez une approche de révocation et testez-la en heures ouvrables, pas pendant un incident.
6. Transformez la « Procédure de diagnostic rapide » en une page de runbook et faites en sorte que l’on-call la suive avant de changer quoi que ce soit.

Si vous faites ces choses, le « problème de certificat VPN » cesse d’être un genre récurrent d’incident et devient une maintenance de routine. C’est tout l’intérêt.