Partager via

Modifications apportées à la vérification du certificat de serveur TLS du navigateur Microsoft Edge

  • Article

Lorsque Microsoft Edge établit des connexions à un serveur HTTPS, Edge vérifie que le serveur a présenté un certificat émis par une entité approuvée par le navigateur. Cette relation d’approbation est établie par le biais d’une liste d’approbation de certificats et le composant responsable de l’exécution des vérifications est appelé vérificateur de certificat.

Dans les versions antérieures de Microsoft Edge, la liste d’approbation de certificats par défaut et la logique du vérificateur de certificat étaient fournies par la plateforme de système d’exploitation sous-jacente.

Pour les appareils gérés, à partir de Microsoft Edge 112 sur Windows et macOS, la liste d’approbation de certificats par défaut et le vérificateur de certificat sont fournis par le navigateur et fournis avec celui-ci. Cette approche dissocie la liste et le vérificateur du magasin racine du système d’exploitation hôte pour le comportement de vérification par défaut. Pour plus d’informations sur le moment de la modification, consultez la chronologie du déploiement et les conseils de test .

Même après la modification, en plus d’approuver les racines intégrées fournies avec Microsoft Edge, le navigateur interroge la plateforme sous-jacente et approuve les racines installées localement que les utilisateurs et/ou les entreprises ont installées. Par conséquent, les scénarios où un utilisateur ou une entreprise a installé plus de racines dans le magasin racine du système d’exploitation hôte doivent continuer à fonctionner.

Cette modification signifie que la logique de vérification de certificat fonctionne de manière cohérente dans Microsoft Edge sur Windows et macOS. Dans une prochaine version à déterminer, le déploiement s’appliquera également à Linux et Android. En raison des stratégies d’Apple App Store, le magasin racine et le vérificateur de certificats fournis par Apple continuent d’être utilisés sur iOS et iPadOS.

Source de la liste d’approbation de certificat par défaut

Le magasin racine fourni avec Microsoft Edge sur Windows et macOS provient de la liste de certificats approuvés (CTL) définie par le programme de certificats racines approuvés Microsoft. Ce programme de certificat racine définit la liste fournie avec Microsoft Windows. Par conséquent, les clients doivent s’attendre à ne voir aucune modification visible par l’utilisateur.

Sur macOS, si un certificat émis par un certificat racine approuvé par la plateforme, mais pas par le programme de certificat racine approuvé de Microsoft, le certificat n’est plus approuvé. Ce manque de confiance n’est pas censé être une situation courante, car la plupart des serveurs garantissent déjà que les certificats TLS qu’ils utilisent sont approuvés par Microsoft Windows.

Les mises à jour sont publiées selon la cadence décrite dans les notes de publication du programme racine approuvé Microsoft.

Chronologie du déploiement et conseils de test

À compter de Microsoft Edge 109, une stratégie d’entreprise (MicrosoftRootStoreEnabled) et un indicateur dans edge://flags (« Microsoft Root Store ») sont disponibles pour contrôler le moment où le magasin racine intégré et le vérificateur de certificats sont utilisés.

Les appareils qui ne sont pas gérés par l’entreprise ont commencé à recevoir la fonctionnalité via un déploiement de fonctionnalité contrôlé (CFR) dans Microsoft Edge 109 et ont atteint 100 % des appareils non gérés dans Edge 111. Pour plus d’informations, consultez Configurations et expérimentation de Microsoft Edge, qui explique comment fonctionnent les CFR dans Microsoft Edge. Pour les appareils gérés par l’entreprise, l’implémentation existante fournie par la plateforme a été utilisée via Microsoft Edge 111.

À compter de Microsoft Edge 112, la valeur par défaut a changé pour tous les appareils Windows et macOS, y compris ceux gérés par l’entreprise, afin d’utiliser l’implémentation du vérificateur et la CTL fournies avec le navigateur. La stratégie MicrosoftRootStoreEnabled continue d’être disponible dans cette version pour permettre aux entreprises de revenir au comportement précédent si des problèmes inattendus sont détectés et de signaler les problèmes à Microsoft.

Microsoft recommande aux entreprises qui ont des proxys d’arrêt et d’inspection ou d’autres scénarios impliquant des certificats de serveur TLS émis par des racines qui ne sont pas dans la CTL Microsoft d’identifier et de signaler de manière proactive les problèmes de compatibilité à Microsoft.

Dans Microsoft Edge 115, la prise en charge de la stratégie MicrosoftRootStoreEnabled est supprimée.

Différences connues de comportement des certificats approuvés localement sur Windows

Conformité RFC 5280 plus stricte

Le nouveau vérificateur de certificats intégré est plus strict dans l’application des exigences RFC 5280 que l’ancien vérificateur basé sur la plateforme.

Voici quelques exemples de conformité RFC 5280 plus stricte :

  1. Les paramètres d’algorithme pour les algorithmes ECDSA doivent être absents. L’ancien vérificateur ignore les paramètres tandis que le nouveau rejette le certificat. Pour plus d’informations, consultez problème chromium 1453441 pour plus d’informations.
  2. Les contraintes de nom spécifiant une adresse IP doivent contenir huit octets pour les adresses IPv4 et 32 octets pour les adresses IPv6. Si votre certificat spécifie une adresse IP vide, vous devez réémettre le certificat et omettre entièrement la contrainte de nom d’adresse IP.
  3. Les contraintes de nom avec une liste « exclue » vide ne sont pas valides. La visionneuse de certificats Windows affiche cette liste comme Excluded=None dans les Name Constraints détails. Pour plus d’informations, consultez problème chromium 1457348 pour plus d’informations. Au lieu de spécifier une liste vide, omettez-la entièrement.

Différences de comportement de vérification de révocation connues sur Windows

En plus des exigences RFC 5280 plus strictes, le nouveau vérificateur ne prend pas en charge les URI de liste de révocation de certificats (CRL) basés sur LDAP.

Si votre entreprise active la stratégie RequireOnlineRevocationChecksForLocalAnchors et que les listes de révocation de certificats ne sont pas valides par RFC 5280, votre environnement peut commencer à voir ERR_CERT_NO_REVOCATION_MECHANISM et/ou ERR_CERT_UNABLE_TO_CHECK_REVOCATION des erreurs.

Si vous rencontrez ERR_CERT_NO_REVOCATION_MECHANISM, vous devez confirmer que la liste de révocation de certificats à l’URI spécifié par le certificat retourne une réponse encodée DER (et non encodée PEM).

Voir également