Qu’est-ce qui change et à quelle date?

Dans notre article L’authentification client dans les certificats TLS/SSL ne sera plus prise en charge à partir de 2027, nous avons expliqué les changements introduits par le Google Chrome Root Program et leurs conséquences pour les certificats TLS publics de SwissSign..

En bref, les certificats TLS publiquement reconnus n’auront plus qu’une seule finalité: l’authentification serveur. Les nouveaux certificats d’autorité de certification intermédiaire publiés dans la CCADB depuis le 15 juin 2026 ne peuvent contenir que l’Extended Key Usage (EKU) id-kp-serverAuth. À partir du 15 mars 2027, les nouveaux certificats TLS publics destinés aux utilisateurs finaux devront eux aussi contenir exclusivement id-kp-serverAuth et ne pourront plus inclure id-kp-clientAuth.

SwissSign adapte en conséquence les profils de ses certificats TLS publics. De nouveaux profils contenant uniquement l’authentification serveur sont disponibles depuis fin septembre 2026. Les profils actuels contenant à la fois serverAuth et clientAuth devraient être remplacés d’ici fin janvier 2027.

L’authentification serveur HTTPS n’est pas concernée. Cet article se concentre sur les cas d’utilisation de l’authentification mutuelle touchés par ce changement ainsi que sur leur migration vers une PKI privée.

Pourquoi séparer l’authentification serveur de l’authentification client?

Lors de l’émission d’un certificat public, un élément est vérifié: le contrôle d’un nom de domaine et, pour les certificats OV et EV, l’identité de l’organisation qui en est titulaire. En revanche, cette vérification ne détermine jamais si une machine ou une personne est autorisée à accéder à votre VPN, à votre passerelle API ou à vos services internes. Un certificat couvrant les deux finalités est en outre deux fois plus précieux pour une personne malveillante qui obtient la clé privée: la même clé lui permet de se faire passer pour votre serveur et de s’authentifier comme client. L’utilisation de certificats distincts pour l’authentification serveur et client limite les conséquences d’identifiants compromis et renforce la gestion des risques sur l’ensemble du cycle de vie des certificats.

Quels systèmes sont concernés?

Le changement concerne principalement les environnements dans lesquels des certificats TLS publiquement reconnus sont utilisés pour l’authentification client. Exemples typiques:

• Passerelles VPN et accès à distance: authentification des utilisateurs dans les VPN IPsec/IKE, les VPN SSL et les accès à distance.

• Wi-Fi d’entreprise et contrôle d’accès au réseau (802.1X authentification des utilisateurs et des appareils avec EAP-TLS pour accéder aux réseaux d’entreprise.

• Passerelles API et intégrations B2B: authentification des applications et des utilisateurs d’API au moyen de mTLS.

• Communication de serveur à serveur: authentification mutuelle entre serveurs, applications et systèmes au moyen de mTLS.

• Authentification des appareils, de l’IoT et des communications de machine à machine: authentification des machines afin d’identifier et d’authentifier des appareils, des équipements et des systèmes automatisés.

Non concernés: si vos certificats TLS SwissSign sont utilisés exclusivement pour l’authentification serveur HTTPS, par exemple pour sécuriser des sites web publics ou des applications web, ce changement ne vous concerne pas. Les certificats TLS serveur existants et futurs continueront de fonctionner comme auparavant.

Les certificats existants continueront de fonctionner, mais plus pour longtemps

Les certificats émis avant la date butoir conservent leur EKU clientAuth et restent valides jusqu’à leur expiration, laissant un certain délai de transition. Dans le même temps, la durée de validité des certificats TLS publics diminue: elle est passée à 200 jours en mars 2026 et sera réduite à 47 jours d’ici 2029. Après le changement, chaque renouvellement remplacera un certificat à double usage par un certificat contenant uniquement serverAuth. Le risque est le suivant: une connexion qui fonctionnait depuis des années peut soudainement échouer après un renouvellement de routine. L’interruption se manifeste alors en production plutôt que dans le cadre d’un changement planifié.

La PKI privée comme alternative pour l’authentification mutuelle

Un certificat public est comparable à un passeport: il est délivré par une autorité largement reconnue. Un certificat privé ressemble davantage à un badge d’entreprise: il est émis dans un environnement clairement défini et reconnu comme fiable par les systèmes qui en font partie. Pour l’authentification mutuelle entre systèmes, ce modèle de confiance privé est souvent mieux adapté. L’organisation détermine elle-même quels systèmes reçoivent des certificats, combien de temps ceux-ci restent valides et quand ils sont révoqués.

Cas d’utilisation 1: mTLS dans Kubernetes

Les environnements Kubernetes peuvent exécuter un grand nombre de microservices qui communiquent entre eux. Avec mTLS, des certificats identifient ces services et leur permettent de s’authentifier mutuellement: chaque service présente un certificat que le service destinataire vérifie auprès d’une autorité de certification reconnue.

À mesure que le nombre de services augmente, le nombre de certificats à émettre, renouveler et remplacer augmente lui aussi. Une PKI privée fournit l’infrastructure de confiance privée nécessaire, tandis que le Certificate Lifecycle Management (CLM) automatise leur gestion à grande échelle.

Dans Kubernetes, des outils tels que cert-manager peuvent demander et renouveler des certificats pour chaque workload et s’intégrer à un émetteur de certificats externe. L’automatisation des certificats Kubernetes peut ainsi s’inscrire dans l’approche globale de l’organisation en matière de gestion des certificats.

Cas d’utilisation 2: authentification B2B

Dans le cadre d’intégrations B2B, les organisations peuvent utiliser mTLS pour authentifier les partenaires externes qui accèdent à leurs API ou à leurs services. Le serveur présente son certificat au partenaire, tandis que le partenaire présente un certificat client qui permet à l’organisation de l’identifier.

Avec une PKI privée, l’organisation peut délivrer directement ces certificats clients aux partenaires autorisés et configurer ses API ou ses passerelles afin qu’elles reconnaissent l’autorité de certification privée. Elle contrôle ainsi quels partenaires peuvent s’authentifier et peut gérer leurs certificats conformément à ses propres politiques de sécurité.

Mettre en œuvre l’authentification mutuelle avec SwissSign Private PKI

Avec SwissSign Private PKI, les organisations disposent d’une autorité de certification privée dédiée, associée au Certificate Lifecycle Management, à la gouvernance et au reporting. Les certificats publics et privés peuvent être gérés de manière centralisée tout au long de leur cycle de vie.

• Migration plus rapide: des modèles, des politiques et une gouvernance préconfigurés réduisent les efforts nécessaires à la mise en place et à l’exploitation d’une PKI privée.

• Cycle de vie automatisé des certificats: l’émission, le renouvellement et la distribution des certificats peuvent être automatisés dans l’ensemble de l’infrastructure.

• Gestion centralisée des certificats: les certificats publics et privés, y compris leur émission et leur révocation, peuvent être gérés depuis une plateforme unique.

• Contrôle renforcé: des politiques de certificats cohérentes, une gouvernance et un reporting définissent des exigences claires pour l’authentification client.

• Coûts prévisibles: CHF 2’025.– par an et CHF 31.80 par certificat et par an.

Une hiérarchie privée offre également un environnement contrôlé permettant de se préparer aux futures évolutions cryptographiques, notamment à l’introduction d’algorithmes post-quantiques.

Des exigences différentes s’appliquent à l’authentification des personnes. Selon le cas d’utilisation, des certificats S/MIME validés par un sponsor, à partir du niveau de validation Organization Validation (OV), peuvent constituer une alternative dans le cadre d’une Managed PKI.

Trois mesures à prendre dès maintenant

1. Dresser un inventaire: recherchez l’EKU clientAuth dans votre parc de certificats et identifiez chaque système qui présente un certificat en tant que client. Les dates de renouvellement ne suffisent pas à déterminer quels systèmes utilisent clientAuth.
2. Décider pour chaque cas d’utilisation: définissez l’alternative appropriée pour chaque scénario d’authentification client, par exemple une PKI privée pour les machines, les services et les appareils, ou des certificats S/MIME lorsqu’une authentification des utilisateurs est nécessaire.
3. Automatiser: avec des durées de validité plus courtes, le remplacement manuel n’est plus viable à grande échelle. Le Certificate Lifecycle Management automatise la découverte, le renouvellement et la distribution des certificats et permet ainsi de relever les deux défis à la fois.

Questions fréquentes