Fin de clientAuth : pourquoi le mTLS avec des certificats publics touche à sa fin

Pendant longtemps, un certificat TLS de confiance publique pouvait remplir deux rôles à la fois : authentifier un serveur auprès des navigateurs et authentifier un client auprès d’un autre serveur. L’extension Extended Key Usage le permettait avec les usages serverAuth et clientAuth. Ce double rôle prend fin. La politique du Chrome Root Program exige des hiérarchies consacrées exclusivement à l’authentification des serveurs.

Les échéances

Selon la version 1.8 de la Chrome Root Program Policy, deux dates s’appliquent :

Depuis le 15 juin 2026, les autorités de certification intermédiaires nouvellement déclarées à la CCADB ne peuvent plus déclarer que l’usage serverAuth.
À partir du 15 mars 2027, la même règle vaut pour chaque certificat final émis.

Les autorités de certification anticipent. DigiCert, par exemple, émet par défaut ses certificats TLS publics sans clientAuth depuis le 1er octobre 2025 et, selon sa propre annonce, supprimera totalement cette option le 1er mars 2027. Qui se fie à l’échéance de Chrome risque donc de découvrir le changement dès le prochain renouvellement.

Les certificats existants restent valides jusqu’à leur expiration. Mais comme la durée de validité maximale est de 200 jours depuis le 15 mars 2026, la transition est courte : un certificat encore émis avec clientAuth le dernier jour autorisé expire au plus tard fin septembre 2027. Au-delà, plus aucun certificat final valide issu d’une hiérarchie reconnue par Chrome ne porte cet usage.

Là où ça casse

Les navigateurs sont à peine concernés, puisqu’ils vérifient des serveurs. Sont touchées les connexions dans lesquelles un système se présente comme client avec un certificat public :

Interfaces partenaires : connexions B2B où les deux parties s’authentifient par mTLS et où le certificat client provient d’une AC publique.
Trafic de serveur à serveur : services qui utilisent leur propre certificat serveur comme identité cliente auprès d’autres services.
Équipements et agents : terminaux qui se présentent à un service central avec des certificats émis publiquement.

Le piège tient au calendrier. L’erreur n’apparaît pas à la date butoir, mais au premier renouvellement qui suit, souvent automatisé et souvent la nuit. Le nouveau certificat est valide, et pourtant la négociation TLS échoue, parce que l’autre partie exige l’usage clientAuth.

Les identités clientes relèvent d’une PKI propre

Chrome ne supprime pas le mTLS. La politique se contente de séparer les usages : les AC publiques authentifient les serveurs auprès du public, tandis que les identités clientes sont émises dans une relation de confiance que les parties contrôlent elles-mêmes. C’est d’ailleurs plus sain sur le plan de la sécurité. Faire confiance à une AC publique comme émetteur de certificats clients revient potentiellement à accepter n’importe quel certificat de cette AC, et pas seulement ceux de son partenaire.

Quatre étapes ont fait leurs preuves pour la transition. D’abord l’inventaire : quels certificats portent aujourd’hui clientAuth, et lesquels sont réellement utilisés comme clients ? Le certificat seul ne le dit pas ; seul le rapprochement avec les connexions le révèle. Ensuite, une autorité de certification dédiée aux usages clients, séparée de tout ce qui authentifie des serveurs. Puis la coordination avec les partenaires, car chaque contrepartie doit installer la nouvelle ancre de confiance, ce qui demande du temps. Enfin, l’automatisation de l’émission et du renouvellement, pour que la PKI interne ne devienne pas une nouvelle charge manuelle.

NextPKI suit précisément ce schéma : rendre d’abord l’inventaire visible, puis automatiser le renouvellement, indépendamment de l’AC émettrice. L’étape décisive précède toutefois tout outil : identifier les connexions qui dépendent aujourd’hui, sans que personne le sache, de clientAuth.

Le 15 mars 2027 n’est pas le jour où le mTLS casse. C’est le jour à partir duquel chaque renouvellement peut le casser.