FAQ zur Migration der Root-Zertifizierungsstelle für die Google Maps Platform

Allgemeine Informationen

Fehlerbehebung

Vertrauenswürdige Zertifikate verwalten

Anhang

Allgemeine Informationen

Was genau ist geplant?

Allgemeiner Überblick

Google ist dabei, einen mehrjährigen Plan umzusetzen. Es sollen eigene Root-Zertifikate ausgestellt und genutzt werden. Root-Zertifikate sind kryptografische Signaturen, die der TLS-/SSL-Technologie zur Absicherung von HTTPS-Verbindungen zugrunde liegen.

Die TLS der Google Maps Platform wird derzeit über ein Root-Zertifikat von GeoTrust Global CA abgesichert, einer renommierten Zertifizierungsstelle, die zu Symantec gehört. Praktisch alle TLS-Clients, darunter Webbrowser, Smartphones und Anwendungsserver, erkennen dieses Root-Zertifikat und können damit eine sichere Verbindung zu den Servern der Google Maps Platform herstellen.

Bis Anfang 2020 will Google alle Google Maps Platform-Dienste zu einem Root-Zertifikat migrieren, das von Google Trust Services (GTS), der eigenen Zertifizierungsstelle von Google, ausgestellt wird.

Als Zwischenschritt wurde die Google Maps Platform Anfang 2018 zu einem anderen vertrauenswürdigen Root-Zertifikat von GlobalSign (GS) migriert. Google zahlt für die Nutzung dieses Root-Zertifikats und der Zertifizierungsstelle, die GlobalSign verwendet, um es auszustellen. So soll die Umstellung auf die eigene Zertifizierungsstelle vereinfacht werden.

Die meisten TLS-Clients erkennen das Root-Zertifikat von GlobalSign bereits. Die vorläufige Änderung wird daher keine Auswirkungen auf ihre Nutzung der Google Maps Platform haben.

Bei einigen besonderen Anwendungsfällen, z. B. bei eingebetteten Geräten oder Nutzern, die stark veraltete Browser oder Betriebssysteme verwenden, kann es sein, dass Clients das Root-Zertifikat von GlobalSign fehlt. Für diese Clients ist eine Aktualisierung auf das Zertifikat erforderlich, damit ihre Verbindungen zur Google Maps Platform abgesichert werden können. Die Entwickler der jeweiligen Anwendungen müssen selbst herausfinden, ob eine solche Aktualisierung erforderlich ist. Google kann das nicht für sie tun. Auf der Website von Google Trust Services sind HTTPS-Testendpunkte verfügbar, um Entwickler bei diesem Schritt zu unterstützen. Weitere technische Details finden Sie unten.

Sobald die Migration zu den Root-Zertifikaten von GTS beginnt, sind für die meisten Systeme wahrscheinlich dieselben Schritte erforderlich. Wenn die Empfehlungen in diesem Dokument befolgt werden, sollten sich aber selbst komplexe Systeme problemlos migrieren lassen.

Technische Übersicht

Am 16. März 2017 wurde im Supportportal für Google Maps Platform-Kunden mit der Premiumoption bereits angekündigt, dass Google an einer eigenen Root-Zertifizierungsstelle, GTS, arbeitet. Auch im Google Security Blog wurde darüber berichtet. Neben anderen Google-Diensten wird auch die Google Maps Platform schrittweise auf TLS-Zertifikate umgestellt, die von GTS-Root-Zertifizierungsstellen signiert sind.

Als Zwischenschritt hat Google das angesehene Root-Zertifikat von GlobalSign „GS Root R2“ gekauft. Die Migration der Google Maps Platform vom Root-Zertifikat von GeoTrust zu diesem Zertifikat begann Ende 2017. Sie wurde Anfang 2018 abgeschlossen.

Fast alle TLS-Clients sind mit dem Zertifikat „GS Root R2“ vorkonfiguriert oder erhalten es über reguläre Software-Updates. Wenn Anwendungen Verbindungen zur Google Maps Platform über Clients herstellen, die das Zertifikat nicht erkennen, müssen Anwendungsentwickler dafür sorgen, dass die Clients getestet und bei Bedarf mit dem Zertifikat aktualisiert werden.

Das Zertifikat „GlobalSign Root CA – R2“ und sämtliche GTS-Root-Zertifikate sind auf der GTS-Website verfügbar. Für Testzwecke finden Sie auf der GTS-Website auch Endpunkte mit TLS-Zertifikaten, die von jeder Zertifizierungsstelle signiert sind. Wenn Ihr Client eine TLS-Verbindung zum GS Root R2-Testendpunkt herstellen kann, stuft er das Zertifikat „GS Root R2“ als vertrauenswürdig ein und ist von der nächsten Änderung nicht betroffen.

Google wird „GS Root R2“ mindestens bis Ende 2018 nutzen. Danach ist geplant, die Google Maps Platform direkt zu GTS zu migrieren. Unter Umständen wird aber auch gelegentlich wieder auf Root-Zertifikate von Drittanbietern wie GS Root R3 zugegriffen.

Wie erhalte ich aktuelle Informationen über diesen Migrationsprozess?

Markieren Sie das öffentliche Problem 67842936, um Benachrichtigungen zu erhalten. Wenn wir während des Migrationsprozesses auf Themen stoßen, die von allgemeinem Interesse sind, werden auch die vorliegenden FAQ entsprechend aktualisiert.

Wir nutzen mehrere Google-Dienste. Wirkt sich die Migration der Root-Zertifizierungsstelle auf alle aus?

Ja, die Root-Zertifizierungsstelle wird für alle Google-Dienste und -APIs migriert. Das kann je nach Dienst aber zu unterschiedlichen Zeiten passieren. Nachdem Sie dafür gesorgt haben, dass Ihre Anwendung den empfohlenen Root-Zertifikaten in der PEM-Beispieldatei von Google vertraut, sollten Sie während der Migration nichts weiter tun müssen, unabhängig davon, welche Google-APIs oder -Dienste aufgerufen werden. Weitere Informationen finden Sie unter Soll ich alle Root-Zertifikate aus der PEM-Beispieldatei von Google installieren?.

Wie finde ich heraus, ob mein Zertifikatspeicher aktualisiert werden muss?

Testen Sie Ihre Anwendungsumgebung mit den Testendpunkten, die auf der GTS-Website zusammen mit den Root-Zertifizierungsstellen aufgeführt werden. Wenn Sie eine TLS-Verbindung zum GS Root R2-Testendpunkt und zur Sandbox für Zertifikattests von Google herstellen können, müssen Sie bis mindestens Ende 2018 nichts weiter tun.

Um Ihr System zukunftssicher zu machen, raten wir daher dringend dazu, alle Zertifikate aus der PEM-Beispieldatei von Google zu installieren. Sie sollten nur auf diesen Schritt verzichten, wenn Sie absolut sicher sind, dass Ihr System immer auf dem neuesten Stand sein wird und sämtliche Patches unverzüglich eingespielt werden.

Gibt es ein einfaches Tool, mit dem ich meinen Zertifikatspeicher prüfen kann?

Das Befehlszeilentool curl, das auf den meisten Plattformen verfügbar ist, bietet umfangreiche Optionen zum Testen Ihrer Einrichtung. Eine Anleitung zum Abrufen von curl finden Sie unter curl herunterladen.

Standardzertifikatspeicher testen
# 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
Root-CA-Paket von Google verifizieren
Laden Sie die PEM-Beispieldatei von Google herunter und führen Sie die folgenden Schritte aus:
# 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

Wie läuft die Migration ab?

Wann findet die Migration statt?

Die erste Migrationsphase begann Ende 2017 und wurde in der ersten Hälfte des Jahres 2018 abgeschlossen. Dabei wurde auf Zertifikate von Zwischen-CAs umgestellt, die auf „GS Root R2“ basieren.

Der Termine zukünftiger Migrationsphasen werden in den nächsten Jahren bekannt gegeben (rechtzeitig vor Ablauf des Zertifikats „GS Root R2“ im Jahr 2021).

Allgemeine Einführung für die einzelnen Google-Dienste

  • Der gestaffelte Rollout beginnt in einem einzelnen Rechenzentrum.
  • Er wird dann nach und nach auf alle Rechenzentren ausgeweitet.
  • Wenn schwerwiegende Probleme auftreten, kann ein Rollback durchgeführt werden, bis die Probleme behoben sind.
  • Unter Berücksichtigung der Erfahrungen aus früheren Iterationen werden weitere Google-Dienste einbezogen, bis alle zu den neuen Zertifikaten migriert wurden.

Wer ist wann und wo betroffen?

Da immer mehr Rechenzentren migriert werden, erhalten auch immer mehr Google Maps Platform-Entwickler die neuen Zertifikate. Die Änderungen laufen eher dezentralisiert ab, weil Clientanfragen in der Regel an Server in Rechenzentren in der Nähe weitergeleitet werden. Wir können nicht mit Sicherheit vorhersagen, wer, wann und wo betroffen sein wird. Daher empfehlen wir allen unseren Kunden schon lange vor den nächsten Phasen der Migration der Root-Zertifizierungsstelle dafür zu sorgen, dass ihre Systeme zukunftssicher sind.

Wichtige Hinweise

Clients, die nicht mit dem erforderlichen Root-Zertifikat konfiguriert sind, können ihre TLS-Verbindung zur Google Maps Platform nicht verifizieren. Sie geben dann in der Regel eine Warnung aus, dass die Zertifikatsvalidierung fehlgeschlagen ist. Je nach ihrer TLS-Konfiguration senden Clients trotzdem Anfragen an die Google Maps Platform. Eventuell wird der Vorgang aber auch abgebrochen.

Welche Mindestanforderungen muss ein TLS-Client für die Kommunikation mit der Google Maps Platform erfüllen?

Weitere Informationen finden Sie auf der Seite GTS FAQ unter What are the recommended minimum requirements for a Transport Layer Security (TLS) client to communicate with Google? (Welche Mindestanforderungen sollte ein Transport Layer Security-Client [TLS-Client] für die Kommunikation mit Google erfüllen?).

Für die Google Maps Platform gelten keine zusätzlichen Anforderungen.

Bei welchen Arten von Anwendungen können Probleme auftreten?

Die Anwendung nutzt den Zertifikatspeicher des Systems ohne vom Entwickler festgelegte Einschränkungen

Google Maps Platform-Webdienstanwendungen

Wenn Sie ein gängiges Betriebssystem verwenden (z. B. Ubuntu, Red Hat, Windows 7+, Windows Server 2008+ oder OS X), das noch unterstützt und regelmäßig aktualisiert wird, sollte Ihr standardmäßiger Zertifikatspeicher bereits das Zertifikat „GS Root R2“ enthalten.

Falls Sie eine veraltete Betriebssystemversion verwenden, für die keine Updates mehr bereitgestellt werden, ist „GS Root R2“ unter Umständen nicht enthalten. Bei Windows XP SP2 ist das Zertifikat z. B. enthalten, bei Windows XP SP1 aber nicht. Bei Legacy-Geräten muss getestet werden, ob sie dem Zertifikat vertrauen.

Für mobile Apps, die Google Maps Platform-Webdienste direkt vom Endnutzergerät aus aufrufen, gelten die Richtlinien unter Können Probleme mit mobile Apps auftreten?.

Clientseitige Google Maps Platform-Anwendungen

Google Maps JavaScript API-Anwendungen nutzen in der Regel die Root-Zertifikate des Browsers, in dem sie ausgeführt werden. Weitere Informationen finden Sie unter Können Probleme bei Google Maps JavaScript API-Anwendungen auftreten?.

Für native mobile Apps auf Android- und iOS-Geräten, für die das Google Maps oder Places SDK verwendet wird, gelten die gleichen Regeln wie für Apps, die die Google Maps Platform-Webdienste aufrufen.

Weitere Informationen finden Sie unter Können Probleme bei mobilen Apps auftreten?.

Für die Anwendung werden ein eigenes Zertifikatpaket oder erweiterte Sicherheitsfunktionen verwendet, z. B. „Certificate Pinning“

Sie müssen Ihr Zertifikatpaket selbst aktualisieren. Wie unter Soll ich alle Root-Zertifikate aus der PEM-Beispieldatei von Google installieren? bereits erwähnt, empfehlen wir, sämtliche Root-Zertifikate aus der PEM-Beispieldatei von Google in Ihren Zertifikatspeicher zu importieren.

Wenn Sie Zertifikate oder öffentliche Schlüssel für die Google-Domains anpinnen, mit denen Ihre Anwendung eine Verbindung herstellt, sollten Sie die entsprechenden Zertifikate und Schlüssel in die Liste der vertrauenswürdigen Entitäten in Ihrer Anwendung aufnehmen.

Weitere Informationen zu „Certificate Pinning“ oder „Public Key Pinning“ finden Sie in den externen Ressourcen, die unter Weitere Informationen aufgeführt sind.

Soll ich alle Root-Zertifikate aus der PEM-Beispieldatei von Google installieren?

Wenn Sie Ihr System gleich komplett zukunftssicher machen möchten, sollten Sie alle Zertifikate aus der PEM-Beispieldatei von Google installieren. Das gilt besonders dann, wenn Sie Betriebssystemupdates nicht regelmäßig für Ihr System einspielen oder wenn Sie eigene Zertifikatpakete für Ihre Anwendung verwenden.

Warum sollte ich keine Zwischenzertifikate von Zertifizierungsstellen installieren?

Sie sollten nur die Root-Zertifikate aus der PEM-Beispieldatei von Google installieren und das Root-Zertifikat verwenden, um die Authentizität der gesamten Zertifikatskette zu validieren. Das gilt gleichermaßen für einzelne Serverzertifikate wie Zertifikate, die durch den Host „maps.googleapis.com“ bereitgestellt werden, sowie für alle Zwischen-CAs (z. B. GIAG3, GTS CA 1O1 oder GIAG4).

Jede zeitgemäße Implementierung einer TLS-Bibliothek sollte vertrauenswürdige Zertifikatsketten automatisch validieren können, solange die Root-Zertifizierungsstelle vertrauenswürdig ist.

Können Probleme bei Google Maps JavaScript API-Anwendungen auftreten?

Das Zertifikat „GlobalSign Root CA – R2“ ist gut eingebettet und wird von den meisten modernen Browsern als vertrauenswürdig eingestuft. Daher werden diese Browser wahrscheinlich noch eine Zeit lang eine Verbindung zu den Google-Diensten herstellen können. Wird der Browser aktiv verwaltet, unterstützt er mit großer Sicherheit irgendwann auch alle anderen Root-Zertifizierungsstellen von Google.

Die Google Maps JavaScript API selbst funktioniert aber nur in unterstützten Browsern. Aus diesem Grund – und um Probleme zu vermeiden – sollten Sie einen der aufgeführten Browser verwenden und auf dem neuesten Stand halten.

Können Probleme bei mobilen Apps auftreten?

Android- und Apple-Geräte, für die weiterhin Updates vom Hersteller veröffentlicht werden, sollten zukunftssicher sein. Die meisten älteren Android-Smartphones vertrauen bereits mindestens den Zertifikaten „GS Root R2“ und „GS Root R3“, die Liste der vertrauenswürdigen Zertifikate kann aber je nach Hersteller, Gerätemodell und Android-Version variieren. Neuere Versionen des Open-Source-Projekts von Android (AOSP), die auf Nexus- und Pixel-Geräten von Google verwendet werden, vertrauen außerdem standardmäßig „GS Root R4“. Die GTS-Root-Zertifizierungsstellen werden in bestehenden Android-Versionen immer noch nur sehr begrenzt unterstützt.

Für die aktuellen iOS-Versionen stellt Apple eine Liste vertrauenswürdiger Root-Zertifizierungsstellen auf der Supportseite zur Verfügung. Auf iOS-Geräten ab Version 5 werden die Zertifikate „GS Root R2“ und „GS Root R3“ unterstützt, ab Version 7 auch „GS Root R4“. Wie bei den aktuellen Android-Versionen wurden die GTS-Root-Zertifizierungsstellen zum Zeitpunkt der Erstellung dieses Dokuments noch nicht unterstützt.

Weitere Informationen finden Sie im Abschnitt Wie kann ich die vertrauenswürdigen Root-Zertifikate auf meinem Smartphone einsehen?.

Wann werden die Root-Zertifikate von Google Trust Services für meinen Browser oder mein Betriebssystem implementiert?

Google arbeitet mit allen wichtigen Drittanbietern zusammen, die gängige, vertrauenswürdige Root-Zertifikatpakete pflegen. Dazu gehören u. a. Betriebssystemhersteller wie Apple und Microsoft, aber auch die internen Android- und Chrome OS-Teams von Google, Browserentwickler wie Mozilla, Apple, Microsoft und das Chrome-Team von Google sowie Hersteller von Hardware wie Smartphones, Set-Top-Boxen, Fernsehern, Spielekonsolen oder Druckern.

Google kann nicht steuern, ab wann die Zertifikate von Drittanbietern berücksichtigt werden. Daher sollten Sie regelmäßig die verfügbaren Systemupdates installieren. Ausgewählte Drittanbieter, wie das CA Certificate Program von Mozilla, haben möglicherweise eigene Zeitpläne für die Aufnahme der Zertifikate.

Fehlerbehebung

Wo finde ich die erforderlichen Tools?

curl herunterladen

Wenn curl in Ihrer OS-Distribution nicht enthalten ist, können Sie das Tool unter https://curl.haxx.se/ herunterladen. Dabei haben Sie die Möglichkeit, die Quelle herunterzuladen und das Tool selbst zu kompilieren oder ein vorkompiliertes Binärprogramm herunterzuladen, sofern eins für Ihre Plattform verfügbar ist.

OpenSSL herunterladen

Wenn openssl in Ihrer OS-Distribution nicht enthalten ist, können Sie die Quelle unter https://www.openssl.org/ herunterladen und das Tool kompilieren. Eine Liste der von Drittanbietern erstellten Binärprogramme finden Sie unter https://www.openssl.org/community/binaries.html. Beachten Sie bitte, dass diese Builds nicht vom OpenSSL-Team unterstützt oder in irgendeiner Weise empfohlen werden.

Wireshark und tcpdump herunterladen

Diese Tools sind in den meisten Linux-Distributionen enthalten. Vorkompilierte Versionen von wireshark für andere Betriebssysteme finden Sie unter https://www.wireshark.org. Der Quellcode für tcpdump und LibPCAP ist unter https://www.tcpdump.org verfügbar.

Java-Keytool herunterladen

Das Befehlszeilentool keytool sollte in jeder Version des Java Development Kits (JDK) oder der Java-Laufzeitumgebung (JRE) enthalten sein. Installieren Sie sie, um keytool. zu erhalten. Allerdings ist die Verwendung von keytool wahrscheinlich nicht erforderlich, um das Root-Zertifikat zu verifizieren, es sei denn, Ihre Anwendung wurde mit Java erstellt.

Vorgehensweise bei einem Produktionsausfall

Zuerst sollten Sie die erforderlichen Root-Zertifikate aus der PEM-Beispieldatei von Google im Zertifikatspeicher Ihrer Anwendung installieren. Danach können Sie sich zusätzlich den Abschnitt Vertrauenswürdige Zertifikate verwalten ansehen.
  1. Arbeiten Sie mit Ihren Systemadministratoren zusammen und aktualisieren Sie den lokalen Zertifikatspeicher.
  2. In diesen FAQ finden Sie Hinweise für Ihr System.
  3. Falls Sie weitere plattform- oder systemspezifische Hilfe benötigen, wenden Sie sich an den technischen Support Ihres Systemanbieters.
  4. Allgemeine Unterstützung erhalten Sie von unserem Supportteam (siehe Abschnitt Google Maps Platform-Support kontaktieren).
  5. Markieren Sie das öffentliche Problem 67842936, um Benachrichtigungen zur Migration zu erhalten.

Google Maps Platform-Support kontaktieren

Erste Schritte zur Fehlerbehebung

Unter Wie finde ich heraus, ob mein Zertifikatspeicher aktualisiert werden muss? finden Sie allgemeine Informationen zur Fehlerbehebung.

Falls Sie Zertifikate exportieren oder importieren müssen, sollten Sie sich auch den Abschnitt Vertrauenswürdige Zertifikate verwalten ansehen.

Wenn das Problem nicht behoben wurde und Sie sich an den Google Maps Platform-Support wenden möchten, sollten Sie Antworten auf folgende Fragen bereithalten:

  1. Wo befinden sich Ihre betroffenen Server?
  2. Welche Google-IP-Adressen ruft Ihr Dienst auf?
  3. Welche APIs sind von dem Problem betroffen?
  4. Wann genau ist das Problem zuerst aufgetreten?
  5. Was wird bei folgenden Befehlen ausgegeben?
    # 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
    

Unter Wo finde ich die erforderlichen Tools? können Sie nachlesen, wie Sie sich die nötigen Tools beschaffen.

Wie finde ich die öffentliche Adresse meines DNS heraus?

Unter Linux können Sie folgenden Befehl ausführen:
dig -t txt o-o.myaddr.l.google.com
Unter Windows können Sie das Tool „nslookup“ im interaktiven Modus verwenden:
C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Wie interpretiere ich die curl-Ausgabe richtig und sorge dafür, dass die Ergebnisse zuverlässig sind?

Wenn Sie curl mit den Flags -vvI ausführen, erhalten Sie viele nützliche Informationen. Hier finden Sie einige Hinweise zum Interpretieren der Ausgabe:
  • Zeilen, die mit * beginnen, enthalten das Ergebnis der TLS-Verhandlung sowie Informationen zum Verbindungsabbruch.
  • Zeilen, die mit > beginnen, enthalten die ausgehende HTTP-Anfrage an, die von curl gesendet wird.
  • Zeilen, die mit < beginnen, enthalten die HTTP-Antwort vom Server.
  • Wenn das Protokoll HTTPS war, signalisieren Zeilen, die mit > oder < beginnen, einen erfolgreichen TLS-Handshake.
Verwendete TLS-Bibliothek und Root-Zertifikatpakete

Wenn curl mit den -vvI-Flags ausgeführt wird, wird auch der verwendete Zertifikatspeicher ausgegeben. Die genaue Ausgabe kann allerdings je nach System variieren (siehe unten).

Die Ausgabe eines Red Hat Linux-Computers mit curl mit NSS kann z. B. diese Zeilen enthalten:

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

Die Ausgabe eines Ubuntu- oder Debian Linux-Computers kann folgende Zeilen enthalten:

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

Wird das Flag --cacert verwendet, kann die Ausgabe eines Ubuntu- oder Debian Linux-Computers, für den die PEM-Datei für Root-Zertifikate von Google-verwendet wird, folgende Zeilen enthalten:

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

Ausgehende Anfragen enthalten den User-Agent-Header, der nützliche Informationen über curl und Ihr System liefern kann.

Beispiel für die Ausgabe eines Red Hat Linux-Computers:

> 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: */*
>
Fehler beim TLS-Handshake
Zeilen wie die unten zeigen, dass die Verbindung aufgrund eines nicht vertrauenswürdigen Serverzertifikats während des TLS-Handshakes beendet wurde. Auch das Fehlen von Debug-Ausgaben, die mit > oder < beginnen, ist ein starker Indikator für einen fehlgeschlagenen Verbindungsversuch:
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Erfolgreicher TLS-Handshake
Bei einem erfolgreichen TLS-Handshake werden Zeilen wie die unten ausgegeben. Die Chiffrensammlung, die für die verschlüsselte Verbindung verwendet wird, und Details zum akzeptierten Serverzertifikat sollten dabei aufgeführt werden. Sind Zeilen vorhanden, die mit > oder < beginnen, weist das außerdem darauf hin, dass HTTP-Nutzlast erfolgreich über die TLS-Verbindung übertragen wird:
* 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
Wie drucke ich die empfangenen Serverzertifikate menschenlesbar aus?
Wenn die Ausgabe im PEM-Format erfolgt (z. B. von openssl s_client ... -showcerts), können Sie das Zertifikat so ausdrucken:
  1. Kopieren Sie das gesamte Base64-codierte Zertifikat, einschließlich der Kopf- und Fußzeile:
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. Fügen Sie den Inhalt des Kopierpuffers in das Terminal ein.
  4. Drücken Sie die Eingabetaste.
Ein- und Ausgabebeispiele finden Sie im Abschnitt Wie drucke ich PEM-Zertifikate menschenlesbar aus? unten.

Wie sehen die Google-Zertifikate in OpenSSL aus?

Neues Zertifikat auf Grundlage von „GlobalSign Root CA – R2“

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

Vertrauenswürdige Zertifikate verwalten

Wie kann ich die vertrauenswürdigen Root-Zertifikate auf meinem Smartphone einsehen?

Vertrauenswürdige Zertifikate auf Android-Geräten

Wie unter Können Probleme bei mobilen Apps auftreten? bereits erwähnt, können Android-Nutzer die Liste der vertrauenswürdigen Zertifikate seit Version 4 in den Einstellungen einsehen. In der folgenden Tabelle sehen Sie genau, welchem Pfad Sie in den Einstellungen folgen müssen:

Android-Version Pfad
1.x, 2.x, 3.x
4.x, 5.x, 6.x, 7.x Einstellungen > Sicherheit > Vertrauenswürdige Anmeldedaten
8.x, 9 Einstellungen > Sicherheit & Standort > Verschlüsselung und Anmeldedaten > Vertrauenswürdige Anmeldedaten
10 Einstellungen > Sicherheit > Erweitert > Verschlüsselung und Anmeldedaten > Vertrauenswürdige Anmeldedaten

Die folgende Tabelle veranschaulicht die wahrscheinliche Verfügbarkeit der wichtigsten Root-Zertifikate nach Android-Version. Sie beruht auf einer manuellen Verifikation mit aktuell verfügbaren Systemimages für virtuelle Android-Geräte. Sind keine Systemimages mehr verfügbar, wird auf den Versionsverlauf des Git-Repositorys für CA-Zertifikate von AOSP zurückgegriffen:

Android-Version 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

Der Zertifikatspeicher des Android-Systems kann in der Regel nur aktualisiert werden, wenn ein Firmwareupdate ausgeführt oder das Gerät gerootet wird. Allerdings werden die aktuellen vertrauenswürdigen Root-Zertifikate auf den meisten gängigen Android-Versionen wahrscheinlich noch mehrere Jahre funktionieren, also über die effektive Lebensdauer der meisten existierenden Geräte hinaus.

Ab Version 7.0 ist eine sichere Methode für Entwickler von Android-Apps verfügbar, über die sie app-spezifische vertrauenswürdige Zertifikate angeben können. Dazu werden die Zertifikate mit der App gebündelt und eine benutzerdefinierte Konfiguration der Netzwerksicherheit erstellt, wie auf der Website für Android-Entwickler im entsprechenden Trainingsdokument Network security configuration (in englischer Sprache) beschrieben.

Entwickler von Drittanbieter-Apps können die Konfiguration der Netzwerksicherheit von Traffic des Google Play Services APK nicht beeinflussen. Daher werden diese Bemühungen wahrscheinlich nur teilweise Abhilfe schaffen.

Auf älteren Legacy-Geräten wäre die einzige Option, von Nutzern hinzugefügte CAs zu verwenden, die entweder über eine Unternehmensrichtlinie oder vom Endnutzer selbst auf seinem Gerät installiert werden.

Vertrauenswürdiger Speicher für iOS

Nutzer von iOS-Mobilgeräten können die standardmäßigen vertrauenswürdigen Root-Zertifikate zwar nicht direkt einsehen, ab iOS-Version 5 stellt Apple aber entsprechende Links zur Verfügung. Diese finden Sie auf der Apple-Supportwebsite unter Listen verfügbarer vertrauenswürdiger Root-Zertifikate in iOS und iOS 5 und iOS 6: Liste der verfügbaren vertrauenswürdigen Root-Zertifikate.

Alle zusätzlichen Zertifikate, die auf dem iOS-Gerät installiert sind, sollten jedoch unter Einstellungen > Allgemein > Profile angezeigt werden. Wenn keine zusätzlichen Zertifikate installiert sind, wird der Menüpunkt Profile unter Umständen nicht angezeigt.

Die folgende Tabelle veranschaulicht die Verfügbarkeit der wichtigsten Root-Zertifikate nach iOS-Version:

iOS-Version GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11, 12.0
ab 12.1.3

Wo finde ich den Zertifikatspeicher meines Systems und wie kann ich ihn aktualisieren?

Das richtet sich nach dem Betriebssystem und der verwendeten SSL-/TLS-Bibliothek. Bei den meisten Linux-Distributionen finden Sie die Standard-Root-Zertifikate jedoch unter einem der folgenden Pfade: /usr/local/share/ca-certificates (Debian-, Ubuntu-, ältere RHEL- und CentOS-Versionen), /etc/pki/ca-trust/source/anchors und /usr/share/pki/ca-trust-source (Fedora, neuere RHEL- und CentOS-Versionen) oder /var/lib/ca-certificates (OpenSUSE). Außerdem sind /etc/ssl/certs (Debian, Ubuntu) oder /etc/pki/tls/certs (RHEL, CentOS) möglich. Einige der Zertifikate in diesen Verzeichnissen sind wahrscheinlich symbolische Links zu Dateien in anderen Verzeichnissen.

OpenSSL

Bei Anwendungen, die OpenSSL verwenden, können Sie den konfigurierten Speicherort der installierten Komponenten einschließlich des Standardzertifikatspeichers mit dem folgenden Befehl einsehen:
openssl version -d
Der Befehl gibt OPENSSLDIR aus. Das ist das Verzeichnis der obersten Ebene, in dem sich die Bibliothek und ihre Konfigurationen befinden:
OPENSSLDIR: "/usr/lib/ssl"
Der Zertifikatspeicher befindet sich im Unterverzeichnis 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
…

Wenn OpenSSL wie im Beispiel oben den Standardzertifikatspeicher des Systems verwendet, lesen Sie im Abschnitt Wo finde ich den Zertifikatspeicher meines Systems und wie kann ich ihn aktualisieren? nach und stellen Sie sicher, dass das System-Root-Zertifikatpaket auf dem neuesten Stand ist.

Eine Anleitung zum Abrufen von openssl finden Sie unter OpenSSL herunterladen.

Mozilla NSS

Anwendungen, die Mozilla NSS verwenden, können standardmäßig auch eine systemweite Zertifikatdatenbank nutzen. Diese befindet sich normalerweise unter /etc/pki/nssdb oder einem nutzerspezifischen Speicherort unter ${HOME}/.pki/nssdb. Informationen zum Aktualisieren von NSS finden Sie in der Dokumentation des Tools certutil zum Hinzufügen neuer Zertifikate (in englischer Sprache) sowie in der offiziellen Dokumentation des Betriebssystems.

Microsoft .NET

Windows .NET-Entwickler können die folgenden Microsoft-Artikel lesen, um Informationen zur Aktualisierung ihres Zertifikatspeichers zu erhalten:

Java

Java-Anwendungen verwenden unter Umständen einen eigenen Zertifikatspeicher. Diesen finden Sie auf Linux-Systemen normalerweise unter /etc/pki/java/cacerts oder /usr/share/ca-certificates-java. Wenn Sie Ihren Java-Zertifikatspeicher mit dem Befehlszeilentool keytool von Oracle aktualisieren möchten, finden Sie in folgenden Stack Overflow- und Oracle-Artikeln entsprechende Informationen:

Was ist eine PEM-Datei?

Privacy Enhanced Mail (PEM) ist ein Standardformat für Textdateien zum Speichern und Senden von kryptografischen Zertifikaten, Schlüsseln u. ä., das als RFC 7468 neu veröffentlicht wurde.

Das Dateiformat selbst ist für Menschen lesbar, die Base64-codierten Daten des binären Zertifikats aber nicht. Die PEM-Spezifikation erlaubt aber die Ausgabe von erklärendem Text vor oder nach den codierten Zertifikatdaten. Viele Tools nutzen diese Funktion, um eine Zusammenfassung in Klartext für die wichtigsten Datenelemente in einem Zertifikat zur Verfügung zu stellen.

Auch Tools wie openssl können verwendet werden, um das gesamte Zertifikat in eine für Menschen lesbare Form zu decodieren. Weitere Informationen finden Sie im Abschnitt Wie drucke ich PEM-Zertifikate menschenlesbar aus?.

Was ist eine CRT-Datei?

Tools, mit denen Zertifikate im PEM-Format exportiert werden können, verwenden oft die Dateierweiterung „.crt“, um anzugeben, dass die Datei textcodiert ist.

Was ist eine DER-Datei?

Distinguished Encoding Rules (DER) ist ein standardisiertes Binärformat für die Codierung von Zertifikaten. Zertifikate in PEM-Dateien sind in der Regel Base64-codierte DER-Zertifikate.

Was ist eine CER-Datei?

Eine exportierte Datei mit dem Suffix „.cer“ kann ein PEM-codiertes Zertifikat enthalten, meistens handelt es sich aber um ein binäres, in der Regel DER-codiertes Zertifikat. Konventionsgemäß enthalten CER-Dateien nur ein einzelnes Zertifikat.

Mein System verweigert das Importieren aller Zertifikate aus der Datei „roots.pem“

Einige Systeme lassen nur den Import von PEM-Dateien mit einem einzelnen Zertifikat zu. Im Abschnitt Wie extrahiere ich einzelne Zertifikate aus der Datei „roots.pem“? unten können Sie nachlesen, wie sich die Datei aufteilen lässt.

Wie extrahiere ich einzelne Zertifikate aus der Datei „roots.pem“?

Mit dem folgenden einfachen Bash-Skript können Sie roots.pem in seine Komponentenzertifikate aufteilen:
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
Dabei sollten – wie im folgenden Beispiel zu sehen – mehrere einzelne PEM-Dateien erstellt werden:
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
Die PEM-Dateien issuer=….pem können dann einzeln importiert oder in ein von Ihrem Zertifikatspeicher unterstütztes Dateiformat konvertiert werden.

Wie konvertiere ich eine PEM-Datei in ein von meinem System unterstütztes Format und umgekehrt?

Mit dem Befehlszeilentool openssl können Sie Dateien zwischen allen gängigen Dateiformaten für Zertifikate konvertieren. Unten finden Sie Anleitungen für die Konvertierung von PEM-Dateien in die gängigsten Dateiformate für Zertifikate.

Eine vollständige Liste der verfügbaren Optionen finden Sie in der offiziellen Dokumentation zu den OpenSSL-Befehlszeilendienstprogrammen.

Eine Anleitung zum Abrufen von openssl finden Sie unter OpenSSL herunterladen.

Wie konvertiere ich eine PEM-Datei in das DER-Format?

Mit openssl können Sie den folgenden Befehl ausgeben, um eine Datei von PEM in DER zu konvertieren:
openssl x509 -in roots.pem -outform der -out roots.der

Wie konvertiere ich eine PEM-Datei in PKCS #7?

Mit openssl können Sie den folgenden Befehl ausgeben, um eine Datei von PEM in PKCS #7 zu konvertieren:
openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

Wie konvertiere ich eine PEM-Datei in PKCS #12 (PFX)?

Mit openssl können Sie den folgenden Befehl ausgeben, um eine Datei von PEM in PKCS #12 zu konvertieren:
openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

Sie müssen ein Passwort für die Datei angeben, wenn Sie ein PKCS #12-Archiv erstellen. Speichern Sie das Passwort unbedingt an einem sicheren Ort, wenn Sie die PKCS#12-Datei nicht sofort in Ihr System importieren.

Wie exportiere ich Zertifikate aus dem NSS-Zertifikatspeicher als PEM-Datei?

Sie können sich die Dokumentation zum NSS-Tool certutil von Mozilla und die Diskussion in der Red Hat-Community export certificate from cert8.db as a .pem file ansehen (beide in englischer Sprache).

Wie drucke ich PEM-Zertifikate menschenlesbar aus?

In den folgenden Beispielen wird davon ausgegangen, dass Sie die Datei GlobalSign_Root_CA_-_R2.pem mit folgendem Inhalt haben:
-----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-----

Zertifikate mit OpenSSL drucken

Wenn Sie den Befehl
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
ausführen, sollten die folgenden Zeilen vor dem Zertifikat ausgegeben werden:
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

Eine Anleitung zum Abrufen von openssl finden Sie unter OpenSSL herunterladen.

Zertifikate mit dem Java-Keytool drucken

Wenn Sie den Befehl
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
ausführen, sollten Folgendes ausgegeben werden:
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                                        ....
]
]

Eine Anleitung zum Abrufen von keytool finden Sie unter Java-Keytool herunterladen.

Wie sehe ich, welche Zertifikate in meinem Zertifikatspeicher installiert sind?

Das richtet sich nach dem Betriebssystem und der SSL-/TLS-Bibliothek. Die Tools, die den Import und Export von Zertifikaten in den und aus dem Zertifikatspeicher ermöglichen, bieten in der Regel auch eine Option zum Auflisten der installierten Zertifikate.

Wenn Sie die vertrauenswürdigen Root-Zertifikate erfolgreich in PEM-Dateien exportiert haben oder Ihr Zertifikatspeicher bereits PEM-Dateien enthält, können Sie die Dateien in einem beliebigen Texteditor öffnen, da sie im „Nur Text“-Format vorliegen.

Die PEM-Datei kann korrekt gekennzeichnet sein und menschenlesbare Informationen der zugehörigen Zertifizierungsstelle liefern (z. B. aus der PEM-Beispieldatei von 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-----

Die Datei kann auch nur den Zertifikatteil enthalten. In solchen Fällen gibt der Name der Datei, z. B. GlobalSign_Root_CA_-_R2.pem, unter Umständen an, zu welcher Zertifizierungsstelle das Zertifikat gehört. Für jede Zertifizierungsstelle wird zwischen den Tokens -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- ein eigener Zertifikatstring angezeigt. Sie können ihn also verwenden, um die jeweilige Zertifizierungsstelle eindeutig zuzuordnen.

Sie können also jedes Zertifikat in der PEM-Beispieldatei von Google mit den PEM-Dateien abgleichen, die Sie aus Ihrem Zertifikatspeicher extrahiert haben. Da alle Zertifikate im Root-CA-Paket von Google richtig gekennzeichnet sind, ist leicht ersichtlich, welche bereits in Ihrem Zertifikatspeicher vorhanden sind und welche noch hinzugefügt werden müssen, selbst wenn die PEM-Dateien in Ihrem Zertifikatspeicher nicht gekennzeichnet wurden.

Anleitungen speziell für Smartphones finden Sie im Abschnitt Wie kann ich die vertrauenswürdigen Root-Zertifikate auf meinem Smartphone einsehen?.

Anhang

Benötigen Sie weitere Informationen?

Halten Sie sich in erster Linie immer an die Dokumentation Ihres Betriebssystems, die Dokumentation Ihrer Programmiersprache(n) sowie die Dokumentation aller externen Bibliotheken, die Ihre Anwendung verwendet.

Alle anderen Informationsquellen einschließlich dieser FAQ können veraltet oder aus anderen Gründen fehlerhaft sein. Sie sollten daher nicht als maßgeblich betrachtet werden. Unter Umständen finden Sie trotzdem nützliche Informationen (meistens auf Englisch) in den Q&A-Communities von Stack Exchange, auf Websites wie AdamW on Linux and more oder im Blog „Confirm“, um nur einige zu nennen. Sie sollten sich auch die Google Trust Services FAQ und den Artikel How to Use X.509 Certificates and SSL For Secure Communications ansehen.

Weiterführende Informationen, etwa zum „Certificate Pinning“, finden Sie in diesem Artikel des Open Web Application Security Project (OWASP) und auf dem Pinning Cheat Sheet (beide in englischer Sprache). Android-spezifische Anleitungen finden Sie auf der Website für Android-Entwickler im Trainingsdokument Security with HTTPS and SSL. Hilfreich könnte auch der Blogpost Android Security: SSL Pinning von Matthew Dolan sein. Dort erläutert er u. a. die Vor- und Nachteile von „Certificate Pinning“ und „Public Key Pinning“.

Weitere Informationen zur Verwaltung zusätzlicher vertrauenswürdiger Zertifikate unter Android finden Sie auch auf der Website für Android-Entwickler im Trainingsdokument Network security configuration und im JeroenHD-Blogpost Android 7 Nougat and certificate authorities.

Eine umfassende Liste der von AOSP als vertrauenswürdig eingestuften Root-Zertifizierungsstellen ist im Git-Repository ca-certificates verfügbar. Informationen zu Versionen, die auf offiziellen Android Forks beruhen, z. B. LineageOS, finden Sie in den entsprechenden Repositories des Betriebssystemanbieters.