Suppression de l'EKU d'authentification client de TLS Certificats de serveur : ce que vous devez savoir

Marché

Depuis le 15 septembre 2025, SSL.com TLS Des certificats de serveur ont été émis sans l'extension d'utilisation étendue de la clé (EKU) pour l'authentification du client. Cette modification a été guidée par la Politique du programme racine de Google ChromeNous expliquons ici ce que sont les EKU, les raisons de ce changement, son impact sur les environnements serveur et les actions que vous pourriez devoir entreprendre. Vous trouverez également une FAQ et des conseils techniques pour différents scénarios.

Mettre à jour: La suppression de l'EKU clientAuth est une exigence du CA/Browser Forum, et non une modification propre à Chrome. Les principales autorités de certification publiques, dont SSL.com, suppriment l'EKU clientAuth des nouveaux certificats et de ceux renouvelés. TLS Les certificats serveur sont supprimés depuis fin 2025, et la date limite pour la suppression dans le cadre du programme Chrome Root est le 15 mars 2027. Si vos systèmes dépendent de l'EKU clientAuth pour l'authentification mutuelle TLSPour l'authentification VPN ou un cas d'utilisation similaire, prévoyez de migrer ce cas d'utilisation vers un certificat d'authentification client dédié avant le renouvellement de vos certificats actuels. Les certificats émis avant la date limite de chaque autorité de certification restent valides jusqu'à leur expiration.

Si vous utilisez ClientAuth dans l'un de vos TLS Pour toute question relative aux certificats de serveur, nous vous encourageons à contacter notre équipe afin que nous puissions travailler ensemble pour trouver la meilleure solution pour votre organisation.

Que sont les utilisations de clés étendues (EKU) ? 

Utilisation étendue des clés (EKU), est une extension de certificat qui définit la fonction prévue d'une clé publique au sein d'un certificat numérique. Elle établit un ensemble structuré d'applications autorisées, garantissant que la clé est utilisée uniquement pour des opérations cryptographiques spécifiques. Cette fonctionnalité est régie par Identificateurs d'objets (OID)—identifiants numériques uniques qui catégorisent chaque utilisation autorisée, telle que la signature de code, l’authentification du serveur, l’authentification du client ou la messagerie électronique sécurisée. Lorsque l'authentification est basée sur un certificat, l'entité de vérification examine le certificat pour identifier l'identifiant d'objet (OID) dans l'EKU. En intégrant l'extension EKU, un Autorité de certification (CA) restreint la portée du certificat à des rôles prédéfinis, chaque objectif désigné étant explicitement mappé à un OID. 

Par exemple : 

• TLS Authentification du serveur Web – Indique que le certificat peut être utilisé pour authentifier un serveur (par exemple, un site Web HTTPS). L'OID correspondant à l'authentification du serveur est 1.3.6.1.5.5.7.3.1 

• TLS Authentification du client Web – Indique que le certificat peut être utilisé par un client pour s'authentifier auprès d'un serveur (par exemple, un certificat client pour l'authentification mutuelle). TLS). L'OID attribué à l'authentification client est 1.3.6.1.5.5.7.3.2 

Les navigateurs et les serveurs n'ont besoin que de serveurAuth EKU à établir une connexion sécurisée pour HTTPS mais historiquement beaucoup TLS les certificats de serveur comprenaient à la fois le serveurAuth et clientAuth EKU.  Voici un exemple de un tel certificat :

Et événement? 

À partir de septembre 15, 2025 SSL.com va aide TLS certificats qui incluent uniquement les serveurAuth EKU (Et pas clientAuth) pour les certificats de serveur. Autrement dit, les nouveaux certificats SSL/TLS les certificats pour votre site Web ou votre serveur seront explicitement destinés uniquement à « l'authentification du serveur ». 

Pourquoi supprimer le clientAuth EKU à partir des certificats du serveur ? 

Plusieurs raisons justifient ce mandat : 

• Sécurité et portée : Public mode TLS les certificats sont censé uniquement authentifier les serveurs sur le web. Cette suppression assure une séparation claire entre les fonctionnalités serveur et client. L'EKU ClientAuth est utilisée pour l'authentification des machines et des utilisateurs avec Mutual TLS (mTLS) et d’autres scénarios d’authentification. 

• Prévenir les erreurs de configuration : Certains systèmes pourraient faire confiance tout certificat d'une autorité de certification publique pour l'authentification du client si l'EKU est présent, ce qui pourrait constituer un risque de sécurité. 

• Exigences du navigateur : Les principaux navigateurs ne nécessitent pas et ne vérifient pas l'EKU clientAuth dans le certificat d'un site Web.  

• Simplifié PKI Archi En séparant les utilisations, les autorités de certification peuvent maintenir des hiérarchies de certificats distinctes pour le serveur TLS par rapport à d’autres fins. 

Conformité de l'industrie 

Cette modification de politique est une exigence du CA/Browser Forum qui est mise en œuvre progressivement dans l'ensemble du secteur, le programme Chrome Root ayant fixé la date limite d'application finale au 15 mars 2027. TLS certificats de serveur.

Impact sur les environnements de serveur 

Pour la grande majorité des déploiements de serveurs, ce changement sera faible impact or aucun impact. Voici à quoi vous attendre: 

• Serveurs Web standard (HTTPS) : Aucun impact. Les certificats mis à jour continueront de fonctionner normalement. 

• Certificats existants : Tout certificat délivré avant la coupure continuera de fonctionner jusqu'à son expiration. 

• Mutuel TLS (mTLS) et scénarios de certification client : Si vous utilisiez un TLS certificat de serveur pour authentification client, vous devrez obtenir un certificat séparé auprès du clientAuth EKU d'une autre source.  

• Systèmes d'entreprise nécessitant les deux EKU : Certains systèmes hérités ou d'entreprise exigent les deux EKU. Vérifiez si des mises à jour sont nécessaires pour se conformer aux nouvelles règles. 

• Certificats pour les clients API, les appareils IoT, etc. : Si votre cas d'utilisation repose sur clientAuth EKU, vous devrez obtenir un certificat d'authentification client dédié. SSL.com propose Certificats d'authentification client. 

Actions requises pour les clients 

1. Faites l'inventaire de vos certificats : Identifiez tout TLS certificats utilisés et vérification de l'EKU clientAuth. 
2. Identifier les cas de double usage : Déterminez si l’un de vos systèmes repose sur un TLS certificat pour l'authentification du client. 
3. Plan de renouvellement/réémission du certificat : Les futurs certificats seront émis sans clientAuth EKU par défaut. 
4. Réédition anticipée si nécessaire : Si vous souhaitez mettre à jour vos certificats de manière proactive, vous pouvez les réémettre avant la date limite. 
5. Obtenez des certificats d'authentification client si nécessaire : Sécurisez un certificat séparé avec le clientAuth EKU si besoin. 
6. Mettre à jour la documentation et la configuration : Modifiez tous les scripts ou documentations de demande de certificat automatisés qui supposaient auparavant que les deux EKU seraient présents. 

FAQ (Foire aux questions) 

Q1. Qu'est-ce que l'EKU « Authentification client » et pourquoi figurait-elle dans mon certificat ? 

L'EKU « Authentification client » indique qu'un certificat peut être utilisé par un client pour s'authentifier auprès d'un serveur. Certaines autorités de certification l'incluaient historiquement dans TLS certificats par défaut, mais cela n'a jamais été nécessaire pour la sécurité normale du site Web. 

Q2. Les navigateurs vont-ils rejeter mon certificat s'il contient l'EKU clientAuth ? 

Non. Les navigateurs n'interdisent pas les certificats existants comportant l'EKU clientAuth. La modification de septembre 2025 n'a affecté que l'émission de nouveaux certificats. Un certificat émis avant cette date reste valide jusqu'à son expiration.

Q3. Mon actuel TLS Le certificat indique « Authentification client » dans sa section « Utilisation étendue de la clé ». Est-il désormais invalide ? 

Non, il reste valide. Vous n'avez pas besoin de le remplacer immédiatement. Lors du renouvellement, le nouveau certificat n'inclura tout simplement pas l'EKU clientAuth. 

Q4. Comment puis-je vérifier si un certificat possède l'EKU clientAuth ? 

Vous pouvez inspecter les détails du certificat à l'aide d'OpenSSL, de PowerShell ou d'outils d'interface graphique pour vérifier le Utilisation étendue des clés extension. 

Q5. Notre système exige que le certificat du serveur contienne les EKU serverAuth et clientAuth. Que faire ? 

Vous devez mettre à jour votre système pour n'exiger que serveurAuth pour les certificats de serveur. Si l'authentification du client est nécessaire, obtenez un certificat distinct avec le clientAuth EKU de SSL.com. 

Q6. Puis-je toujours obtenir un certificat de confiance publique avec uniquement l'EKU d'authentification client ? 

Certaines autorités de certification, comme SSL.com, proposent des services dédiés certificats d'authentification client. Ceux-ci sont distincts de TLS certificats et généralement utilisés pour l'authentification d'entreprise. 

Q7. Cela affecte-t-il d'autres EKU ou types de certificats (signature de code, e-mail, etc.) ? 

Non, ce changement est spécifique à TLS certificats de serveurLa signature de code et les certificats de courrier électronique ont leurs propres exigences EKU. 

Q8. Nous utilisons l'authentification par certificat client sur notre site web. Ce changement a-t-il un impact sur ce système ? 

Non, mutuel TLS (mTLS) L'authentification fonctionne toujours. Cependant, assurez-vous que les certificats clients présentés par les utilisateurs possèdent toujours les droits clientAuth EKU si nécessaire. 

Q9. Est-ce lié au changement à venir vers des durées de vie des certificats plus courtes (certificats de 90 jours) ? 

Non, il s’agit de changements sectoriels distincts, même si tous deux visent à améliorer la sécurité et les pratiques de gestion des certificats. 

Q10. Où puis-je consulter les exigences officielles concernant ce changement ? 

Le Politique du programme racine de Google Chrome  fournit des lignes directrices sur l'interdiction du clientAuth EKU dans TLS certificats de serveur. 

Résumé 

La suppression du clientAuth EKU de TLS Les certificats de serveur constituent un changement de politique sectoriel visant à renforcer la sécurité et à prévenir les abus. Pour la plupart des utilisateurs, l'impact sera négligeable. Cependant, si vous utilisez l'EKU clientAuth, il est conseillé d'agir proactivement pour obtenir le type de certificat adapté à vos besoins. 

Si vous avez des questions ou avez besoin d'aide, veuillez contacter notre équipe d'assistance à support@ssl.com.