Généralement, lorsqu’elles lancent de nouvelles fonctionnalités, les fournisseurs IT commencent par être indulgents afin d'en encourager l'utilisation. Ce fut le cas par exemple de la biométrie faciale : les premiers paramètres avaient été choisis de façon à faciliter son fonctionnement. Certes, les imposteurs avaient plus de facilité pour tromper le système, mais cette même facilité incitait fortement les utilisateurs légitimes à s’emparer de la fonctionnalité. Google et de nombreuses autorités de certification ont fait de même avec les certificats de serveur web, en tolérant leur utilisation pour toutes sortes de fonctions d'authentification au lieu de la seule fonction de serveur web pour laquelle ils ont été conçus. En théorie, selon Google, cette tolérance n’aura plus cours à partir du 15 juin 2026. 

L'article en ligne expliquant ce changement est assez technique, mais il en ressort que Google essaye enfin de mettre un terme à l'utilisation parfois très négligente des certificats. Au début de l'année, plusieurs groupes ont débattu de la possibilité de raccourcir le délai d'expiration des certificats Web à six semaines, mesure qui a finalement été officialisée en avril. Cette décision portait sur la durée d'utilisation des certificats web. Désormais, Google se concentre sur les cas d’usage des certificats, ce pour quoi ils peuvent et ne peuvent pas être utilisés. Pour Timothy Hollebeek, responsable de la stratégie technologique de DigiCert, « c’est un tournant décisif dans la manière dont est régie la confiance numérique et elle a de sérieuses implications pour les entreprises, en particulier dans les services financiers ». 

Des certificats à usage unique

Après cette date, « les certificats mal configurés ou non conformes seront marqués, ce qui entraînera des pannes importantes pour les applications légitimes de cet EKU (Extended Key Usage ». Autrement dit, à partir du 15 juin 2026, Google Chrome cessera de reconnaître les certificats SSL serveur incluant un EKU « Client Authentication ». Seul l'EKU « Server Authentication » sera accepté. Pour les entreprises qui utilisent encore des certificats à usage multiple, il s'agit d'un signal d'alarme. Les institutions financières ne peuvent plus se fier aux certificats destinés aux navigateurs et aux serveurs web ». M. Hollebeek estime qu'il s'agit là d'une bonne décision, étant donné que « bon nombre de ces applications ne nécessitent aucune communication en dehors du réseau de l'entreprise et seront donc mieux protégées par une PKI interne, dans laquelle l’entreprise peut configurer les certificats comme elle l'entend ».

Erik Avakian, conseiller technique au sein de la société de conseil Info-Tech, partage cet avis. « Google fait ce qu'il faut », a-t-il acquiéssé. « C'est une bonne chose, car c’est un retour au concept du moindre privilège », selon lequel les certificats sont utilisés « uniquement dans le but prévu ». Il s'agit d'une confiance zéro « lorsque les certificats sont répartis de cette manière ». Selon M. Avakian, la plupart des utilisateurs font ce qui leur convient, à moins qu'on ne leur demande de faire autrement. « Contraindre les utilisateurs à améliorer la sécurité est utile », a-t-il ajouté. « Ils veulent que les choses se fassent rapidement et facilement. C'est une question de culture, de coûts et de facilité ». Selon M. Hollebeek, le changement se résume à l'utilisation de certificats différents pour l'authentification du serveur et l'authentification du client. « La séparation cryptographique entre les domaines est un principe de sécurité bien connu. Il ne faudrait utiliser des certificats PKI Web que si un navigateur est impliqué », a-t-il expliqué. Jason Soroko, un autre expert en certificats, est d'accord pour dire que le fait d'emprunter la méthode facile, plutôt que la bonne méthode, est à l'origine de ce problème. « Les certificats d'authentification des clients devraient provenir d'une autorité de certification privée », a estimé Jason Soroko, qui est membre de Sectigo. « Il était tout simplement plus commode de s’adresser à une autorité de certification pour obtenir l'authentification du client ».

Google délivre un message très clair

La déclaration de Google est rédigée dans un langage que la communauté de la certification devrait certainement comprendre : « Pour aligner toutes les hiérarchies PKI incluses dans le Chrome Root Store sur le principe de servir uniquement les cas d'utilisation d'authentification de serveur TLS, le programme Chrome Root éliminera progressivement les racines polyvalentes du Chrome Root Store. À partir du 15 juin 2026, le programme Chrome Root définira une contrainte SCTNotAfter sur les certificats d'autorité de certification racine inclus dans le Chrome Root Store pour toute hiérarchie PKI en violation des exigences ci-dessous », a écrit Google. « Pour réduire l'impact négatif sur l'écosystème, le Chrome Root Store peut temporairement continuer à inclure un certificat d'AC racine polyvalent dans le Chrome Root Store sans contrainte SCTNotAfter au cas par cas, mais uniquement si le propriétaire de l'AC correspondant a soumis une demande d'inclusion de racine à la BCCAD pour un certificat d'AC racine de remplacement avant le 15 juin 2026. »

Plus prosaïquement, si une entreprise a utilisé les certificats de manière légère, il lui reste moins d'un an pour faire le ménage.