Pourquoi un certificat diffère selon le navigateur

Un certificat Transport Layer Security (TLS) peut afficher une chaîne valide dans un navigateur, puis échouer dans un autre sur la même machine. Ce n’est pas forcément un bug : chaque navigateur choisit, totalement ou partiellement, ses autorités racines, ses règles cryptographiques et ses mécanismes de révocation.

→ Lire l’explication complète de la marmotte

Magasins de confiance : le compromis entre cohérence et intégration

Un magasin de confiance est la liste des certificats racines qu’un logiciel accepte comme point de départ d’une chaîne de certification. Une autorité de certification émet des certificats intermédiaires, puis des certificats de serveur. Le navigateur remonte cette chaîne jusqu’à une racine présente dans son magasin local.

Le compromis central est brutal : utiliser le magasin du système d’exploitation donne une intégration naturelle avec la gestion de parc, mais laisse le navigateur dépendre des décisions locales de la plateforme. Utiliser un magasin propre au navigateur homogénéise le comportement entre plateformes, mais crée une seconde politique de confiance à administrer. Les deux approches coûtent quelque chose. La solution magique tient généralement dans une slide où les certificats expirent poliment.

Pour un service Internet public, la règle est de viser une autorité présente dans les programmes de confiance des principaux navigateurs, puis de tester les navigateurs et systèmes réellement supportés. Pour un service interne, la règle est plus stricte : distribuer une racine privée par la gestion centralisée des postes, documenter les navigateurs qui l’acceptent et interdire l’import manuel comme mécanisme de déploiement. Un certificat privé dans un poste administré à la main n’est pas une architecture, c’est une loterie avec une date d’expiration.

La chaîne envoyée par le serveur doit contenir le certificat serveur et les certificats intermédiaires nécessaires, jamais le certificat racine. Compter sur le téléchargement d’un intermédiaire via une URL embarquée dans le certificat produit des résultats variables, notamment derrière un proxy filtrant ou sur des postes sans accès sortant. Le serveur doit fournir la chaîne complète : c’est une obligation de compatibilité, pas une optimisation.

Les principes de chaîne et de signature sont détaillés dans la PKI expliquée. Pour les contraintes de négociation, versions et noms de domaine, voir aussi TLS expliqué.

Firefox, Chrome, Edge et Safari : qui décide de la racine

Firefox utilise principalement le magasin de racines Mozilla Root Store pour les certificats publics. Son moteur cryptographique s’appuie sur Network Security Services (NSS), une bibliothèque qui maintient aussi une base locale de certificats. Selon la plateforme et les politiques d’entreprise, Firefox peut importer ou reconnaître des autorités du système, notamment sous Windows via une politique dédiée. Cette option est un choix d’administration, pas une propriété universelle à présumer.

Chrome déploie Chrome Root Store pour la confiance publique sur plusieurs plateformes. Ce magasin est piloté par Google et découple progressivement les racines publiques du magasin natif de certains systèmes. Les autorités privées ajoutées localement restent toutefois soumises à l’intégration de plateforme et aux politiques d’entreprise. Chrome sur Android dépend encore fortement du magasin Android, tandis que les comportements de Chromium compilé par une distribution Linux peuvent diverger. Le nom du navigateur ne suffit pas : la version, la plateforme et le canal de distribution comptent.

Microsoft Edge s’appuie généralement sur le magasin de certificats Windows lorsqu’il tourne sous Windows. Une racine déployée dans le magasin « Trusted Root Certification Authorities » de l’ordinateur est donc normalement reconnue par Edge, Chrome et les composants utilisant les interfaces de validation Windows. Cette proximité est pratique pour les environnements Active Directory, mais elle augmente aussi la portée d’une racine installée par erreur ou par un outil d’inspection TLS trop enthousiaste.

Safari utilise les services de sécurité d’Apple et les certificats racines approuvés par Apple. Le trousseau macOS permet de gérer des autorités locales, avec des réglages de confiance parfois définis au niveau utilisateur ou système. Cette distinction est critique : une racine ajoutée au trousseau d’un compte ne rend pas nécessairement un service accessible à tous les comptes, aux processus systèmes ou aux appareils mobiles gérés.

Sous Linux, la situation est moins uniforme. Le magasin système est souvent exposé via p11-kit, un composant de partage des ancres de confiance, et alimenté par les paquets de certificats de la distribution. Firefox peut conserver son propre comportement, Chrome peut suivre son magasin embarqué pour les racines publiques, et un navigateur Chromium empaqueté par une distribution peut dépendre de bibliothèques différentes. Déclarer « Linux fait confiance à cette racine » sans nommer la distribution, le paquet navigateur et sa version ne signifie rien d’opérationnel.

Causes précises d’un certificat accepté ici et rejeté là

La première cause est l’absence de racine commune. Une autorité privée installée dans Windows mais absente de Firefox sera acceptée par Edge et possiblement refusée par Firefox. L’inverse existe aussi avec une racine publique ajoutée ou retirée du programme Mozilla avant qu’une plateforme n’applique une modification équivalente.

La seconde cause est la politique cryptographique. Un navigateur peut refuser une clé RSA trop courte, un algorithme de signature ancien, une extension critique incohérente ou un usage de clé incompatible. RSA signifie Rivest, Shamir, Adleman : cet algorithme reste courant, mais une chaîne RSA n’est pas automatiquement acceptable. Le certificat doit aussi présenter l’usage serveur attendu et un nom dans l’extension Subject Alternative Name, qui liste les noms autorisés. Le champ historique Common Name ne doit plus servir de roue de secours.

La troisième cause est la transparence des certificats. Certificate Transparency est un système de journaux publics append-only qui enregistre l’émission de certificats publics. Chrome impose des preuves d’enregistrement pour de nombreux certificats publics, sous forme de Signed Certificate Timestamp, une preuve horodatée signée. Un certificat peut donc former une chaîne correcte mais être rejeté faute de preuves de transparence conformes. Cette règle ne s’applique pas de la même manière aux autorités privées.

La quatrième cause est la révocation. Online Certificate Status Protocol (OCSP) permet de demander l’état d’un certificat à une autorité. Les navigateurs ne réagissent pas tous de façon identique à une réponse absente, lente ou invalide. Certains utilisent des listes de révocation fournies par l’éditeur, certains mettent en cache, certains privilégient la disponibilité lorsque le contrôle de révocation échoue. Une révocation ne ferme jamais les sessions TLS déjà établies : elle affecte les validations ultérieures. Attendre d’elle une télécommande d’arrêt d’urgence revient à demander à un calendrier de remplacer un extincteur.

Enfin, les différences proviennent de la construction de chaîne. Plusieurs chemins peuvent exister vers des racines différentes, notamment après une transition d’autorité ou une signature croisée. Le navigateur choisit un chemin selon ses propres règles et son magasin local. Une chaîne apparemment « valide » dans un test en ligne peut échouer chez un client réel si ce test ne reproduit ni sa racine, ni ses règles, ni son réseau.

Diagnostic reproductible d’une chaîne TLS

Le premier diagnostic doit séparer trois faits : ce que le serveur envoie, ce que le magasin local accepte et ce que le navigateur impose en plus. openssl vérifie une chaîne contre un fichier d’ancres donné ; il ne reproduit ni la transparence des certificats ni toutes les politiques de Chrome, Firefox, Edge ou Safari.

L’exemple suivant fonctionne sur une machine Linux disposant d’OpenSSL et du bundle de certificats Debian ou Ubuntu. Il valide le nom et force l’échec si la chaîne ne peut pas être construite.

# Vérifier la chaîne réellement présentée par le serveur et le nom demandé.
# Le fichier CA est le magasin système Debian/Ubuntu, pas celui de Firefox.
openssl s_client \
  -connect service.exemple.fr:443 \
  -servername service.exemple.fr \
  -verify_hostname service.exemple.fr \
  -verify_return_error \
  -CAfile /etc/ssl/certs/ca-certificates.crt \
  </dev/null

# Afficher les certificats transmis, pour repérer un intermédiaire manquant.
openssl s_client \
  -connect service.exemple.fr:443 \
  -servername service.exemple.fr \
  -showcerts \
  </dev/null

Un résultat Verify return code: 0 (ok) prouve uniquement que cette chaîne est acceptable par ce bundle OpenSSL. Si Chrome refuse encore, vérifier les journaux de transparence, les règles de nommage, la date système, les politiques de gestion de poste et la présence d’un proxy TLS. Si Firefox refuse seul, inspecter sa politique d’import des racines d’entreprise et sa base NSS.

Le test doit être automatisé depuis les plateformes supportées, avec navigateur réel ou moteur de navigateur. Une sonde OpenSSL unique est un bon détecteur de panne de chaîne, pas une preuve de compatibilité. La section PKI et TLS traite les autres contrôles à intégrer autour de cette validation.

Racines privées, interception TLS et surface d’attaque

Ajouter une racine privée à un magasin de confiance donne à son détenteur le pouvoir d’émettre des certificats acceptés pour n’importe quel nom. C’est nécessaire pour une autorité interne, et c’est exactement pourquoi l’opération est dangereuse. Une racine compromise transforme un contrôle local en capacité d’interception à grande échelle.

L’interception TLS par proxy repose sur ce mécanisme : le proxy présente un certificat fabriqué à la volée, signé par une racine d’entreprise installée sur le poste. Cette pratique casse la confidentialité de bout en bout entre le navigateur et le serveur distant. Elle peut aussi casser les applications utilisant l’épinglage de certificat, les mises à jour logicielles, les protocoles non couverts par le proxy et les services dont les règles de transparence sont strictes. Le chiffrement reste actif, mais le proxy devient un point de terminaison. Les slogans « inspection chiffrée sans compromis » méritent donc le même regard qu’un parapluie troué vendu comme ventilation naturelle.

Une autorité racine publique compromise ou mal contrôlée expose aussi à l’émission frauduleuse. Certificate Transparency permet de détecter des émissions publiques inattendues, pas de bloquer instantanément une connexion déjà établie. Une surveillance des journaux doit alerter sur les noms détenus, avec une procédure d’escalade vers l’autorité émettrice.

Le magasin de confiance ne garantit pas l’identité applicative, l’absence de logiciel malveillant sur le poste, la confidentialité après terminaison TLS ou l’autorisation métier. Pour l’authentification mutuelle entre services, un certificat client peut compléter le mécanisme, avec les contraintes décrites dans mTLS. Le navigateur ne remplace ni une politique d’accès ni une vérification des identités côté application.

Exploitation : rotation, supervision et reprise

La clé privée d’une autorité racine doit rester hors ligne ou dans un HSM (Hardware Security Module), un équipement qui protège les opérations cryptographiques et limite l’export de clé. Une autorité intermédiaire en ligne émet les certificats courants. Cette séparation réduit le rayon d’explosion : compromettre l’intermédiaire impose une révocation et une réémission, compromettre la racine impose une reconstruction complète de la confiance.

La rotation d’une racine n’est pas le renouvellement d’un certificat serveur. Elle exige une période de coexistence, la distribution de la nouvelle racine avant l’émission de nouvelles chaînes, puis le retrait contrôlé de l’ancienne. Retirer l’ancienne racine avant la migration des postes coupe les services. La conserver indéfiniment maintient une capacité de signature qu’il faudrait avoir supprimée. La bonne date de retrait est déterminée par l’inventaire des clients, pas par l’optimisme du comité de changement.

Superviser au minimum l’expiration des certificats serveurs, la disponibilité des répondeurs de révocation, la conformité de la chaîne envoyée, la présence des preuves de transparence et les erreurs navigateur remontées par les utilisateurs. Conserver les journaux d’émission et les sauvegardes chiffrées des configurations d’autorité, mais ne jamais sauvegarder une clé racine en clair dans un partage d’équipe. Ce genre de coffre-fort finit toujours par avoir un fichier nommé final_final_v2.

🦫 Explication de la marmotte 🍫

Quand un navigateur ouvre un site sécurisé, le site lui envoie un certificat. Ce document contient le nom du site, une date de validité, une clé publique et une signature faite par une autorité de certification. Le navigateur vérifie d’abord que le nom demandé figure dans le certificat, que la date est correcte et que les usages prévus correspondent à un site web.

Il examine ensuite qui a signé ce certificat. Souvent, une autorité intermédiaire a signé le certificat du site, et une autorité racine a signé l’autorité intermédiaire. Le navigateur accepte cette suite seulement si l’autorité racine figure dans sa liste locale de confiance.

Cette liste varie selon le navigateur et le système utilisé. Certains navigateurs ont leur propre liste. D’autres utilisent davantage la liste du système. Une entreprise peut aussi ajouter une autorité privée pour ses sites internes ou pour inspecter les connexions chiffrées. Si cette autorité manque, le certificat est rejeté, même si un autre navigateur l’accepte.

Le navigateur applique aussi ses propres règles : taille de clé, méthode de signature, preuve que le certificat public a été enregistré dans des journaux contrôlables, et état de révocation. Si une seule vérification échoue, la connexion est bloquée ou accompagnée d’un avertissement. Le serveur doit donc envoyer tous les certificats intermédiaires nécessaires, et l’organisation doit distribuer ses autorités privées de manière contrôlée.

Pages voisines

La citent

Pourquoi un certificat diffère selon le navigateur

Elle cite

Pourquoi un certificat diffère selon le navigateur

Pourquoi un certificat diffère selon le navigateur

Magasins de confiance : le compromis entre cohérence et intégration

Firefox, Chrome, Edge et Safari : qui décide de la racine

Causes précises d’un certificat accepté ici et rejeté là

Diagnostic reproductible d’une chaîne TLS

Racines privées, interception TLS et surface d’attaque

Exploitation : rotation, supervision et reprise

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines