Questions fréquentes sur la migration des CA racine pour Google Maps Platform

Ce document inclut les sections suivantes :

Pour une présentation plus détaillée sur la migration en cours des CA racine de Google, consultez la section Quelle est la situation.

Terminologie

Vous trouverez ci-dessous la liste des termes importants utilisés dans ce document. Pour une présentation plus complète de la terminologie associée, consultez les questions fréquentes sur Google Trust Services.

Certificat SSL/TLS
Un certificat lie une clé cryptographique à une identité.
Les certificats SSL/TLS sont utilisés pour authentifier et établir des connexions sécurisées aux sites Web. Les certificats sont émis et signés de manière cryptographique par des entités appelées "autorités de certification".
Les navigateurs s'appuient sur les certificats émis par les autorités de certification de confiance pour s'assurer que les informations transmises sont envoyées au serveur approprié et qu'elles sont chiffrées lorsqu'elles sont en transit.
Secure Sockets Layer (SSL)
Secure Socket Layer était le protocole le plus largement déployé pour chiffrer les communications Internet. Le protocole SSL n'est plus considéré comme sécurisé et ne doit plus être utilisé.
Transport Layer Security (TLS)
Transport Layer Security est le successeur de SSL.
Autorité de certification (CA, Certificate Authority)
Une autorité de certification est une sorte de bureau d'émission de passeports numériques pour les appareils et les personnes. Il émet des documents protégés par cryptographie (certificats) pour attester qu'une entité (par exemple, un site Web) est bien celle qu'elle prétend.
Avant d'émettre un certificat, les CA doivent vérifier que les noms figurant dans le certificat sont associés à la personne ou à l'entité qui le demande.
Le terme "Autorité de certification" peut désigner à la fois les organisations, comme Google Trust Services, et les systèmes qui émettent des certificats.
Magasin de certificats racine
Un magasin de certificats racine contient un ensemble d'autorités de certification approuvées par un fournisseur d'applications. La plupart des navigateurs Web et des systèmes d'exploitation possèdent leur propre magasin de certificats racine.
Pour être intégrée à un magasin de certificats racine, l'autorité de certification doit respecter des exigences strictes définies par le fournisseur d'applications.
Ces exigences incluent généralement le respect des normes du secteur telles que les règles du CA/Browser Forum.
Autorité de certification racine
Une autorité de certification racine (ou, plus exactement, son certificat) est le certificat de niveau le plus élevé dans une chaîne de certificats.
Les certificats CA racine sont généralement autosignés. Les clés privées qui leur sont associées sont stockées hors connexion dans des installations hautement sécurisées pour qu'elles soient protégées des accès non autorisés.
Autorité de certification intermédiaire
Une autorité de certification intermédiaire (ou, plus exactement, son certificat) est un certificat utilisé pour signer d'autres certificats dans une chaîne de certificats.
Les CA intermédiaires servent principalement à permettre que des certificats soient émis en ligne alors que le certificat CA racine reste hors connexion.
Les CA intermédiaires sont également appelées "CA subordonnées".
Autorité de certification émettrice
Une autorité de certification émettrice (ou, plus exactement, son certificat) est le certificat utilisé pour signer le certificat de niveau le plus bas dans une chaîne de certificats.
Il est communément appelé "certificat d'abonné" ou "certificat d'entité finale". Dans ce document, nous utiliserons également le terme certificat de serveur.
Chaîne de certificats
Les certificats sont associés à leur émetteur (ils sont signés de manière cryptographique par ceux-ci). Une chaîne de certificats est composée d'un certificat d'entité finale, de tous ses certificats d'émetteur et d'un certificat racine.
Signature croisée
Les clients des fournisseurs d'applications doivent mettre à jour leur magasin de certificats racine en incluant les nouveaux certificats CA pour qu'ils soient considérés comme fiables par leurs produits. Il peut s'écouler un certain temps avant que les produits contenant les nouveaux certificats CA soient largement utilisés.
Pour améliorer la compatibilité avec les clients plus anciens, les certificats CA peuvent être signés de manière "croisée" par une autorité de certification établie plus ancienne. Cela crée un deuxième certificat CA pour la même identité (c'est-à-dire la même paire nom et clé).
Selon les CA incluses dans leur magasin de certificats racine, les clients créeront une chaîne de certificats différente jusqu'à un certificat racine de confiance.

Informations générales

Quelle est la situation ?

Vue d'ensemble

En 2017, Google a lancé un projet sur plusieurs années pour émettre et utiliser ses propres certificats racine, les signatures cryptographiques à la base de la sécurité Internet TLS utilisée par HTTPS.

Depuis la première phase, la sécurité TLS des services Google Maps Platform est garantie par GS Root R2, une autorité de certification racine renommée dont la fiabilité est largement établie. Google a acheté GS Root R2 à GMO GlobalSign pour faciliter la transition vers ses propres CA racine, émises par Google Trust Services (GTS).

Presque tous les clients TLS (tels que les navigateurs Web, les smartphones et les serveurs d'applications) ont approuvé ce certificat racine et ont donc pu établir une connexion sécurisée avec les serveurs Google Maps Platform pendant la première phase de la migration.

Cependant, une CA peut par essence ne pas émettre de certificats qui sont valides au-delà du délai d'expiration de son propre certificat. Étant donné que GS Root R2 a expiré le 15 décembre 2021, Google migrera ses services vers une nouvelle CA, GTS Root R1 Cross, en utilisant un certificat émis par sa propre CA racine, GTS Root R1.

Bien que la grande majorité des systèmes d'exploitation et des bibliothèques clientes TLS récents ont déjà approuvé les CA racine GTS, pour assurer une transition en douceur pour la plupart des anciens systèmes également, Google a acquis une signature croisée auprès de GMO GlobalSign utilisant GlobalSign Root CA - R1, l'une des CA racine les plus anciennes et les plus fiables actuellement disponibles.

Par conséquent, la plupart des clients Google Maps Platform auront déjà approuvé l'une ou l'autre de ces autorités de certification racine reconnues (ou les deux), et la deuxième phase de la migration n'aura alors aucune conséquence.

Cela s'applique également aux clients qui, conformément à nos instructions lors de la première phase de la migration en 2018, ont installé tous les certificats de notre bundle de CA racine Google de confiance.

Nous vous recommandons de vérifier vos systèmes dans les cas suivants :

  • Vos services sont exécutés sur des plates-formes non standards ou anciennes, et/ou vous gérez votre propre magasin de certificats racine.
  • Vous n'avez pas pris de mesures en 2017-2018 lors de la première phase de la migration de CA racine de Google, ou vous n'avez pas installé l'ensemble des certificats du bundle de CA racine Google de confiance.

Si vous êtes dans l'un des cas ci-dessus, il se peut que vous deviez mettre à jour vos clients avec les certificats racine recommandés afin d'assurer une utilisation ininterrompue de Google Maps Platform pendant cette phase de migration.

Pour plus d'informations techniques, consultez la section ci-dessous. Pour obtenir des instructions générales, reportez-vous à la section Comment vérifier si mon magasin de certificats racine doit être mis à jour.

Nous vous recommandons également de continuer à synchroniser vos magasins de certificats racine avec le bundle de CA racine proposé ci-dessus pour préparer vos services aux futurs changements de CA. Cependant, nous annoncerons de tels changements à l'avance. Pour savoir comment vous tenir informé, consultez les sections Comment puis-je me renseigner pendant cette phase de migration et Comment recevoir un avis préalable pour les prochaines migrations.

Récapitulatif technique

Comme annoncé le 15 mars 2021 dans le blog Google sur la sécurité, GS Root R2, la CA racine utilisée par Google Maps Platform depuis le début de l'année 2018, est arrivé à expiration le 15 décembre 2021. Google migrera donc cette année vers une CA nouvellement émise, GTS Root R1 Cross. En conséquence, nos services vont progressivement basculer vers les certificats d'entité finale TLS émis par cette nouvelle CA.

Presque tous les clients et les systèmes TLS récents sont déjà préconfigurés avec le certificat GTS Root R1 ou doivent le recevoir via des mises à jour logicielles normales. GlobalSign Root CA - R1 devrait même être disponible sur les anciens systèmes.

Cependant, nous vous conseillons de vérifier vos systèmes si vous êtes dans au moins l'un des deux cas suivants :

  • Vos services sont exécutés sur des plates-formes non standards ou anciennes, et/ou vous gérez votre propre magasin de certificats racine.
  • Vous n'avez pas pris de mesures en 2017-2018 lors de la première phase de la migration de CA racine de Google, ou vous n'avez pas installé l'ensemble des certificats du bundle de CA racine Google de confiance.

La section Comment vérifier si mon magasin de certificats racine doit être mis à jour indique la procédure générale à suivre pour vérifier si votre système sera affecté.

Pour en savoir plus, consultez Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance.

Comment puis-je me renseigner pendant cette phase de migration ?

Ajoutez le problème public 186840968 à vos favoris afin de recevoir les notifications correspondantes. Ces questions fréquentes sont également mises à jour tout au long de la migration, chaque fois que nous estimons qu'un sujet pourrait intéresser la communauté.

Comment recevoir un avis préalable pour les prochaines migrations ?

Nous vous recommandons de suivre le blog Google sur la sécurité. Nous nous efforcerons également de mettre à jour la documentation spécifique à chaque produit dès que possible suite aux annonces publiques sur le blog.

Abonnez-vous également aux notifications Google Maps Platform, car nous publions régulièrement sur le forum les modifications susceptibles d'affecter un grand nombre de clients.

Nous utilisons plusieurs services Google. Seront-ils tous concernés par la migration des CA racine ?

Oui. La migration des CA racine sera réalisée au niveau de l'ensemble des services et API Google, mais pas forcément selon le même calendrier. Cependant, une fois que vous avez vérifié que les magasins de certificats racine utilisés par vos applications clientes Google Maps Platform contiennent toutes les CA listées dans le bundle de CA racine Google de confiance, vos services ne devraient pas être affectés par la migration en cours. Vous pouvez également synchroniser les certificats du bundle pour vous préparer aux futurs changements de CA racine.

Pour en savoir plus, consultez les sections Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance et Quels types d'applications risquent de ne plus fonctionner.

La section Comment vérifier si mon magasin de certificats racine doit être mis à jour ci-dessous fournit également des instructions générales pour tester votre système.

Comment vérifier si mon magasin de certificats racine doit être mis à jour ?

Testez votre environnement d'application par rapport aux points de terminaison de test ci-dessous :

Votre système sera généralement compatible avec ce changement de CA racine si :

  • votre service s'exécute sur un système d'exploitation grand public recevant des mises à jour, vous avez appliqué régulièrement les correctifs au système d'exploitation et aux bibliothèques utilisés par le service, et vous ne gérez pas votre propre magasin de certificats racine, ou ;
  • vous avez suivi nos précédentes recommandations et installé toutes les CA racine du bundle de CA racine Google de confiance.

Nous recommandons aux clients potentiellement concernés d'installer immédiatement les certificats du bundle de CA racine Google de confiance afin d'éviter les interruptions de service à l'avenir.

Pour en savoir plus, consultez Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance.

Existe-t-il un outil simple permettant de valider mon magasin de certificats racine ?

Les deux outils de ligne de commande curl et openssl vous seront peut-être utiles. Ils sont disponibles sur la plupart des plates-formes et offrent de nombreuses options pour tester votre configuration.

Pour savoir comment installer curl, consultez la section Obtenir curl ci-dessous.

Les commandes openssl présentées ci-dessous concernent la version 1.1.1 ou ultérieure. Les versions antérieures à 1.1.1 ne sont plus prises en charge. Si vous utilisez une version antérieure, mettez-la à jour ou modifiez ces commandes tel que nécessaire pour votre version. Pour savoir comment installer openssl, consultez la section Obtenir OpenSSL.

D'autres outils utiles sont également proposés dans la section Où trouver les outils dont j'ai besoin ci-dessous.

Pour obtenir des instructions concrètes pour les tests, consultez la section Comment vérifier si mon magasin de certificats racine doit être mis à jour.

Tester votre magasin de certificats racine par défaut

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Valider le bundle de CA racine Google de confiance

Téléchargez le bundle de CA racine Google de confiance, puis procédez comme suit :

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Comment et quand se poursuivra la migration des CA racine de Google ?

  1. La première phase (migration vers GS Root R2), annoncée en janvier 2017, a été entamée fin 2017 et s'est achevée au cours du premier semestre 2018.
  2. La deuxième phase (migration vers GTS Root R1 Cross), annoncée en mars 2021, a été déployée avant l'expiration de GS Root R2 le 15 décembre 2021.

Le calendrier des phases de migration ultérieures sera annoncé bien avant que les certificats expirent.

Toutefois, vous pourrez préparer vos applications à ces changements à venir en synchronisant de votre magasin de certificats racine avec la liste des CA racine du bundle de CA racine Google de confiance.

Pour plus d'informations, consultez la section Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance.

Plan de déploiement général pour chaque service Google

  1. Le déploiement par étapes commence dans un seul centre de données.
  2. Le déploiement est progressivement étendu à d'autres centres de données jusqu'à ce qu'il existe une couverture mondiale.
  3. Si des problèmes graves sont détectés à un moment donné, vous pouvez effectuer un rollback temporaire des tests le temps qu'ils soient résolus.
  4. Sur la base des entrées provenant d'itérations précédentes, d'autres services Google sont inclus dans le déploiement jusqu'à ce que tous les services Google aient petit à petit migré vers les nouveaux certificats.

Qui sera concerné, quand et où ?

De plus en plus de développeurs Google Maps Platform commenceront à recevoir les nouveaux certificats à mesure que les centres de données seront migrés. Ces changements seront relativement localisés, car les requêtes client sont généralement transmises aux serveurs situés dans des centres de données géographiquement proches.

Comme nous ne pouvons pas anticiper avec certitude qui sera concerné, quand, ni où, nous recommandons à tous nos clients de vérifier leurs services bien à l'avance et de les préparer aux éventuelles phases de migration de CA racine Google.

Consultez la section Comment vérifier si mon magasin de certificats racine doit être mis à jour pour obtenir des conseils supplémentaires.

Points à noter

Les clients dont la configuration n'inclut pas le certificat racine nécessaire ne pourront pas valider leur connexion TLS à Google Maps Platform. Dans ce cas, ils enverront généralement un avertissement indiquant que la validation du certificat a échoué.

Selon leur configuration TLS, les clients peuvent continuer à envoyer une requête Google Maps Platform ou refuser de poursuivre la requête.

Quelles sont les exigences minimales requises pour qu'un client TLS puisse communiquer avec Google Maps Platform ?

Les certificats Google Maps Platform utilisent des noms alternatifs de sujet (SAN, Subject Alternative Names) de DNS. Par conséquent, le traitement du certificat d'un client doit pouvoir prendre en charge des SAN susceptibles d'inclure un caractère générique unique à la place du premier libellé du nom, par exemple, *.googleapis.com.

Pour connaître les autres prérequis, consultez la section Quelles sont les exigences recommandées pour qu'un client TLS puisse communiquer avec Google dans les questions fréquentes sur GTS.

Quels types d'applications risquent de ne plus fonctionner ?

L'application utilise le magasin de certificats racine du système sans aucune restriction imposée par le développeur

Applications de service Web Google Maps Platform

Si vous utilisez un OS standard (par exemple, Ubuntu, Red Hat, Windows 10/Server 2019 ou OS X) recevant régulièrement des mises à jour, votre magasin de certificats racine par défaut doit déjà inclure le certificat GTS Root R1.

Si vous utilisez une ancienne version d'OS qui ne reçoit plus de mises à jour, le certificat GTS Root R1 n'est pas forcément présent. Toutefois, votre magasin de certificats racine contient probablement GlobalSign Root CA - R1, l'une des CA racine les plus anciennes et les plus fiables.

Pour les applications mobiles qui appellent des services Web Google Maps Platform directement à partir de l'appareil de l'utilisateur final, les consignes de la section Les applications mobiles risquent-elles de ne plus fonctionner s'appliquent.

Applications Google Maps Platform côté client

Les applications de l'API Maps JavaScript s'appuient généralement sur les certificats racine du navigateur Web qui exécute l'application. Pour en savoir plus, consultez la section Les applications JavaScript risquent-elles de ne plus fonctionner.

Pour les applications mobiles natives utilisant le SDK Maps pour Android, le SDK Maps pour iOS, le SDK Places pour Android ou le SDK Places pour iOS, les mêmes règles s'appliquent que pour les applications qui appellent les services Web Google Maps Platform.

Pour en savoir plus, consultez la section Les applications mobiles risquent-elles de ne plus fonctionner.

L'application utilise son propre bundle de certificats ou des fonctionnalités de sécurité avancées telles que l'épinglage de certificats

Vous devez mettre vous-même à jour votre bundle de certificats. Comme expliqué dans la section Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance, nous vous recommandons d'importer tous les certificats du bundle de CA racine Google de confiance dans votre propre magasin de certificats racine.

Si vous épinglez des certificats ou des clés publiques pour les domaines Google auxquels votre application se connecte, vous devez les ajouter à la liste des entités de confiance de votre application.

Pour découvrir comment épingler les certificats ou les clés publiques, consultez les ressources externes présentées dans la section Vous avez besoin de plus d'informations.

Pourquoi synchroniser mon magasin de certificats racine avec le bundle de CA racine Google de confiance ?

Le bundle de CA racine Google de confiance comprend toutes les CA susceptibles d'être utilisées par les services Google à l'avenir.

Par conséquent, si vous souhaitez préparer votre système pour les futurs changements, nous vous recommandons vivement de vérifier que votre magasin de certificats racine contient tous les certificats du bundle et de prendre l'habitude de les synchroniser.

C'est particulièrement important si vos services s'exécutent sur une version du système d'exploitation non mise à jour, si vous ne pouvez pas appliquer les correctifs à votre système d'exploitation ni à vos bibliothèques pour une raison quelconque, ou si vous gérez votre propre magasin de certificats racine.

Pour découvrir comment être tenu au courant des migrations de CA racine à venir, reportez-vous à la section Comment recevoir un avis préalable pour les prochaines migrations. Synchronisez régulièrement votre magasin de certificats racine et la liste du bundle pour éviter que vos services soient interrompus en cas de changement de CA à l'avenir, et si GTS Root R1 Cross et GlobalSign Root CA - R1 expirent tous les deux.

Veuillez également consulter la section Je développe un produit qui se connecte aux services Google, quels certificats CA dois-je approuver dans les questions fréquentes sur GTS pour obtenir d'autres recommandations.

Pourquoi ne pas installer de certificats CA feuille ou intermédiaires ?

Votre application risquerait alors de ne plus fonctionner chaque fois que nous enregistrons un nouveau certificat ou que nous changeons de CA intermédiaire. Or, nous pouvons être amenés à le faire à tout moment et sans préavis. Cela s'applique aussi bien aux certificats de serveur individuels, comme ceux fournis par maps.googleapis.com, qu'à n'importe laquelle de nos CA intermédiaires, comme GTS Root R1 Cross.

Pour que vos services continuent de fonctionner dans une telle situation, vous ne devez installer que les certificats racine du bundle de CA racine Google de confiance, et vous appuyer seulement sur le certificat racine pour vérifier la fiabilité de l'ensemble de la chaîne de certificats associée.

Toute intégration de bibliothèque TLS récente doit pouvoir approuver automatiquement ces chaînes de confiance dès lors que l'autorité de certification racine est fiable.

Les applications JavaScript risquent-elles de ne plus fonctionner ?

Les certificats racine GTS sont déjà bien intégrés et approuvés par la plupart des navigateurs récents. De plus, avec la signature croisée de GMO GlobalSign, la migration devrait bien se dérouler, même pour la plupart des utilisateurs finaux d'anciens navigateurs. Cela inclut tous les navigateurs officiellement compatibles avec l'API Maps JavaScript.

Dans tous les navigateurs récents, les utilisateurs finaux doivent pouvoir approuver les certificats. Généralement, ils peuvent également modifier les certificats approuvés par le navigateur. Bien que le chemin d'accès exact diffère selon le navigateur, la liste des certificats se trouve généralement dans les Paramètres.

Les applications mobiles risquent-elles de ne plus fonctionner ?

Les appareils Android et Apple iOS régulièrement mis à jour par leur fabricant sont généralement préparés aux changements futurs. La plupart des anciens modèles de téléphones Android incluent au moins le certificat GlobalSign Root CA - R1. Toutefois, la liste des certificats de confiance peut varier en fonction du fabricant, du modèle et de la version Android du combiné.

Toutefois, la prise en charge des CA racine GTS, y compris GTS Root R1, peut être limitée dans les versions antérieures à Android 10.

Pour les appareils iOS, Apple fournit une liste des CA racine de confiance pour chaque version récente d'iOS sur ses pages d'assistance. Cependant, toutes les versions à partir d'iOS 5 prennent en charge GlobalSign Root CA - R1.

Les CA racine GTS, y compris GTS Root R1, sont compatibles depuis la version iOS 12.1.3.

Consultez la section Comment vérifier les certificats racine de confiance sur mon téléphone mobile pour en savoir plus.

Quand mon navigateur ou mon système d'exploitation inclura-t-il les certificats racine Google Trust Services ?

Au cours des dernières années, Google a collaboré étroitement avec tous les principaux fournisseurs tiers pour proposer des bundles de certificats racine de confiance fréquemment utilisés. Voici quelques exemples : fabricants de systèmes d'exploitation (comme Apple et Microsoft, mais aussi les équipes Android et ChromeOS de Google), développeurs de navigateurs (comme Mozilla, Apple, Microsoft, mais aussi l'équipe Chrome de Google), fabricants de matériel (téléphones, boîtiers décodeurs, téléviseurs, consoles de jeu, imprimantes et plus encore).

Par conséquent, il est très probable que tous les systèmes mis à jour prennent déjà en charge les nouvelles CA racine GTS de Google, y compris GTS Root R1. Même les anciens systèmes devraient très vraisemblablement être compatibles avec GlobalSign Root CA - R1, qui sera utilisé pour la signature croisée des certificats émis par Google au cours des prochaines années.

Cependant, Google n'est pas responsable des délais d'inclusion des certificats tiers. Par conséquent, nous vous recommandons d'appliquer régulièrement les mises à jour du système disponibles.

Certains tiers, comme le programme de certificats CA de Mozilla, fournissent peut-être des renseignements sur leur calendrier d'inclusion des certificats.

Résoudre des problèmes

Où trouver les outils dont j'ai besoin ?

Obtenir curl

Si votre distribution de l'OS ne fournit pas l'outil curl, vous pouvez le télécharger ici : https://curl.haxx.se/. Vous pouvez soit télécharger la source, puis compiler l'outil vous-même, soit télécharger un fichier binaire précompilé, s'il en existe un pour votre plate-forme.

Obtenir OpenSSL

Si votre distribution de l'OS ne fournit pas l'outil openssl, vous pouvez télécharger la source depuis https://www.openssl.org/ et compiler l'outil. Vous trouverez la liste des builds de binaires de tiers ici : https://www.openssl.org/community/binaries.html. Toutefois, aucun de ces builds n'est pris en charge ni autrement approuvé par l'équipe OpenSSL.

Obtenir WireShark, TShark ou tcpdump

Bien que la plupart des distributions Linux incluent wireshark, son outil de ligne de commande tshark et tcpdump, des versions précompilées de Wireshark et de Tshark sont disponibles pour d'autres OS sur https://www.wireshark.org.

Le code source de tcpdump et de LibPCAP est disponible sur https://www.tcpdump.org.

La documentation de ces outils utiles se trouve dans le guide de l'utilisateur de Wireshark, sur la page de manuel de Tshark et sur la page de manuel de tcpdump, respectivement.

Obtenir Java keytool

L'outil de ligne de commande keytool doit être envoyé avec chaque version du kit de développement Java (JDK) ou de l'environnement d'exécution Java (JRE). Installez ces versions pour obtenir keytool.. Cependant, l'utilisation de keytool n'est probablement pas nécessaire pour valider le certificat racine, sauf si la création de votre application repose sur Java.

Que faire en cas de panne de production ?

Avant tout, installez les certificats racine requis du bundle de CA racine Google de confiance dans le magasin de certificats racine utilisé par votre application.

  1. Collaborez avec les administrateurs de votre système pour mettre à niveau votre magasin local de certificats racine.
  2. Consultez ces questions fréquentes afin d'y trouver des conseils applicables à votre système.
  3. Si vous avez encore besoin d'aide pour votre plate-forme ou votre système, utilisez les canaux d'assistance technique proposés par votre fournisseur.
  4. Pour obtenir une assistance générale, contactez notre équipe d'assistance, comme indiqué dans la section Contacter l'assistance Google Maps Platform. Remarque : Pour les problèmes spécifiques à une plate-forme, les conseils ne sont fournis qu'en fonction des données disponibles.
  5. Ajoutez le problème public 186840968 à vos favoris afin de recevoir d'autres informations sur la migration.

Contacter l'assistance Google Maps Platform

Premières étapes de dépannage

Consultez la section Comment vérifier si mon magasin de certificats racine doit être mis à jour pour résoudre les problèmes d'ordre général.

Si vous avez besoin d'importer ou d'exporter des certificats racine, vous trouverez également des informations précieuses dans la section Gérer vos certificats de confiance.

Si le problème n'est pas résolu et que vous décidez de contacter l'assistance Google Maps Platform, vous devrez également nous fournir les informations suivantes :

  1. Où se trouvent vos serveurs affectés ?
  2. Quelles adresses IP de Google votre service appelle-t-il ?
  3. Quelles sont les API concernées par ce problème ?
  4. À quel moment précis le problème a-t-il commencé ?

  5. Indiquez les résultats des commandes suivantes :

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Pour savoir comment obtenir les outils nécessaires, consultez la question Où trouver les outils dont j'ai besoin.

Envoyer une demande d'assistance

Suivez les instructions pour créer une demande d'assistance sous Assistance et ressources Google Maps Platform.

Lorsque vous envoyez une demande d'assistance, en plus des données listées dans la section Premières étapes de dépannage, veuillez également fournir les informations suivantes :

  • Quelles sont vos adresses IP publiques ?
  • Quelle est l'adresse IP publique de votre serveur DNS ?
  • Si possible, ajoutez une capture de paquets tcpdump ou Wireshark lorsque la négociation TLS avec https://maps.googleapis.com/ a échoué. Utilisez pour cela le format PCAP avec une longueur d'instantané suffisamment grande pour capturer l'intégralité du paquet sans le tronquer (par exemple, en utilisant -s0 sur les anciennes versions de tcpdump).
  • Si possible, joignez des extraits des journaux de votre service qui indiquent le motif exact de l'échec de la connexion TLS, de préférence avec des informations complètes sur la chaîne de certificats du serveur.

Pour savoir comment obtenir les outils nécessaires, consultez la question Où trouver les outils dont j'ai besoin.

Publier des contenus sur le problème public 186840968

Lorsque vous publiez un commentaire sur le problème public 186840968, veuillez inclure les informations listées dans la section Premières étapes de dépannage.

Comment déterminer l'adresse publique de mon DNS ?

Sous Linux, vous pouvez exécuter la commande suivante :

dig -t txt o-o.myaddr.l.google.com

Sous Windows, vous pouvez utiliser nslookup en mode interactif :

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Comment interpréter le résultat curl ?

L'exécution de curl avec les indicateurs -vvI fournit des informations très utiles. Voici quelques instructions pour interpréter le résultat :

  • Les lignes qui commencent par * affichent le résultat de la négociation TLS et des informations sur la fermeture de connexion.
  • Les lignes qui commencent par > affichent la requête HTTP sortante envoyée par curl.
  • Les lignes qui commencent par < affichent la réponse HTTP obtenue du serveur.
  • Si le protocole était HTTPS, les lignes > ou <, si elles sont présentes, indiquent que le handshake TLS s'est bien déroulé.

Bibliothèque TLS et bundle de certificats racine utilisés

curl avec les options -vvI renvoie également le magasin de certificats racine utilisé. Toutefois, le résultat exact peut varier selon le système, comme illustré ici.

Sur une machine Linux Red Hat, où curl a été lié à NSS, le résultat peut contenir les lignes suivantes :

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Sur une machine Linux Ubuntu ou Debian, le résultat peut contenir les lignes suivantes :

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

Sur une machine Linux Ubuntu ou Debian, avec le fichier PEM du certificat racine de Google fourni via l'indicateur --cacert, le résultat peut contenir les lignes suivantes :

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

User-agent

Les requêtes sortantes contiennent l'en-tête User-Agent qui peut fournir des informations utiles sur curl et votre système.

Exemple à partir d'une machine Linux Red Hat :

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Échec du handshake TLS

Des lignes telles que celles reprises dans cet exemple de code indiquent que la connexion a été fermée à mi-chemin du handshake TLS à cause d'un certificat de serveur non approuvé. L'absence de résultats de débogage qui commencent par > ou < est également un indicateur fort d'un échec de tentative de connexion :

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

Handshake TLS réussi

Un handshake TLS réussi est indiqué par la présence de lignes d'apparence semblables à celles de cet exemple de code. Vous devriez y trouver la suite de chiffrement utilisée pour la connexion ainsi que les détails du certificat de serveur accepté. De plus, la présence de lignes qui commencent par > ou < indique que le trafic HTTP de la charge utile est correctement transmis via la connexion chiffrée par TLS :

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

Comment afficher sous forme lisible par l'humain les certificats de serveur reçus ?

En partant du principe que le résultat est au format PEM (par exemple, celui d'openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null) vous pouvez afficher le certificat diffusé en procédant comme suit :

  • Copiez l'intégralité du certificat encodé au format Base64, y compris l'en-tête et le pied de page :

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • Ensuite, exécutez :

    openssl x509 -inform pem -noout -text
````

  • Collez le contenu de votre copie en mémoire tampon dans le terminal.

  • Appuyez sur la touche Entrée.

Pour obtenir des exemples d'entrées et de sorties, consultez la section Comment afficher sous forme lisible par l'humain des certificats PEM.

À quoi ressemblent les certificats Google avec signatures croisées dans OpenSSL ?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

Gérer vos certificats de confiance

Comment vérifier les certificats racines de confiance sur mon téléphone mobile ?

Certificats de confiance Android

Comme indiqué dans la section Les applications mobiles risquent-elles de ne plus fonctionner, depuis la version 4.0, Android permet aux utilisateurs de combinés de valider la liste des certificats de confiance dans les paramètres. Le tableau ci-dessous indique le chemin d'accès exact dans le menu Paramètres :

Version d'Android Chemin d'accès au menu
1.x, 2.x, 3.x N/A
4.x, 5.x, 6.x, 7.x Paramètres > Sécurité > Certificats de confiance
8.x, 9 Paramètres > Sécurité et localisation > Chiffrement et identifiants > Identifiants de confiance
10+ Paramètres > Sécurité > Paramètres avancés > Chiffrement et identifiants > Identifiants de confiance

Ce tableau illustre la disponibilité probable des certificats racine les plus critiques par version d'Android, sur la base d'une vérification manuelle effectuée à l'aide d'images système d'appareils virtuels Android actuellement disponibles. Pour les images système qui ne sont plus disponibles, ce tableau se base sur l'historique des versions du dépôt Git ca-certificates d'AOSP.

Version d'Android GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valide jusqu'au 15 décembre 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Il n'est généralement pas possible de mettre à jour le magasin de certificats racine du système Android sans mettre à jour le micrologiciel ou démarrer l'appareil en mode root. Toutefois, sur la plupart des versions d'Android encore très utilisées, l'ensemble actuel de certificats racine de confiance offrira probablement un service ininterrompu pendant plusieurs années, au-delà de la durée de vie effective de la plupart des appareils existants.

Depuis la version 7.0, Android propose aux développeurs d'applications une méthode sécurisée pour ajouter des certificats de confiance approuvés seulement par leur application. Elle consiste à ajouter les certificats dans le même bundle que l'application et à créer une configuration de sécurité réseau personnalisée, comme décrit dans le document de formation Configuration de la sécurité réseau dans les bonnes pratiques de sécurité et de confidentialité sur Android.

Toutefois, comme les développeurs d'applications tierces ne pourront pas contrôler la configuration de sécurité réseau du trafic provenant de l'APK des services Google Play, cette méthode ne fournira probablement qu'une solution de contournement partielle.

Sur les appareils plus anciens, votre seule option serait de vous fier à des CA ajoutées par l'utilisateur (soit au moyen d'une règle d'entreprise appliquée à l'appareil de l'utilisateur final, soit par les utilisateurs finaux eux-mêmes).

Magasin de confiance iOS

Bien qu'Apple ne montre pas directement à l'utilisateur du combiné son ensemble de certificats racine de confiance par défaut, des liens vers les ensembles de CA racine de confiance sont disponibles dans les articles de l'assistance Apple à partir d'iOS version 5 :

Toutefois, tous les certificats supplémentaires installés sur l'appareil iOS doivent être visibles sous Réglages > Général > Profil. Si aucun certificat supplémentaire n'est installé, l'élément de menu Profil risque de ne pas s'afficher.

Ce tableau illustre la disponibilité des certificats racine les plus critiques par version d'iOS, en fonction des sources ci-dessus :

Version d'iOS GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valide jusqu'au 15 décembre 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Où se trouve le magasin de certificats racine de mon système et comment le mettre à jour ?

L'emplacement du magasin de certificats racine par défaut varie en fonction du système d'exploitation et de la bibliothèque SSL/TLS utilisée. Toutefois, sur la plupart des distributions Linux, les certificats racine par défaut sont disponibles via l'un des chemins d'accès ci-dessous :

  • /usr/local/share/ca-certificates : Debian, Ubuntu, anciennes versions de RHEL et de CentOS
  • /etc/pki/ca-trust/source/anchors et /usr/share/pki/ca-trust-source : Fedora, versions récentes de RHEL et de CentOS
  • /var/lib/ca-certificates : openSUSE

Les certificats peuvent également être accessibles via les chemins suivants :

  • /etc/ssl/certs : Debian, Ubuntu
  • /etc/pki/tls/certs : RHEL, CentOS

Certains des certificats de ces répertoires sont probablement des liens symboliques vers des fichiers d'autres répertoires.

Magasin de certificats racine OpenSSL

Pour les applications qui utilisent OpenSSL, vous pouvez consulter l'emplacement configuré de ses composants installés, y compris le magasin de certificats racine par défaut, à l'aide de la commande suivante :

openssl version -d

La commande renvoie OPENSSLDIR, qui correspond au répertoire de premier niveau où se trouvent la bibliothèque et ses configurations :

OPENSSLDIR: "/usr/lib/ssl"

Le magasin de certificats racine se trouve dans le sous-répertoire certs.

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

Si OpenSSL repose sur le magasin de certificats racine par défaut du système comme dans l'exemple ci-dessus, consultez la première partie de la section Où se trouve le magasin de certificats racine de mon système et comment le mettre à jour pour vérifier que le bundle de certificats racine du système est à jour.

Pour savoir comment installer openssl, consultez la section Obtenir OpenSSL.

Magasin de certificats racine Java

Les applications Java utiliseront peut-être leur propre magasin de certificats racine. Dans les systèmes Linux, celui-ci se trouve généralement dans /etc/pki/java/cacerts ou /usr/share/ca-certificates-java, et il peut être géré avec l'outil de ligne de commande Java keytool.

Pour importer un certificat individuel dans votre magasin de certificats Java, exécutez la commande suivante :

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

Il vous suffit de remplacer cert.pem par le fichier de certificat correspondant à chaque certificat racine recommandé, alias par un alias de certificat unique, mais pertinent et certs.jks par le fichier de base de données de certificats utilisé dans votre environnement.

Pour en savoir plus, consultez les articles suivants sur Oracle et Stack Overflow :

Magasin de certificats racine Mozilla NSS

Les applications qui utilisent Mozilla NSS peuvent également utiliser par défaut une base de données de certificats à l'échelle du système, généralement située dans /etc/pki/nssdb, ou un magasin par défaut spécifique à l'utilisateur dans ${HOME}/.pki/nssdb.

Pour mettre à jour votre base de données NSS, utilisez l'outil certutil.

Pour importer un fichier de certificat individuel dans votre base de données NSS, exécutez la commande suivante :

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

Il vous suffit de remplacer cert.pem par le fichier de certificat correspondant à chaque certificat racine recommandé, cert-name par un pseudo de certificat pertinent et certdir par le chemin d'accès de la base de données de certificats utilisée dans votre environnement.

Pour plus d'informations, reportez-vous au manuel officiel NSS Tools certutil ainsi qu'à la documentation de votre système d'exploitation.

Magasin de certificats racine Microsoft .NET

Pour mettre à jour leur magasin de certificats racine, les développeurs Windows .NET peuvent se référer entre autres aux articles Microsoft suivants :

Formats des fichiers de certificats

Définition d'un fichier PEM

Le fichier PEM (Privacy-Enhanced Mail) correspond à un format texte qui s'est imposé comme norme de facto pour stocker et envoyer des certificats, clés, etc. cryptographiques. Il a été formalisé en tant que norme de jure dans le RFC 7468.

Bien que le format de fichier en lui-même soit lisible par l'humain, les données de certificat binaires encodées au format Base64 ne le sont pas. Toutefois, la spécification PEM permet d'émettre un texte explicatif avant ou après le corps du certificat encodé au format texte. De plus, de nombreux outils utilisent cette fonctionnalité afin de fournir aussi un résumé des éléments de données les plus pertinents dans un certificat, en texte clair.

Des outils tels qu'openssl peuvent également servir à décoder le certificat entier en un format lisible par l'humain. Pour en savoir plus, consultez la section Comment afficher sous forme lisible par l'humain des certificats PEM.

Définition d'un fichier ".crt"

Les outils qui permettent d'exporter des certificats au format PEM utilisent souvent l'extension de fichier .crt pour indiquer que le fichier est encodé au format texte.

Définition d'un fichier DER

DER (Distinguished Encoding Rules) est un format binaire standardisé qui permet d'encoder les certificats. Les certificats des fichiers PEM sont généralement des certificats DER encodés en Base64.

Qu'est-ce qu'un fichier ".cer" ?

Un fichier exporté doté d'un suffixe ".cer" peut contenir un certificat encodé au format PEM. Toutefois, il s'agit plus généralement d'un certificat binaire, souvent encodé au format DER. Par convention, les fichiers .cer ne contiennent généralement qu'un seul certificat.

Mon système refuse d'importer tous les certificats à partir de roots.pem

Certains systèmes, tels que Java keytool, ne peuvent importer qu'un seul certificat à partir d'un fichier PEM, même s'il en contient plusieurs. Reportez-vous à la question Comment extraire des certificats individuels de roots.pem pour découvrir comment diviser le fichier au préalable.

Comment extraire des certificats individuels de root.pem ?

Vous pouvez diviser roots.pem pour extraire les certificats qui le composent à l'aide du script bash simple suivant :

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Un certain nombre de fichiers PEM individuels seront alors créés comme illustré ici :

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

Les fichiers PEM individuels tels que 02265526.pem peuvent ensuite être importés séparément ou convertis dans un format de fichier accepté par votre magasin de certificats.

Comment convertir un fichier PEM dans un format compatible avec mon système ?

L'outil de ligne de commande openssl de la boîte à outils OpenSSL peut être utilisé pour convertir des fichiers vers et depuis tous les formats couramment utilisés pour les fichiers de certificats. Vous trouverez ci-dessous les instructions pour convertir un fichier PEM aux formats de fichiers de certificats les plus couramment utilisés.

Pour obtenir la liste complète des options disponibles, consultez la documentation officielle des utilitaires de ligne de commande OpenSSL.

Pour savoir comment installer openssl, consultez la section Obtenir OpenSSL.

Comment convertir un fichier PEM en fichier DER ?

À l'aide d'openssl, vous pouvez exécuter la commande suivante afin de convertir un fichier PEM en fichier DER :

openssl x509 -in roots.pem -outform der -out roots.der
Comment convertir un fichier PEM en fichier PKCS #7 ?

À l'aide d'openssl, vous pouvez exécuter la commande suivante pour convertir un fichier PEM au format PKCS #7 :

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Comment convertir un fichier PEM en fichier PKCS #12 (PFX) ?

À l'aide d'openssl, vous pouvez exécuter la commande suivante pour convertir un fichier PEM au format PKCS #12 :

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

Lorsque vous créez une archive PKCS #12, vous devez fournir un mot de passe de fichier. Si vous n'importez pas immédiatement le fichier PKCS #12 dans votre système, assurez-vous de stocker le mot de passe en lieu sûr.

Lister, afficher et exporter des certificats depuis votre magasin de certificats racine

Comment exporter un certificat dans un fichier PEM depuis le keystore Java ?

À l'aide de keytool, vous pouvez exécuter la commande suivante pour lister tous les certificats de votre magasin de certificats, avec l'alias que vous pouvez utiliser pour exporter chacun d'eux :

keytool -v -list -keystore certs.jks

Remplacez simplement certs.jks par le fichier de base de données de certificats utilisé dans votre environnement. Cette commande affiche également l'alias de chaque certificat, dont vous aurez besoin si vous souhaitez l'exporter.

Pour exporter un certificat individuel au format PEM, exécutez la commande suivante :

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

Remplacez simplement certs.jks par le fichier de base de données de certificats utilisé dans votre environnement, et fournissez des éléments alias et alias.pem correspondant au certificat que vous voulez exporter.

Pour en savoir plus, consultez le manuel Java Platform, Standard Edition Tools Reference: keytool.

Comment exporter des certificats dans un fichier PEM depuis le magasin de certificats racine NSS ?

À l'aide de certutil, vous pouvez exécuter la commande suivante pour lister tous les certificats de votre magasin de certificats, avec le pseudo que vous pouvez utiliser pour exporter chacun d'eux :

certutil -L -d certdir

Remplacez simplement certdir par le chemin d'accès de la base de données de certificats utilisé dans votre environnement. Cette commande affiche également le pseudo de chaque certificat dont vous aurez besoin si vous souhaitez l'exporter.

Pour exporter un certificat individuel au format PEM, exécutez la commande suivante :

certutil -L -n cert-name -a -d certdir > cert.pem

Remplacez simplement certdir par le chemin d'accès de la base de données de certificats utilisé dans votre environnement, et fournissez des éléments cert-name et cert.pem correspondant au certificat que vous voulez exporter.

Pour plus d'informations, reportez-vous au manuel officiel NSS Tools certutil ainsi qu'à la documentation de votre système d'exploitation.

Comment afficher des certificats PEM sous forme lisible par l'humain ?

Dans les exemples suivants, nous partons du principe que vous disposez du fichier GTS_Root_R1.pem avec le contenu suivant :

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
Afficher des fichiers de certificat à l'aide d'OpenSSL

Le résultat de la commande

openssl x509 -in GTS_Root_R1.pem -text

devrait ressembler à ceci :

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

Pour savoir comment installer openssl, consultez la section Obtenir OpenSSL.

Afficher des certificats à l'aide de Java keytool

Le résultat de la commande

keytool -printcert -file GTS_Root_R1.pem

devrait ressembler à ceci :

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Pour savoir comment installer keytool, consultez la section Obtenir Java keytool.

Comment vérifier quels certificats sont installés dans mon magasin de certificats racine ?

Cela dépend du système d'exploitation et de la bibliothèque SSL/TLS. Toutefois, les outils qui permettent d'importer/exporter des certificats depuis/vers le magasin de certificats racine proposent généralement aussi une option pour lister les certificats installés.

De plus, si vous avez correctement exporté les certificats racine de confiance dans des fichiers PEM ou que votre magasin de certificats racine stocke déjà de tels fichiers, vous pouvez essayer de les ouvrir dans n'importe quel éditeur de texte, car il s'agit d'un format en texte brut.

Le fichier PEM peut être libellé correctement et fournir des informations lisibles par l'humain de l'autorité de certification associée (exemple du bundle de CA racine Google de confiance) :

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

Le fichier peut également simplement contenir la partie certificat. Dans de tels cas, le nom du fichier (par exemple, GTS_Root_R1.pem) peut décrire la CA à laquelle le certificat appartient. La chaîne de certificat entre les jetons -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- sera également unique pour chaque CA.

Toutefois, même si vous n'avez pas accès aux outils ci-dessus, étant donné que chaque certificat du bundle de CA racine Google de confiance est correctement libellé, vous pouvez faire correspondre les CA racine du bundle à ceux de votre magasin de certificats racine soit par Issuer, soit en comparant les chaînes de certificats des fichiers PEM.

Les navigateurs Web peuvent utiliser leur propre magasin de certificats racine ou utiliser celui fourni par défaut par le système d'exploitation. Toutefois, tous les navigateurs récents devraient vous permettre de gérer, ou au moins de consulter, l'ensemble des CA racine qu'ils ont approuvées. Pour en savoir plus, consultez la section Les applications JavaScript risquent-elles de ne plus fonctionner.

Pour obtenir des instructions spécifiques aux téléphones mobiles, consultez la section dédiée Comment vérifier les certificats racine de confiance sur mon téléphone mobile.

Annexe

Vous avez besoin de plus d'informations ?

Fiez-vous toujours en priorité à la documentation de votre système d'exploitation, et à celle des langages de programmation et de toutes les bibliothèques externes utilisés par votre application.

Les informations d'autres sources (y compris ces questions fréquentes) peuvent être obsolètes ou incorrectes, et ne font pas autorité. Cependant, vous trouverez peut-être des informations utiles dans de nombreuses communautés de questions-réponses sur Stack Exchange, ainsi que sur des sites tels qu'AdamW on Linux and more et le confirm blog, entre autres.

Veuillez également consulter les questions fréquentes sur Google Trust Services.

Pour plus d'informations sur des sujets avancés tels que l'épinglage de certificats, consultez Certificate and Public Key Pinning et Pinning Cheat Sheet sur le site Open Web Application Security Project (OWASP). Pour obtenir des instructions spécifiques à Android, reportez-vous au document de formation officiel sur la sécurité avec HTTPS et SSL, dans les bonnes pratiques de sécurité et de confidentialité sur Android. Pour en savoir plus sur l'épinglage de certificats et de clés publiques sur Android, reportez-vous à l'article de blog de Matthew Dolan Android Security: SSL Pinning.

Le document de formation Configuration de la sécurité réseau dans les bonnes pratiques de sécurité et de confidentialité sur Android et l'article de blog de JeroenHD Android 7 Nougat and certificate authorities fournissent d'autres informations sur la gestion des certificats de confiance supplémentaires sur Android.

Pour obtenir la liste complète des CA racine approuvées par AOSP, consultez le dépôt Git ca-certificates. Pour toutes les versions basées sur des systèmes Android dupliqués non officiels (LineageOS, par exemple), reportez-vous aux dépôts appropriés mis à disposition par le fournisseur de l'OS.