Questions fréquentes sur la migration des autorités de certification racine pour Google Maps Platform

Informations générales

Dépannage

Gérer vos certificats de confiance

Annexe

Informations générales

Quelle est la situation ?

Vue d'ensemble

Google élabore un plan pluriannuel afin d'émettre et d'utiliser ses propres certificats racines, les signatures cryptographiques à la base de la sécurité Internet TLS/SSL utilisée par HTTPS.

Actuellement, la sécurité TLS de Google Maps Platform est assurée par un certificat racine émis par GeoTrust Global CA, une autorité de certification très connue et fiable appartenant à Symantec. Presque tous les clients TLS (tels que les navigateurs Web, les smartphones et les serveurs d'applications) connaissent ce certificat racine et peuvent l'utiliser afin de disposer d'une connexion sécurisée aux serveurs Google Maps Platform.

D'ici le début des années 2020, Google prévoit de migrer tous les services Google Maps Platform vers un certificat racine délivré par l'autorité de certification de Google, Google Trust Services (GTS).

Des mesures provisoires avaient été prises pour Google Maps Platform début 2018, avec la migration vers un autre certificat racine de confiance de GlobalSign (GS). Google a acheté le droit d'utilisation de ce certificat racine (et de l'autorité de certification utilisée par GlobalSign pour l'émettre) afin de faciliter la transition entre les certificats.

Dans la grande majorité des cas, les clients TLS reconnaissent déjà le certificat racine GlobalSign. Par conséquent, leur utilisation de Google Maps Platform ne sera pas affectée par cette modification initiale.

Toutefois, et en particulier dans certains cas d'utilisation spécialisés (les appareils embarqués, par exemple), ou lorsque des utilisateurs travaillent sur des navigateurs ou des systèmes d'exploitation très obsolètes, il est possible que certains clients ne disposent pas du certificat racine GlobalSign. Ces clients devront l'obtenir afin de pouvoir sécuriser leurs connexions à Google Maps Platform. Google ne peut pas identifier ces clients. Les propriétaires d'applications doivent donc effectuer toute validation nécessaire sur leurs propres applications. Pour vous aider, Google Trust Services fournit des points de terminaison de test HTTPS sur le site GTS. Pour plus d'informations techniques, consultez la section ci-dessous.

La plupart des systèmes connaîtront une procédure similaire au début de la migration vers les certificats racines GTS. Toutefois, si vous suivez les recommandations de ce document, la migration devrait généralement se faire de façon fluide, même pour les systèmes spécialisés.

Récapitulatif technique

Comme annoncé sur le portail du service client du forfait Premium de Google Maps Platform le 16 mars 2017, et précédemment dans le blog sur la sécurité de Google, Google a créé GTS, sa propre autorité de certification racine. En plus d'autres services Google, Google Maps Platform passera progressivement aux certificats TLS signés par les autorités de certification racine GTS.

En attendant, Google a acheté l'autorité de certification racine GS Root R2 existante. Celle-ci est très fiable. Google Maps Platform a commencé la migration du certificat racine GeoTrust vers ce nouveau certificat fin 2017, et la migration s'est ainsi achevée début 2018.

La quasi-totalité des clients TLS sont préconfigurés avec le certificat GS Root R2 ou le reçoivent par le biais de mises à jour logicielles standards. Toutefois, si une application se connecte à Google Maps Platform à partir de clients qui ne reconnaissent peut-être pas ce certificat, les développeurs d'applications doivent s'assurer que les clients sont testés et, au besoin, le reçoivent.

Le certificat GS Root R2 et tous les certificats racines GTS sont disponibles sur le site GTS. À des fins de test, le site GTS fournit également des points de terminaison comportant des certificats TLS signés par chaque autorité de certification. En particulier, si votre client peut établir une connexion TLS au point de terminaison du test GS Root R2, cela signifie alors qu'il fait confiance au certificat GS Root R2 et ne devrait pas être affecté par la modification à venir.

Google s'appuiera sur l'autorité de certification GS Root R2 au moins jusqu'à fin 2018. Après cette date, Google Maps Platform pourra utiliser directement l'autorité de certification GTS ou, occasionnellement, avoir recours à des autorités de certification racine tierces, y compris GS Root R3.

Comment recevoir des informations sur la migration ?

Ajoutez le problème public 67842936 à vos favoris afin de recevoir des informations. Ces questions fréquentes sont également mises à jour tout au long de la migration, chaque fois que nous rencontrons des sujets d'intérêt général.

Nous utilisons plusieurs services Google. Tous sont-ils concernés par la migration des autorités de certification racine ?

Oui. La migration des autorités de certification racine s'effectuera sur tous les services et API Google, mais la chronologie peut varier d'un service à l'autre. Toutefois, une fois que vous aurez vérifié que votre application fait confiance au groupe recommandé de certificats racines répertoriés dans le fichier d'exemple au format PEM de Google, votre application doit être protégé de toute forme d'obsolescence pendant la migration des certificats racines, quel que soit le service ou l'API Google qu'elle peut appeler. Consultez la question Dois-je installer tous les certificats racines à partir du fichier d'exemple au format PEM de Google ? pour en savoir plus.

Comment vérifier si mon magasin de certificats requiert une mise à jour ?

Testez votre environnement d'application par rapport aux points de terminaison de test répertoriés en même temps que les autorités de certification racine sur le site GTS. Si vous parvenez à établir une connexion TLS avec le point de terminaison de test GS Root R2 et le bac à sable de test du certificat Google, vous n'aurez aucun problème au moins jusqu'à fin 2018.

Par conséquent, nous vous recommandons vivement d'installer dès à présent tous les certificats du fichier d'exemple au format PEM de Google afin de protéger votre système contre l'obsolescence, sauf si vous êtes certain de pouvoir toujours garantir un environnement de production entièrement à jour, dans lequel tous les correctifs sont appliqués.

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

L'outil de ligne de commande curl, disponible sur la plupart des plates-formes, offre de nombreuses options pour tester votre configuration. Pour obtenir des instructions sur l'obtention de curl, consultez la section Obtenir curl.

Tester votre magasin de certificats par défaut
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
Valider le groupe d'autorités de certification racine de Google
Téléchargez le fichier d'exemple au format PEM de Google, puis procédez comme suit :
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

Comment se déroulera la migration ?

Quel sera le calendrier de la migration ?

La première phase de migration, à savoir passer aux certificats émis par des autorités de certification intermédiaires dont l'ancre de confiance est GS Root R2, a commencé fin 2017 et s'est achevée au cours du premier semestre de 2018.

Le calendrier des prochaines phases de migration sera annoncé dans les années à venir, mais bien avant l'expiration du certificat GS Root R2 en 2021.

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

  • Le déploiement par étapes commence dans un seul centre de données.
  • Le déploiement est progressivement étendu à d'autres centres de données jusqu'à ce qu'il existe une couverture mondiale.
  • Si des problèmes graves sont détectés à un moment donné, les tests peuvent faire l'objet d'un rollback temporaire tant que ces problèmes n'ont pas été résolus.
  • 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 au fur et à mesure du passage aux nouveaux centres de données. Ces modifications bénéficieront d'une certaine localisation, 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 garantir avec certitude et à l'avance qui sera concerné, quand, ni où, nous recommandons à tous nos clients de vérifier sans attendre que leurs systèmes sont protégés contre l'obsolescence, bien avant les prochaines phases de migration des autorités de certification racine de Google.

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 ?

Reportez-vous à la section Quelles sont les exigences minimales recommandées pour qu'un client TLS (Transport Layer Security) puisse communiquer avec Google ? dans les Questions fréquentes concernant GTS.

Google Maps Platform n'impose aucune exigence supplémentaire.

Quels types d'applications risquent de ne plus fonctionner ?

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

Applications de service Web Google Maps Platform

Si vous utilisez un système d'exploitation standard (par exemple, Ubuntu, Red Hat, Windows 7+ ou Server 2008+, OS X), encore en cours d'exploitation et bénéficiant de mises à jour régulières, votre magasin de certificats par défaut doit déjà inclure le certificat GS Root R2.

Si vous utilisez une ancienne version de l'OS qui ne reçoit plus de mises à jour, ce certificat n'est pas forcément présent. Par exemple, Windows XP SP2 inclut le certificat, mais ce n'est pas le cas de Windows XP SP1. Les anciens appareils doivent être testés afin de vérifier qu'ils font confiance au certificat.

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

Applications Google Maps Platform côté client

Les applications de l'API JavaScript pour Google Maps s'appuient généralement sur les certificats racines du navigateur Web qui exécute l'application. Consultez la section Les applications de l'API JavaScript pour Google Maps risquent-elles de ne plus fonctionner ? pour en savoir plus.

Pour les applications mobiles natives (Android et iOS) qui utilisent le SDK Google Maps ou Places, les mêmes règles s'appliquent aux applications qui appellent les services Web Google Maps Platform.

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

L'application utilise son propre groupe 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 groupe de certificats. Comme indiqué à la question Dois-je installer tous les certificats racines à partir du fichier d'exemple au format PEM de Google ?, nous vous recommandons d'importer tous les certificats racines du fichier d'exemple au format PEM de Google dans votre magasin de certificats.

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.

Consultez les documents externes répertoriés à la question Vous avez besoin de plus d'informations ? pour découvrir comment épingler les certificats ou les clés publiques.

Dois-je installer tous les certificats racines à partir du fichier d'exemple au format PEM de Google ?

Si vous souhaitez protéger votre système contre l'obsolescence, dès à présent et en une seule opération, nous vous recommandons d'installer tous les certificats à partir du fichier d'exemple au format PEM de Google. Cela est particulièrement nécessaire si vous n'effectuez pas régulièrement la mise à jour de votre système d'exploitation ou, par exemple, que vous gérez votre propre groupe de certificats pour votre application.

Pourquoi ne pas installer de certificats racines CA intermédiaires ?

Vous ne devez installer les certificats racines qu'à partir du fichier d'exemple au format PEM de Google. De plus, vous devez utiliser le certificat racine afin de valider l'authenticité de toute la chaîne de certificats ayant ce certificat comme ancre de confiance. Cela s'applique également aux certificats de serveur individuels (tels que ceux diffusés par l'hôte maps.googleapis.com) ainsi qu'à nos autorités de certification intermédiaires (GIAG3, GTS CA 1O1 ou GIAG4, par exemple).

Toute intégration de bibliothèque TLS entièrement mise à jour doit pouvoir valider automatiquement ces chaînes de confiance, à condition que l'autorité de certification racine soit digne de confiance.

Les applications de l'API JavaScript pour Google Maps risquent-elles de ne plus fonctionner ?

L'autorité de certification racine GlobalSign R2 est bien intégrée et est approuvée par la plupart des navigateurs récents. Par conséquent, ces navigateurs pourront probablement continuer à se connecter aux services Google pendant un certain temps. De plus, si le navigateur est géré de façon active, il sera presque certainement compatible avec toutes les autres autorités de certification racine de Google, à un moment donné.

Toutefois, l'API JavaScript pour Google Maps n'est sûre de fonctionner qu'au niveau des navigateurs compatibles. Nous vous recommandons donc d'utiliser l'un des navigateurs répertoriés et de maintenir votre navigateur à jour pour éviter tout problème.

Les applications mobiles risquent-elles de ne plus fonctionner ?

Les appareils Android et Apple qui continuent à recevoir des mises à jour régulières de leur fabricant sont généralement protégés contre l'obsolescence. La plupart des modèles de téléphones Android plus anciens incluent au moins les certificats GS Root R2 et GS Root R3. Toutefois la liste des certificats de confiance peut varier en fonction du fabricant, du modèle d'appareil et de la version Android. Les versions plus récentes du projet Android Open Source (AOSP) utilisées sur les appareils Google Nexus et Pixel font également confiance à GS Root R4 par défaut. Toutes les versions Android récentes n'offrent encore qu'une compatibilité minime avec les autorités de certification racine GTS.

Pour les appareils iOS, Apple propose cette liste pour chaque version récente d'iOS, sur ses pages d'assistance. Toutefois, toutes les versions iOS 5 et ultérieures sont compatibles avec GS Root R2 et R3. Les versions 7 et ultérieures acceptent également GS Root R4. Comme c'est le cas pour les versions actuelles d'Android, les autorités de certification racine GTS ne sont pas encore compatibles (au moment de la rédaction de cette documentation).

Consultez la section Comment vérifier les certificats racines 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 racines Google Trust Services ?

Google collabore avec tous les tiers principaux pour gérer des groupes de certificats racines de confiance fréquemment utilisés. Il peut s'agir, par exemple, des fabricants de système d'exploitation tels qu'Apple et Microsoft, mais aussi les équipes Android et ChromeOS de Google ; les développeurs de navigateurs tels que Mozilla, Apple, Microsoft, mais aussi l'équipe Chrome de Google ; les fabricants de matériel, entre autres téléphones, boîtiers décodeurs, téléviseurs, consoles de jeu, imprimantes, pour n'en citer que quelques-uns.

De façon générale, Google n'est pas responsable des délais d'inclusion des certificats tiers. Par conséquent, nous vous recommandons de bien appliquer régulièrement les mises à jour du système qui vous sont proposées. Certains tiers, par exemple le programme de certificats CA de Mozilla, ont peut-être fourni des documents sur leur propre calendrier d'inclusion des certificats.

Dépannage

Où trouver les outils dont j'ai besoin ?

Obtenir curl

Si votre distribution du système d'exploitation 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 accepté ni autrement approuvé par l'équipe OpenSSL.

Obtenir Wireshark et tcpdump

Bien que la plupart des distributions Linux proposent ces deux outils, les versions précompilées de wireshark pour d'autres systèmes d'exploitation sont disponibles à l'adresse https://www.wireshark.org. Le code source pour tcpdump et LibPCAP se trouve à l'adresse https://www.tcpdump.org.

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, commencez par installer les certificats racines requis issus du fichier d'exemple au format PEM de Google, dans le magasin de certificats de confiance utilisé par votre application. Toutefois, vous trouverez peut-être aussi des informations utiles dans la section Gérer vos certificats de confiance.
  1. Collaborez avec les administrateurs de votre système pour mettre à niveau votre magasin local de certificats.
  2. Consultez ces questions fréquentes afin d'y trouver des conseils applicables à votre système.
  3. Si vous avez encore besoin d'aide au niveau de votre plate-forme ou de votre système, contactez l'assistance technique proposée par votre fournisseur système.
  4. Pour obtenir une assistance générale, contactez notre équipe d'assistance, comme indiqué dans la section Contacter l'assistance Google Maps Platform.
  5. Ajoutez le problème public 67842936 à 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 question Comment vérifier si mon magasin de certificats requiert une mise à jour ? pour obtenir des instructions de dépannage génériques.

Si vous avez besoin d'importer ou d'exporter des certificats racines, 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. Résultats des commandes suivantes :
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
    

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

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 correctement la sortie curl et vérifier que les résultats sont fiables ?

L'exécution de curl avec les indicateurs -vvI fournit des informations très utiles. Voici quelques instructions pour interpréter la sortie curl :
  • Les lignes qui commencent par * affichent les résultats de la négociation TLS et les 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, la présence de lignes > ou < implique un handshake TLS réussi.
Bibliothèque TLS et groupe de certificats racines utilisés

L'exécution de curl avec les indicateurs -vvI imprime également les certificats du magasin utilisé. Toutefois, le résultat exact peut varier selon le système, comme illustré ci-dessous.

La sortie d'une machine Linux Red Hat, où curl a été lié à NSS, peut contenir les lignes suivantes :

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

La sortie d'une machine Linux Ubuntu ou Debian peut contenir les lignes suivantes :

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

La sortie d'une machine Linux Ubuntu ou Debian qui utilise le fichier PEM du certificat racine de Google fourni avec l'indicateur --cacert peut contenir les lignes suivantes :

* successfully set certificate verify locations:
* CAfile: /home/<username>/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 libssh2/1.4.2
> Host: cert-test.sandbox.google.com
> Accept: */*
>
Échec du handshake TLS
Des lignes telles que celles reprises ci-dessous indiquent que la connexion a été fermée à mi-handshake TLS à cause d'un certificat de serveur qui n'était pas de confiance. L'absence de sortie de débogage qui commence 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 ci-dessous. La suite de chiffrement utilisée pour la connexion chiffrée doit être indiquée, de même 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 :
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
Comment imprimer les certificats de serveur reçus sous forme lisible ?
En partant du principe que la sortie est au format PEM, par exemple la sortie de openssl s_client ... -showcerts, vous pouvez imprimer le certificat diffusé en procédant comme suit :
  1. 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-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. Collez le contenu de votre tampon de copie dans le terminal.
  4. Appuyez sur la touche Entrée.
Pour obtenir des exemples d'entrées et de sorties, consultez la section Comment imprimer des certificats au format PEM sous forme lisible ? ci-dessous.

À quoi ressemblent les certificats Google en OpenSSL ?

Nouveau certificat ayant l'autorité de certification racine GlobalSign - R2 comme ancre de confiance

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

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é à la question Les applications mobiles risquent-elles de ne plus fonctionner, Android permet aux utilisateurs de téléphones de valider la liste des certificats de confiance dans les Paramètres, et ce depuis la version 4.0. Le tableau ci-dessous indique le chemin d'accès exact au 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 > Certificats de confiance
10 Paramètres > Sécurité > Paramètres avancés > Chiffrement et identifiants > Certificats de confiance

Le tableau ci-dessous illustre la disponibilité probable des certificats racines les plus critiques par version d'Android, basée sur une validation manuelle utilisant les images système AVD (appareil virtuel Android) actuellement disponibles, et ayant recours à l'historique des versions du dépôt Git de certificats CA d'AOSP chaque fois que les images système ne sont plus disponibles :

Version d'Android GS Root R2 GS Root R3 GS Root R4 GTS
2.3, 3.2, 4.x, 5.0
5.1, 6.x, 7.x, 8.x, 9
10

La mise à jour du magasin de certificats du système Android est généralement impossible sans mettre à jour le micrologiciel ou activer le mode root sur l'appareil. Toutefois, l'ensemble actuel de certificats racines de confiance sur la plupart des versions encore très couramment utilisées d'Android fournira certainement un service sans interruption pendant plusieurs années, au-delà de la durée de vie effective de la plupart des appareils existants.

À compter de la version 7.0, Android offre aux développeurs d'applications une méthode sécurisée permettant d'ajouter des certificats de confiance auxquels seul leur application fait confiance. Cela passe par un groupement des certificats avec l'application et par la création d'une configuration de sécurité réseau personnalisée, comme cela est décrit dans le document de formation Configuration de la sécurité réseau dans les bonnes pratiques Android en matière de sécurité et de confidentialité.

Toutefois, comme les développeurs d'applications tierces ne seront pas en mesure d'influencer la configuration de sécurité réseau du trafic provenant du fichier APK pour les services Google Play, cette façon de procéder ne fournira probablement qu'une solution de contournement partielle.

Sur les appareils plus anciens, votre seule option possible serait de vous fier à des autorités de certification ajoutées par l'utilisateur, que ce soit celles ajoutées sur la base d'une règle d'entreprise appliquée à l'appareil de l'utilisateur final ou par les utilisateurs finaux eux-mêmes.

Magasin de confiance iOS

Bien qu'Apple n'affiche pas directement son ensemble de certificats racines par défaut à l'utilisateur du téléphone, l'entreprise peut accéder aux différentes autorités de certification racine approuvées pour iOS versions 5 et ultérieures, depuis les articles d'assistance Apple Listes des certificats racines de confiance disponibles dans iOS, et iOS 5 et iOS 6 : Liste des certificats racines de confiance disponibles.

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.

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

Version d'iOS GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11, 12.0
12.1.3+

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

L'emplacement du magasin de certificats 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 racines par défaut sont disponibles en suivant l'un des chemins d'accès ci-après : /usr/local/share/ca-certificates (Debian, Ubuntu, anciennes versions de RHEL et CentOS) ; /etc/pki/ca-trust/source/anchors et /usr/share/pki/ca-trust-source (Fedora, versions plus récentes de RHEL et CentOS) ou /var/lib/ca-certificates (OpenSUSE). D'autres chemins d'accès aux certificats peuvent inclure /etc/ssl/certs (Debian, Ubuntu) ou /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.

OpenSSL

Pour les applications qui utilisent OpenSSL, vous pouvez vérifier l'emplacement configuré de ses composants installés, y compris le magasin de certificats par défaut, à l'aide de la commande suivante :
openssl version -d
La commande imprime OPENSSLDIR, qui correspond au répertoire de premier niveau dans lequel la bibliothèque et ses configurations sont disponibles :
OPENSSLDIR: "/usr/lib/ssl"
Le magasin de certificats se trouve dans le sous-répertoire certs.
$ ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

Si OpenSSL fait confiance au magasin de certificats système par défaut comme dans l'exemple ci-dessus, vérifiez la section supérieure Où se trouve mon magasin de certificats système et comment puis-je le mettre à jour ? afin de vous assurer que le groupe de certificats racines du système est à jour.

Pour obtenir des instructions sur l'obtention de openssl, consultez la section Obtenir OpenSSL.

NSS Mozilla

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 dans un magasin par défaut spécifique à l'utilisateur dans ${HOME}/.pki/nssdb. Pour mettre à jour NSS, consultez la documentation sur l'outil certutil afin de découvrir comment ajouter des certificats, ainsi que la documentation officielle sur le système d'exploitation.

Microsoft .NET

Les développeurs .NET de Windows trouveront sans doute les articles Microsoft suivants utiles afin de mettre à jour leur magasin de certificats :

Java

Les applications Java utiliseront peut-être leur propre magasin de certificats. Dans les systèmes Linux, celui-ci se trouve généralement dans /etc/pki/java/cacerts ou /usr/share/ca-certificates-java. Pour vous aider à mettre à jour votre magasin de certificats Java à l'aide de l'outil de ligne de commande keytool d'Oracle, reportez-vous aux articles Stack Overflow et Oracle suivants :

Définition d'un fichier PEM

Le fichier PEM (Privacy-Enhanced Mail) correspond à un format texte standard de facto qui permet de stocker et d'envoyer des certificats et clés, etc. cryptographiques, formalisés en tant que norme de jure dans le document RFC 7468.

Bien que le format de fichier lui-même soit lisible pour l'utilisateur, 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 que openssl peuvent également servir à décoder le certificat entier en un format lisible. Consultez la section Comment imprimer des certificats au format PEM sous forme lisible ? pour en savoir plus.

Définition d'un fichier ".crt"

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

Définition d'un fichier DER

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

Définition d'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 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 acceptent uniquement d'importer des fichiers PEM qui contiennent un seul certificat. Reportez-vous à la question Comment extraire des certificats individuels de root.pem ? ci-dessous pour voir comment le fichier peut être divisé.

Comment extraire des certificats individuels de root.pem ?

Vous pouvez diviser roots.pem selon les certificats de ses composants, à 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}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
Un certain nombre de fichiers PEM individuels seront alors créés et seront semblables à ceux répertoriés ci-dessous :
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
Les fichiers PEM issuer=….pem peuvent ensuite être importés individuellement ou convertis dans un autre 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 entre tous les formats de fichiers de certificats couramment utilisés. 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 obtenir des instructions sur l'obtention de openssl, consultez la section Obtenir OpenSSL.

Comment convertir un fichier PEM en fichier DER ?

À l'aide de 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 de 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 de 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

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

Comment exporter des certificats au format PEM, depuis le magasin de certificats NSS ?

Consultez la documentation sur l'outil certutil de NSS Mozilla, ainsi que le document de discussion sur le site de la communauté Red Hat expliquant comment exporter un certificat depuis cert8.db au format .pem.

Comment imprimer des certificats au format PEM sous forme lisible ?

Dans les exemples suivants, nous partons du principe que vous disposez du fichier GlobalSign_Root_CA_-_R2.pem avec le contenu suivant :
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Imprimer des certificats avec OpenSSL

Exécuter la commande
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
doit renvoyer les lignes suivantes avant le certificat :
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

Pour obtenir des instructions sur l'obtention de openssl, consultez la section Obtenir OpenSSL.

Imprimer des certificats à l'aide de Java Keytool

Exécuter la commande suivante
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
doit fournir le résultat suivant :
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

Pour obtenir des instructions sur l'obtention de keytool, consultez la section Obtenir Java Keytool.

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

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 proposent généralement aussi une option pour répertorier les certificats installés.

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

Le fichier PEM peut être libellé correctement, fournissant des informations lisibles de l'autorité de certification associée (exemple issu du fichier d'exemple au format PEM de Google) :

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Le fichier peut également simplement contenir la partie certificat. Dans ce cas, le nom du fichier tel que GlobalSign_Root_CA_-_R2.pem peut décrire l'autorité de certification à laquelle le certificat appartient. La chaîne de certificat entre les jetons -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- sera unique pour chaque autorité de certification. Si vous ne pouvez pas identifier les autorités de certification autrement, vous pouvez comparer ces chaînes de manière fiable entre les fichiers PEM.

Ainsi, vous pouvez comparer chacun des certificats du fichier d'exemple au format PEM de Google par rapport aux fichiers PEM extraits de votre magasin de certificats. Étant donné que chaque certificat du groupe d'autorités de certification racine de Google est correctement libellé, vous pouvez vérifier de manière fiable ceux qui sont déjà dans votre magasin de certificats et identifier ceux qui doivent encore être ajoutés, même si les fichiers PEM de votre magasin de certificats n'étaient pas libellés.

Pour obtenir des instructions spécifiques aux téléphones mobiles, consultez la question spécifique Comment vérifier les certificats racines de confiance sur mon téléphone mobile.

Annexe

Vous avez besoin de plus d'informations ?

Fiez-vous toujours essentiellement à la documentation concernant votre système d'exploitation, celle sur les langages de programmation de votre application ainsi que celle provenant de toutes les bibliothèques externes utilisées 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 GTS, ainsi que l'article Comment utiliser les certificats X.509 et la technologie SSL pour les communications sécurisées.

Pour en savoir plus sur des thèmes avancés tels que l'épinglage de certificats, vous trouverez sans doute utile de lire l'article et l'aide-mémoire de l'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 Android en matière de sécurité et de confidentialité. Pour lire des informations comparatives 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 Android en matière de sécurité et de confidentialité, et l'article de blog de JeroenHD sur Android 7 Nougat et les autorités de certification fournissent d'autres informations sur comment gérer les certificats de confiance supplémentaires sur Android.

Pour obtenir la liste complète des autorités de certification racine approuvées par AOSP, consultez le dépôt Git de certificats CA. Pour toutes les versions basées sur des versions alternatives non officielles d'Android (LineageOS, par exemple), reportez-vous aux dépôts appropriés mis à disposition par le fournisseur du système d'exploitation.