Zero-Trust Network Access : l'histoire des certificats que votre projet de remplacement VPN a oubliée

L'architecture ZTNA standard que vous avez déjà dessinée

Ouvrez n'importe quel plan de déploiement Zero-Trust Network Access de 2026 et le schéma est presque identique. Les terminaux parlent à un proxy d'identité. Le proxy — Zscaler ZPA, Cloudflare Access, Netskope Private Access, Tailscale, Twingate ou un Envoy maison avec OPA — termine la connexion à la périphérie d'un réseau privé, fait appel à un fournisseur d'identité (Okta, Entra ID, Ping, Auth0) pour authentifier l'utilisateur, interroge un moteur de posture (CrowdStrike, SentinelOne, Jamf, Intune) pour évaluer l'équipement, et transmet la session à une application interne uniquement si les deux contrôles passent.

Le diagramme se referme par un point de décision de politique à grain fin mettant en œuvre le modèle d'autorisation par requête que le NIST SP 800-207 appelle un Policy Decision Point (PDP) alimentant un Policy Enforcement Point (PEP).

C'est l'architecture héritée des publications BeyondCorp de Google (à partir de 2014) et codifiée dans le NIST SP 800-207 (août 2020). Sa prémisse est juste : le réseau n'est plus une frontière de confiance ; chaque connexion doit être authentifiée, autorisée et inspectée. Sa prémisse est aussi incomplète.

L'écrasante majorité des conversations sur les certificats Zero-Trust Network Access dans les projets de remplacement VPN en cours réduit l'identité au claim OIDC de l'utilisateur depuis l'IdP. L'équipement est réduit à un score de posture : chiffrement au repos activé, EDR opérationnel, version d'OS à jour. La session elle-même, une fois autorisée, est protégée par un TLS côté serveur exactement comme un reverse-proxy de 2010 la protégeait. Rien dans cette image ne lie la session cryptographique au matériel spécifique qui l'a initiée.

Le résultat est un déploiement ZTNA opérationnellement élégant et cryptographiquement mince. Un refresh token volé, un cookie de session exfiltré par un infostealer ou un code grant OIDC phishé donnent à l'attaquant le même accès que l'équipement légitime, parce que le broker n'a aucune preuve cryptographique que le client TLS au bout du tunnel est le portable qu'il a enrôlé. Le proxy d'identité applique l'identité utilisateur. Il applique rarement l'identité d'équipement dans un sens cryptographiquement significatif.

Où les certificats ont leur place (et pourquoi ils manquent généralement)

Une PKI ZTNA sérieuse a des certificats à quatre couches distinctes, et chaque couche répond à une question différente. Au moment de l'enrôlement de l'équipement, un certificat signé par une CA privée prouve que le terminal est un équipement géré par la flotte, et non un hôte arbitraire avec des identifiants Okta valides. Le sujet du certificat (ou, plus utilement, son extension subjectAltName portant un SAN URI tel que urn:device:fleet:laptop-7a2c ou un otherName avec attestation matérielle) est l'ID d'équipement durable et cryptographiquement vérifiable. Consultez le primer sur les certificats numériques pour les champs X.509 qui importent ici.

Au moment de l'établissement de session, l'équipement s'authentifie auprès du broker ZTNA via mutual TLS (mTLS). Le client envoie un message Certificate dans le handshake TLS 1.3 (RFC 8446, section 4.4.2), le broker valide la chaîne face à la racine privée, vérifie la révocation, et lie la session OIDC de l'utilisateur à l'empreinte du certificat d'équipement via le matériel exportateur défini dans la RFC 5705. Le handshake produit une session cryptographiquement liée à une clé privée spécifique qui, idéalement, ne quitte jamais la racine de confiance matérielle de l'équipement.

À la couche service-à-service derrière le broker, des certificats d'identité workload — SVID SPIFFE tels que définis dans les spécifications SPIFFE/SPIRE, ou X.509 à courte durée de vie émis par Istio, Linkerd ou un plan de contrôle de service mesh — portent un SAN URI spiffe:// identifiant le workload. Le même mécanisme de handshake TLS qui authentifie un portable auprès du broker authentifie le Pod A auprès du Pod B au sein d'un cluster Kubernetes. Les deux dérivent d'une chaîne que vous contrôlez.

Le guide des certificats d'authentification client couvre l'OID Extended Key Usage id-kp-clientAuth (1.3.6.1.5.5.7.3.2) qui distingue un cert client d'un cert serveur dans ce flux.

À la couche API et signature de code, la même hiérarchie émet des certificats de signature pour les artefacts CI/CD, les payloads MDM mobiles et les profils de configuration. Quatre couches, une chaîne, une histoire de révocation.

Les déploiements ZTNA « cert-light » n'en implémentent généralement aucune. Le broker présente au terminal un cert serveur TLS d'une CA publique, le terminal présente au broker un jeton bearer OIDC, et l'architecture entière repose sur l'hypothèse que le jeton bearer ne peut être volé. C'est précisément l'hypothèse que les kits de phishing adversary-in-the-middle (Evilginx, Modlishka, Tycoon 2FA) et les infostealers (Lumma, RedLine, Rhadamanthys) ont passé cinq ans à invalider.

Identité d'équipement vs identité d'utilisateur — pourquoi vous avez besoin des deux

L'identité utilisateur et l'identité équipement sont orthogonales. Les confondre est l'erreur de conception ZTNA la plus conséquente, et c'est celle que presque tous les projets de remplacement VPN commettent à leur première itération.

L'identité utilisateur, faite correctement en 2026, est résistante au phishing. Cela signifie FIDO2/WebAuthn avec un identifiant discoverable lié à un authentificateur itinérant ou de plateforme. L'utilisateur prouve la possession d'une clé privée, générée à l'intérieur d'un TPM 2.0 (portables), d'une Secure Enclave Apple (Mac et iOS), d'une Android StrongBox ou d'un Titan M2 (Pixel et la plupart des Android modernes), ou d'une clé de sécurité itinérante (YubiKey 5, Feitian, Token2) implémentant CTAP2.

L'IdP reçoit une assertion signée en ES256 ou EdDSA sur l'origine de la relying party et un challenge fourni par le serveur. L'assertion est non-phishable parce que la clé privée ne quitte jamais l'authentificateur et la signature est liée à l'origine. C'est ce que le NIST SP 800-63B-4 appelle AAL3 avec résistance à l'imitation du vérificateur.

L'identité d'équipement est un problème différent, avec une solution différente. La question n'est pas qui est au clavier, c'est quel matériel génère ce handshake TLS. La réponse est l'attestation matérielle. Un équipement TPM 2.0 produit une clé d'attestation (AK) certifiée par le certificat Endorsement Key (EK) du fabricant. L'AK peut signer des quotes sur les Platform Configuration Registers (PCR) — PCR0 capture les mesures du firmware, PCR7 capture l'état du secure boot, PCR11 capture l'état de BitLocker sous Windows.

Un flux d'enrôlement d'équipement qui émet un certificat équipement longue durée sans lier la clé publique du certificat à une clé privée résidant dans le TPM, et sans vérifier une attestation au moment de l'enrôlement, émet un identifiant indiscernable d'un secret logiciel sur disque. Il sera exfiltré.

Les équipements Apple suivent le même schéma avec le Secure Enclave Processor (SEP), la Device Attestation API et le framework App Attest. Android utilise Keymaster et l'extension Key Attestation définie dans le CDD Android : une extension d'attestation dans le certificat X.509 porte le niveau de sécurité (TEE, StrongBox), l'état de Verified Boot (Verified, SelfSigned, Unverified, Failed) et le niveau de patch OS. Ces champs d'attestation entrent directement dans votre décision d'enrôlement. Si l'attestation indique verifiedBootState=Unverified, vous n'émettez pas de certificat de flotte ; vous redirigez vers la remédiation.

Le sujet est opérationnel, pas théorique. Un identifiant FIDO2 est lié à un utilisateur. Un certificat équipement attesté par TPM est lié à un matériel. Un attaquant qui phish l'utilisateur mais n'a pas volé le portable échoue au contrôle équipement. Un attaquant qui vole le portable mais ne peut pas solliciter l'authentificateur de l'utilisateur échoue au contrôle utilisateur. Les deux contrôles doivent réussir pour que le broker ZTNA transmette la session.

C'est la définition opérationnelle du Zero-Trust, et c'est le modèle que BeyondCorp décrivait depuis le début — l'accès dépend de l'utilisateur et de l'équipement, deux assertions indépendantes, toutes deux adossées à des clés enracinées dans le matériel.

Les quatre anti-patterns du ZTNA cert-light

Les équipes en milieu de projet convergent vers les quatre mêmes modes de défaillance. Ils sont assez prévisibles pour être énumérés, assez fréquents pour justifier une checklist et assez nuisibles pour saper les gains de sécurité que la migration ZTNA était censée apporter.

Anti-pattern un : certificats uniquement au périmètre, pas en interne. Le broker ZTNA présente un certificat serveur TLS d'une CA publique en bordure. Derrière le broker, le trafic circule en HTTP, ou en TLS avec des certificats auto-signés qu'aucun client ne valide, ou sur un tunnel IPsec établi au déploiement et jamais renouvelé. L'histoire du mouvement latéral est inchangée par rapport à l'ère VPN : une fois passé le broker, le réseau se comporte comme une zone plate de confiance.

Une architecture ZTNA sérieuse a du mTLS partout — broker vers backend, backend vers backend, backend vers base de données — avec des certificats workload renouvelés sur une cadence de 15 minutes à 24 heures et validés face au même ancrage de confiance interne.

Anti-pattern deux : certificats équipement auto-signés sans cycle de vie. Le MDM (Intune, Jamf, Workspace ONE, Kandji) génère un certificat équipement à l'enrôlement, le signe avec une CA auto-signée intégrée et le pousse dans le keystore. Le certificat ne tourne jamais. La clé privée de la CA est dans la base du MDM. Il n'y a pas de hiérarchie PKI, pas de racine offline, pas de HSM, pas de chemin de signature croisée vers quoi que ce soit que le broker puisse valider face à un véritable trust store.

Quand un équipement est décommissionné, le certificat est « supprimé » du MDM, mais aucune CRL n'est publiée et aucun répondeur OCSP ne l'a jamais connu. Un portable qui a été wipé et réinstallé conserve un certificat client valide aux yeux de tout ce qui n'interroge pas le MDM en direct. Ce n'est pas une PKI ; c'est un annuaire avec une décoration cryptographique.

Anti-pattern trois : certificats qui n'expirent pas. Pour éviter la douleur opérationnelle du renouvellement, les équipes émettent des certificats équipement avec des durées de validité de cinq, dix, voire vingt ans. La justification est toujours la même : nous ne voulons pas casser la flotte quand les certificats expirent. La conséquence est que la révocation devient le seul mécanisme pour retirer l'accès, et la révocation, en pratique, n'est pas en temps réel.

Les durées courtes (le CA/Browser Forum pousse le TLS public à 47 jours d'ici 2029) ne sont pas qu'une tendance de conformité. Ce sont le bon pattern opérationnel pour les certificats équipement aussi : des durées de 30 à 90 jours avec renouvellement automatique signifient qu'un équipement compromis perd son accès par attrition, pas par une révocation manuelle que personne ne fait réellement. Le guide de la gestion automatisée des certificats couvre les patterns de renouvellement qui rendent ceci opérationnellement faisable.

Anti-pattern quatre : certificats sans accessibilité à la révocation. La PKI publie des CRL et exploite OCSP, mais le broker ZTNA est configuré avec un soft-fail sur la vérification de révocation, ou le point de distribution CRL se trouve derrière le même réseau que le broker est censé contrôler. Un équipement compromis dont le certificat a été révoqué continue à s'authentifier parce que le broker ne peut pas atteindre l'infrastructure de révocation.

OCSP must-staple (RFC 7633) sur les certificats présentés par le broker, certificats à courte durée de vie comme substitut de CRL, ou OCSP stapling côté client sont les réponses opérationnelles. La vue d'ensemble du cycle de vie des certificats parcourt les exigences d'accessibilité à la révocation plus en détail.

Une architecture de référence avec ZTNA basé certificats

L'architecture de référence pour un déploiement ZTNA mTLS crédible compte six composants et trois hiérarchies de certificats. De gauche à droite : terminal géré, broker ZTNA (le PEP), moteur de politique (le PDP), mesh de workloads, applications internes, et plan PKI et gestion des clés sous l'ensemble.

Le terminal détient deux clés en matériel. La première est la clé d'authentificateur FIDO2 pour l'authentification utilisateur : assertion WebAuthn signée en ES256 sur l'origine de la relying party, envoyée à l'IdP, échangée contre un ID token et un access token OIDC.

La seconde est la clé privée d'identité équipement générée à l'intérieur du TPM 2.0 (Windows), de la Secure Enclave (Apple) ou de la StrongBox (Android). La clé publique correspondante a été attestée à l'enrôlement via un TPM quote ou une attestation de plateforme, et une CA privée a émis un certificat client X.509 portant l'identifiant de flotte de l'équipement dans un SAN URI, l'EKU réglée à id-kp-clientAuth et une validité de 60 jours. Le client TLS du terminal utilise ce certificat pour le handshake mTLS vers le broker.

Le broker ZTNA termine la connexion mTLS entrante. Il valide la chaîne de certificat client face à une racine privée qui réside dans un HSM, vérifie la révocation via OCSP stapling ou sémantique de certificat à courte durée, extrait l'identifiant d'équipement du SAN et interroge le moteur de politique.

Le moteur de politique combine l'identifiant d'équipement avec l'identité utilisateur (depuis le token OIDC), la posture de l'équipement (depuis l'intégration EDR ou MDM), la ressource demandée, l'heure de la journée, la géographie source et un score de risque. Si la décision est « autoriser », le broker établit une connexion mTLS sortante vers le service backend en utilisant son propre certificat client broker-identity.

Le mesh de workloads derrière le broker fait tourner SPIFFE / SPIRE ou un équivalent. Chaque workload — pod, conteneur, fonction serverless — reçoit un SVID X.509 à courte durée portant un SAN URI spiffe://corp.example/ns/payments/sa/api, valide une heure, renouvelé automatiquement. Les appels pod à pod, fonction à base de données et service à service se font tous en mTLS en utilisant ces SVID. La CA interne qui signe les SVID se chaîne à la même racine privée qui signe les certs broker et les certs équipement — une racine de confiance, trois intermédiaires d'émission.

Le plan PKI et gestion des clés est en dessous. La racine offline est dans un HSM air-gapped. Trois CA d'émission online — device-identity, broker-identity, workload-identity — résident dans des HSM réseau ou KMS cloud (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM avec FIPS 140-3 niveau 3). L'enrôlement passe par SCEP pour les équipements gérés par MDM hérités et par ACME (RFC 8555) avec extensions d'attestation d'équipement pour les terminaux modernes. Le renouvellement est automatisé. La révocation est publiée via CRL et OCSP, avec stapling côté broker pour garantir la disponibilité.

Parcourez le handshake TLS 1.3 étape par étape pour voir comment tout cela se compose. Le terminal envoie un ClientHello incluant SNI pour le FQDN du broker, les suites de chiffrement supportées (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) et les algorithmes de signature dont ECDSA-SECP256R1-SHA256 et Ed25519.

Le broker répond avec un ServerHello, son propre certificat serveur chaîné à une CA publique, et une extension CertificateRequest spécifiant les Distinguished Names des CA acceptables — la CA privée device-identity. La stack TLS du terminal sélectionne le certificat équipement résidant dans le TPM correspondant à la liste de CA du broker. Le TPM effectue l'opération de signature pour CertificateVerify (la clé privée ne quitte jamais le matériel), et le broker valide la chaîne face à la racine privée dans son trust store adossé au HSM, vérifie l'OCSP stapled sur le certificat équipement et extrait l'identifiant d'équipement depuis le SAN URI.

Le broker interroge ensuite le moteur de politique avec le tuple (device_id, user_oidc_sub, resource, posture). Sur « autoriser », le broker lie l'access token OIDC à la session mTLS via le matériel exportateur RFC 5705 ou DPoP (RFC 9449), de sorte qu'un bearer token volé est inutilisable en dehors de cette session.

Le broker établit son mTLS sortant vers le backend en utilisant son certificat broker-identity, et le mesh de workloads continue le mTLS de hop en hop en aval.

Migrer du VPN vers ZTNA sans casser la confiance

Le chemin de migration réaliste n'est pas un flag day. C'est un déploiement dual-stack phasé sur 6 à 18 mois. La variable qui détermine la durée n'est pas le produit ZTNA ; c'est le substrat d'enrôlement de certificats et l'hétérogénéité du parc d'équipements. Un parc bien géré de 5 000 terminaux tous sous Windows 11 ou macOS 14, tous enrôlés dans Intune ou Jamf, peut être fait en un trimestre. Un parc de 50 000 équipements incluant BYOD, prestataires, serveurs Linux de dix ans, tablettes industrielles et trois MDM est un programme de 18 mois.

Le phasage tient en gros en quatre phases. Phase un (mois 0 à 2) : fondations PKI. Mettez debout la racine privée dans un HSM. Émettez des intermédiaires pour l'identité équipement, broker et workload. Définissez les profils de certificats avec des champs concrets — DN sujet, types de SAN, EKU, key usage, validité, cadence de renouvellement. Câblez l'infrastructure CRL et OCSP avec des points de distribution joignables sur Internet public. Sans cette couche, aucune autre phase ne réussit.

Phase deux (mois 2 à 5) : substrat d'enrôlement. Choisissez entre SCEP et ACME, ou faites tourner les deux. SCEP est le chemin de moindre résistance pour l'intégration MDM : chaque MDM majeur (Intune, Jamf, Workspace ONE, Kandji) parle SCEP, les certificats peuvent être poussés dans des keystores adossés au TPM via des payloads MDM, et le déploiement ne nécessite aucun changement côté terminal.

La faiblesse de SCEP est sa posture de sécurité — le challenge password statique est un secret partagé, et le protocole précède l'attestation moderne. Les déploiements modernes utilisent SCEP avec des challenges dynamiques émis par équipement par le MDM.

ACME, conçu à l'origine pour Let's Encrypt, est devenu le protocole moderne pour l'enrôlement de certificats sur terminaux grâce aux extensions d'attestation d'équipement (le type de challenge device-attest-01 et équivalents) qui permettent à la CA de vérifier l'équipement demandeur face à Apple Device Attestation, Android Key Attestation ou aux TPM quotes. ACME est le bon choix pour les nouveaux parcs ; SCEP est le bon choix pour les parcs que vous ne pouvez pas reconstruire.

Phase trois (mois 4 à 12) : déploiement de la flotte par cohortes. Déployez le certificat équipement à 5 %, puis 25 %, puis 100 % du parc, par cohorte (ingénierie en premier, ventes ensuite, prestataires en dernier, dirigeants quand ils le tolèrent). Faites tourner le broker ZTNA en double mode : accepter les tunnels VPN hérités pour les équipements non migrés, accepter le mTLS pour les équipements migrés, journaliser lequel est lequel.

Mesurez les modes de défaillance : certificats qui échouent à s'installer parce que le TPM est absent ou désactivé, équipements qui échouent à l'attestation à cause de l'état du secure boot, versions d'OS qui n'ont pas de client ACME. Chaque mode de défaillance produit un ticket de remédiation ou un changement de politique de gestion de flotte.

Phase quatre (mois 10 à 18) : décommissionnement VPN et identité workload. Mettez les concentrateurs VPN hors ligne. Déplacez le trafic est-ouest interne vers le mesh de workloads avec des SVID SPIFFE. Retirez les tunnels IPsec entre datacenters et remplacez-les par du mTLS médié par broker.

Le déploiement de l'identité workload est là où ZTNA cesse d'être un projet réseau et devient un projet d'ingénierie de plateforme — service meshes, proxies sidecar, intégration CA de mesh. De nombreuses organisations s'arrêtent à la phase trois et ne finissent jamais la quatre ; l'histoire au bord du broker est complète et l'histoire du mouvement latéral est à moitié construite. Le sujet de le faire correctement est que l'histoire du mouvement latéral est là où se produisent la plupart des compromissions réelles.

Une dimension fréquemment négligée : la même hiérarchie de certificats qui authentifie les portables doit aussi authentifier la longue queue d'équipements IoT et embarqués derrière le broker ZTNA. Imprimantes, caméras IP, lecteurs de badges, automates industriels (PLC), équipements médicaux et matériel de salle de conférence ont tous besoin d'une identité équipement pour atteindre les services internes.

Ils ne peuvent pas faire tourner FIDO2 et ne peuvent pas installer un agent MDM. Ils peuvent détenir un certificat X.509 provisionné à la fabrication ou enrôlé via 802.1X / EAP-TLS. L'architecture ZTNA doit les accommoder ou elle devient une architecture qui protège 80 % des actifs et laisse les 20 % restants sur le VLAN de confiance qu'elle était censée éliminer.

Le rôle d'Evertrust

Un projet ZTNA qui ignore les certificats est un projet d'identité utilisateur vendu comme une architecture réseau. L'histoire de l'identité utilisateur est, en 2026, largement résolue — FIDO2, OIDC, IdP, moteurs de posture, proxies d'identité sont des composants banalisés et les patterns d'intégration sont bien compris.

La partie difficile — celle qui détermine si le déploiement apporte un véritable Zero-Trust ou simplement un VPN plus élégant — est le plan certificat : la CA privée, le substrat d'enrôlement, la politique d'attestation, l'automatisation du renouvellement, l'accessibilité à la révocation, le mesh d'identité workload et l'inventaire unifié sur les quatre couches de certificats.

C'est la surface pour laquelle la plateforme d'Evertrust est construite. La hiérarchie de CA est la vôtre, hébergée dans vos HSM et intégrée à vos KMS cloud. L'enrôlement passe par SCEP et ACME avec attestation d'équipement. Le cycle de vie est automatisé : les certs équipement à 60 jours se renouvellent sans intervention humaine, les SVID workload à 1 heure tournent en continu, la révocation publie sur des points de distribution OCSP et CRL que le broker ZTNA peut effectivement atteindre.

L'inventaire consolide les certificats équipement, broker, workload et signature en une source unique de vérité, de sorte que le schéma d'architecture et la réalité opérationnelle restent alignés 18 mois après le décommissionnement du VPN. Pour voir comment le plan certificat se branche dans un déploiement ZTNA mTLS, explorez Evertrust Certificate Lifecycle Management.