La crise d’identité client-serveur : pourquoi ne pas utiliser un certificat unique pour les deux rôles

Dans la PKI et TLS, les certificats sont des justificatifs numériques prouvant une identité. Lorsqu’un certificat unique prétend assumer deux rôles distincts et hautement fiables, comme lors de la combinaison des usages étendus de clé (EKU) serverAuth et clientAuth, les frontières de sécurité deviennent floues.

Bien que cette pratique soit techniquement possible et parfois pratique, elle constitue un antipattern de sécurité. Voici pourquoi elle présente des risques et comment concevoir une stratégie de certificats plus sûre.

Le certificat tout-en-un : un raccourci tentant

Un usage étendu de clé (EKU) est une extension X.509 définissant la finalité d’un certificat. Les deux EKU les plus courants pour TLS sont :

• serverAuth (OID: 1.3.6.1.5.5.7.3.1) : autorise le certificat à authentifier un serveur (par exemple, un site HTTPS).
• clientAuth (OID: 1.3.6.1.5.5.7.3.2) : autorise le certificat à authentifier un client (par exemple, un client API, un utilisateur ou un service).

Il est possible de créer un certificat avec les deux EKU, notamment dans les environnements de développement ou les systèmes historiques :

openssl req -new -key device.key -out device.csr -addext "extendedKeyUsage = serverAuth, clientAuth"

La simplicité est séduisante : un seul certificat à gérer au lieu de deux. Mais cette commodité a un coût pour la sécurité.

Problème central : violation du principe du moindre privilège

Le principe du moindre privilège (PoLP) veut que chaque entité (utilisateur, système ou certificat) ne reçoive que les autorisations nécessaires à sa fonction prévue.

Un certificat doté des EKU serverAuth et clientAuth est intrinsèquement trop privilégié :

• Un serveur écoute et répond aux requêtes ; il ne devrait pas pouvoir initier des requêtes comme client authentifié.
• Un client initie des requêtes vers des serveurs de confiance ; il ne devrait pas pouvoir usurper l’identité d’un serveur.

Si un attaquant compromet un certificat serveur possédant aussi l’EKU clientAuth, il peut le réutiliser pour s’authentifier auprès d’autres services internes faisant confiance aux certificats clients et potentiellement se déplacer latéralement dans le réseau.

Analogie : la clé maîtresse d’un coffre bancaire (serveur) ne devrait pas ouvrir également tous les coffres de dépôt (client) qu’il contient.

Problèmes techniques et opérationnels

1. Usage de clé inadapté : les certificats serveur et client ont souvent des extensions keyUsage différentes. Un serveur peut nécessiter keyEncipherment (par exemple pour l’échange de clés RSA), tandis qu’un client peut n’avoir besoin que de digitalSignature. Un certificat combiné peut recevoir des usages trop permissifs.

2. Gestion du cycle de vie complexe : si un développeur quitte l’organisation et que le certificat doit être renouvelé, alors qu’il est aussi utilisé par un serveur critique, le renouvellement devient une opération complexe et risquée.

3. Difficultés d’audit et de conformité : un certificat unique pour plusieurs rôles complique l’identification de sa finalité, la revue des accès et la limitation de l’impact d’une compromission.

La bonne approche : des certificats dédiés à chaque rôle

La pratique recommandée consiste à utiliser des certificats séparés, conçus pour chaque rôle.

Certificat serveur

Un certificat serveur doit uniquement inclure l’EKU d’authentification serveur et les usages de clé adaptés au service :

openssl req -new -key server.key -out server.csr -subj "/CN=api.mycompany.com/O=MyOrg/OU=Server" -addext "extendedKeyUsage = serverAuth" -addext "keyUsage = digitalSignature, keyEncipherment"

Certificat client

Un certificat client doit inclure l’EKU d’authentification client et les usages de clé correspondants :

openssl req -new -key client.key -out client.csr -subj "/CN=backend-service-account/O=MyOrg/OU=Client" -addext "extendedKeyUsage = clientAuth" -addext "keyUsage = digitalSignature"

Avantages de cette approche

• Impact d’une compromission limité : un certificat serveur compromis ne peut pas être réutilisé pour s’authentifier en tant que client.
• Contrôle granulaire : révocation et renouvellement des certificats client et serveur indépendants.
• Audit clair : la finalité de chaque certificat est explicite.
• Conformité facilitée : approche alignée sur les référentiels de sécurité modernes.

Peut-on parfois les combiner ?

Les exceptions sont extrêmement rares et doivent être solidement justifiées.

• Appareils embarqués aux ressources très limitées : dans certains scénarios IoT où un appareil ne peut réellement stocker qu’un certificat, la combinaison peut être inévitable. Il faut alors évaluer soigneusement les risques et les atténuer autrement.
• Proxys de maillage de services interne : certaines architectures spécialisées (comme Istio) utilisent des certificats pour le mTLS entre proxys. Dans ces environnements contrôlés, le plan de contrôle du maillage peut gérer les deux rôles ; cette configuration n’est pas laissée aux propriétaires des applications.

Pour 99 % des cas — applications Web, API, microservices et comptes de service compris — les certificats séparés sont la bonne approche.

Conclusion : la spécialisation est une qualité

En sécurité, la spécialisation est une force. On n’utilise pas un certificat d’AC racine pour signer les courriels quotidiens ; de même, un certificat unique ne devrait pas représenter plusieurs identités machine distinctes.

Des certificats dédiés à l’authentification serveur et client permettent de bâtir des systèmes plus résilients, faciles à gérer et sécurisés. Ils éliminent les risques inutiles et respectent les principes fondamentaux de cybersécurité. PKI Trust Manager aide à appliquer les politiques et éviter les mauvaises pratiques grâce à une gestion rigoureuse des certificats.