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

Diese FAQ sind in folgende Abschnitte gegliedert:

Eine detailliertere Übersicht über die laufende Migration der Google-Root-Zertifizierungsstelle findest du unter Was genau ist geplant?.

Terminologie

Nachfolgend haben wir eine Liste der Begriffe zusammengestellt, die für das Verständnis dieser FAQ am wichtigsten sind. Eine ausführlichere Übersicht der entsprechenden Terminologie findest du in den FAQ der Google Trust Services.

SSL-/TLS-Zertifikat
Über ein Zertifikat wird ein kryptografischer Schlüssel mit einer Identität verknüpft.
SSL-/TLS-Zertifikate werden zum Authentifizieren und Herstellen sicherer Websiteverbindungen verwendet. Sie werden von bestimmten Organisationen, sogenannten Zertifizierungsstellen, ausgegeben und kryptografisch signiert.
Browser sind auf Zertifikate angewiesen, die von vertrauenswürdigen Zertifizierungsstellen ausgestellt wurden. So ist sichergestellt, dass die übertragenen Daten an den richtigen Server gesendet und während der Übertragung verschlüsselt werden.
Secure Sockets Layer (SSL)
Secure Sockets Layer war das gängigste Protokoll für die Verschlüsselung der Internetkommunikation. Inzwischen gilt es nicht mehr als sicher und sollte nicht verwendet werden.
Transport Layer Security (TLS)
Transport Layer Security ist der Nachfolger von SSL.
Zertifizierungsstelle (Certificate Authority, CA)
Eine Zertifizierungsstelle ist eine Art digitale Passbehörde für Geräte und Nutzer. Sie stellt kryptographisch geschützte Dokumente (Zertifikate) aus, um zu bestätigen, dass eine Entität (z. B. eine Website) die ist, die sie vorgibt zu sein.
Bevor ein Zertifikat ausgestellt wird, müssen CAs prüfen, ob die Namen im Zertifikat zu dem Nutzer oder der Entität gehören, die es anfordert.
Der Begriff „Zertifizierungsstelle“ kann sich sowohl auf Organisationen wie Google Trust Services als auch auf Systeme beziehen, die Zertifikate ausstellen.
Root-Zertifikatspeicher
Ein Root-Zertifikatspeicher enthält die Zertifizierungsstellen, die ein Anbieter von Anwendungssoftware als vertrauenswürdig eingestuft hat. Die meisten Webbrowser und Betriebssysteme haben einen eigenen Root-Zertifikatspeicher.
Damit eine Zertifizierungsstelle in einen Root-Zertifikatspeicher aufgenommen werden kann, muss sie strenge Anforderungen erfüllen, die vom Anbieter der Anwendungssoftware festgelegt werden.
In der Regel umfassen diese die Einhaltung von Branchenstandards wie die Vorgaben des CA/Browser Forums.
Root-Zertifizierungsstelle
Eine Root-Zertifizierungsstelle bzw. Root-CA (oder genauer, ihr Zertifikat) stellt das erste Zertifikat in einer Zertifikatskette dar.
Root-CA-Zertifikate sind in der Regel selbst signiert. Die zugehörigen privaten Schlüssel werden in hochsicheren Einrichtungen und ausschließlich offline gespeichert, um sie vor unbefugten Zugriffen zu schützen.
Zwischenzertifizierungsstelle
Eine Zwischenzertifizierungsstelle (oder genauer, ein Zwischenzertifikat) ist ein Zertifikat, mit dem andere Zertifikate in einer Zertifikatskette signiert werden.
Zwischenzertifikate dienen hauptsächlich dazu, das Onlinezertifikat auszustellen, während das Root-CA-Zertifikat offline bleiben kann.
Zwischenzertifizierungsstellen werden auch als untergeordnete CAs bezeichnet.
Ausstellende Zertifizierungsstelle
Eine ausstellende Zertifizierungsstelle (oder genauer, ihr Zertifikat) ist das Zertifikat, mit dem das letzte Zertifikat in einer Zertifikatskette signiert wird.
Das letzte (oder unterste) Zertifikat in der Kette wird in der Regel als Abonnenten-, Endentität- oder untergeordnetes Zertifikat bezeichnet. In diesen FAQ wird auch der Begriff Serverzertifikat verwendet.
Zertifikatskette
Zertifikate sind mit dem Aussteller verknüpft bzw. kryptografisch von ihm signiert. Eine Zertifikatskette besteht aus einem untergeordneten Zertifikat, allen entsprechenden Zwischenzertifikaten und einem Root-Zertifikat.
Cross-Zertifizierung
Die Root-Zertifikatspeicher der Clients von Anbietern von Anwendungssoftware müssen aktualisiert werden, damit neue CA-Zertifikate berücksichtigt und von ihren Produkten als vertrauenswürdig eingestuft werden können. Es dauert einige Zeit, bis die Produkte mit den neuen CA-Zertifikaten weit verbreitet sind.
Um die Kompatibilität mit älteren Clients zu steigern, können CA-Zertifikate von einer anderen älteren, etablierten Zertifizierungsstelle „quersigniert“ oder „cross-zertifiziert“ werden. Dabei wird quasi ein zweites CA-Zertifikat für die gleiche Identität (Name und Schlüsselpaar) erstellt.
Je nachdem, welche CAs in ihrem Root-Zertifikatspeicher enthalten sind, bauen Clients unterschiedliche Zertifikatsketten bis zu einer Root-Zertifizierungsstelle auf, die als vertrauenswürdig eingestuft ist.

Allgemeine Informationen

Was genau ist geplant?

Allgemeiner Überblick

2017 begann Google damit, seinen mehrjährigen Plan umzusetzen, eigene Root-Zertifikate ausstellen und nutzen zu können. Root-Zertifikate sind kryptografische Signaturen, die der TLS-Technologie zur Absicherung von HTTPS-Verbindungen zugrunde liegen.

Seit Abschluss der ersten Phase wird die TLS-Sicherheit der Google Maps Platform-Dienste von „GS Root R2“ gewährleistet. Dabei handelt es sich um eine äußerst angesehene Root-Zertifizierungsstelle, die Google von GMO GlobalSign erworben hat, um die Umstellung auf unsere eigenen Root-Zertifizierungsstellen von Google Trust Services (GTS) zu erleichtern.

Praktisch alle TLS-Clients wie Webbrowser, Smartphones und Anwendungsserver vertrauten diesem Root-Zertifikat und konnten so während der ersten Phase der Migration eine sichere Verbindung zu den Google Maps Platform-Servern aufbauen.

Allerdings können Zertifizierungsstellen grundsätzlich keine Zertifikate mehr ausstellen, nachdem ihr eigenes Zertifikat abgelaufen ist. Da „GS Root R2“ am 15. Dezember 2021 abläuft, migriert Google seine eigenen Dienste zu einer neuen Zertifizierungsstelle – GTS Root R1 Cross. Dabei wird ein Zertifikat verwendet, das von der eigenen Root-Zertifizierungsstelle von Google (GTS Root R1) ausgestellt wurde.

Die meisten modernen Betriebssysteme und TLS-Clientbibliotheken vertrauen den GTS-Root-CAs bereits. Um aber auch eine reibungslose Umstellung für einen Großteil der Legacy-Systeme zu gewährleisten, hat Google eine Cross-Zertifizierungsstelle von GMO GlobalSign erworben – GlobalSign Root CA – R1, eine der ältesten und vertrauenswürdigsten Root-CAs, die derzeit verfügbar sind.

Die Google Maps Platform-Clients der meisten Kunden sollten also bereits mindestens eine dieser renommierten Root-Zertifizierungsstellen erkennen und von der zweiten Phase der Migration völlig unberührt bleiben.

Dies gilt auch für Kunden, die 2018 während der ersten Phase der Migration bereits aktiv geworden sind und auf unsere Empfehlung hin alle Zertifikate aus dem vertrauenswürdigen Root-CA-Paket von Google installiert haben.

Du solltest deine Systeme prüfen, wenn Folgendes zutrifft:

  • Deine Dienste laufen auf nicht standardmäßigen oder Legacy-Plattformen und/oder du verwendest einen eigenen Root-Zertifikatspeicher.
  • Du hast 2017/2018 während der ersten Phase der Migration der Google-Root-CA keine Maßnahmen ergriffen oder nicht alle Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google installiert.

Ist das der Fall, musst du deine Clients unter Umständen mit den empfohlenen Root-Zertifikaten aktualisieren. Nur so lässt sich eine unterbrechungsfreie Nutzung der Google Maps Platform während dieser Migrationsphase garantieren.

Weitere technische Details findest du unten. Eine allgemeine Anleitung findest du im Abschnitt Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss?.

Wir empfehlen dir außerdem, deinen Root-Zertifikatspeicher weiter mit dem oben erwähnten Root-CA-Paket zu synchronisieren, um deine Dienste auf zukünftige Änderungen vorzubereiten. Änderungen an den Root-CAs werden immer im Voraus bekannt gegeben. Weitere Informationen findest du unter Wie erhalte ich aktuelle Informationen über diese Migrationsphase? und Wie erhalte ich Vorabbenachrichtigungen zu künftigen Migrationen?.

Technische Übersicht

Wir hatten im Google Security Blog vom 15. März 2021 bereits angekündigt, dass GS Root R2, die Root-CA, die seit Anfang 2018 für die Google Maps Platform verwendet wird, am 15. Dezember 2021 abläuft. Daher migriert Google in diesem Jahr zu einer neuen CA – GTS Root R1 Cross. Unsere Dienste werden aus diesem Grund nach und nach auf untergeordnete TLS-Zertifikate dieser neuen Zertifizierungsstelle umgestellt.

Das GTS Root R1-Zertifikat sollte auf fast allen modernen TLS-Clients und -Systemen bereits vorkonfiguriert sein oder über reguläre Softwareupdates automatisch installiert werden. GlobalSign Root CA – R1 sollte sogar auf älteren Legacy-Systemen verfügbar sein.

Du solltest deine Systeme jedoch zumindest dann prüfen, wenn die beiden folgenden Punkte zutreffen:

  • Deine Dienste laufen auf nicht standardmäßigen oder Legacy-Plattformen und/oder du verwendest einen eigenen Root-Zertifikatspeicher.
  • Du hast 2017/2018 während der ersten Phase der Migration der Google-Root-CA keine Maßnahmen ergriffen oder nicht alle Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google installiert.

Im Abschnitt Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss? kannst du nachlesen, wie du ermittelst, ob dein System betroffen ist.

Weitere Informationen findest du unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren?.

Wie erhalte ich aktuelle Informationen über diese Migrationsphase?

Markiere das öffentliche Problem 186840968, 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.

Wie erhalte ich Vorabbenachrichtigungen zu künftigen Migrationen?

Am besten folgst du dem Google Security Blog. Nach öffentlichen Ankündigungen im Blog werden wir uns bemühen, die produktspezifische Dokumentation so schnell wie möglich zu aktualisieren.

Du solltest auch die Benachrichtigungen für die Google Maps Platform abonnieren. Im Forum werden regelmäßig Updates zu Änderungen veröffentlicht, die voraussichtlich viele Kunden betreffen.

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. Sobald du jedoch alle CAs aus dem Paket vertrauenswürdiger Root-CAs von Google im Root-Zertifikatspeicher deiner Google Maps Platform-Clientanwendungen installiert hast, sollten deine Dienste nicht mehr von der laufenden Migration betroffen sein. Wenn du Speicher und Paket regelmäßig miteinander synchronisierst, bist du außerdem bestens auf zukünftige Root-CA-Änderungen vorbereitet.

Weitere Informationen findest du unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren? und Bei welchen Arten von Anwendungen können Probleme auftreten?.

Im Abschnitt Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss? kannst du nachlesen, wie du dein System testest.

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

Teste deine Anwendungsumgebung mit den unten aufgeführten Testendpunkten:

  • Wenn du eine TLS-Verbindung zum GTS Root R1 Cross-Testendpunkt herstellen kannst, sollte das Ablaufdatum von „GS Root R2“ keine Auswirkungen auf deine Anwendung haben.
  • Wenn du eine TLS-Verbindung zum GTS Root R1-Testendpunkt herstellen kannst, wird sich wahrscheinlich selbst der Wegfall von GTS Root R1 Cross und GlobalSign Root CA – R1 im Jahr 2028 nicht auf deine Anwendung auswirken.

Dein System sollte mit dieser Root-CA-Änderung kompatibel sein, wenn…

  • dein Dienst auf einem gängigen unterstützten Betriebssystem läuft, sowohl das Betriebssystem als auch die Bibliotheken deines Diensts auf dem neuesten Stand sind und du keinen eigenen Root-Zertifikatspeicher verwendest oder
  • du auf unsere Empfehlung hin bereits alle Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google installiert hast.

Potenziell betroffene Kunden sollten sofort alle Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google installieren, um künftige Dienstunterbrechungen zu vermeiden.

Weitere Informationen findest du unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren?.

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

Auf den meisten Plattformen sind zwei Befehlszeilentools verfügbar – curl und openssl. Sie bieten umfangreiche Optionen zum Testen deiner Einrichtung.

Eine Anleitung zum Abrufen von curl findest du im Abschnitt curl herunterladen.

Eine Anleitung zum Abrufen von openssl findest du unter OpenSSL herunterladen.

Nützliche Tools werden auch im Abschnitt Wo finde ich die erforderlichen Tools? weiter unten erwähnt.

Eine genaue Testanleitung ist im Abschnitt Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss? verfügbar.

Den standardmäßigen Root-Zertifikatspeicher testen

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

Paket vertrauenswürdiger Root-CAs von Google verifizieren

Lade das Paket vertrauenswürdiger Root-CAs von Google herunter und gehe dann so vor:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
<span class="no-select">$ </span>curl -vvI --cacert roots.pem https://good.r1xdemo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

Wie und wann wird die Migration der Root-Zertifizierungsstelle von Google fortgesetzt?

  1. Die erste Phase (Migration zu „GS Root R2“) wurde im Januar 2017 angekündigt. Sie startete Ende 2017 und wurde in der ersten Hälfte des Jahres 2018 abgeschlossen.
  2. Die zweite Phase (Migration zu „GTS Root R1 Cross“) wurde im März 2021 angekündigt und wird in den kommenden Monaten vor dem Ablauf von „GS Root R2“ am 15. Dezember 2021 abgeschlossen.

Die Zeitpläne für zukünftige Migrationsphasen werden rechtzeitig vor dem Wegfall der entsprechenden Zertifikate bekannt gegeben.

Wenn du deinen Root-Zertifikatspeicher regelmäßig mit den Zertifikaten aus dem Paket vertrauenswürdiger Root-CAs von Google synchronisierst, sind deine Anwendungen jedoch immer bestens vorbereitet.

Weitere Informationen findest du unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren?.

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

  1. Der gestaffelte Rollout beginnt in einem einzelnen Rechenzentrum.
  2. Er wird dann nach und nach auf alle Rechenzentren ausgeweitet.
  3. Wenn schwerwiegende Probleme auftreten, kann ein Rollback durchgeführt werden, bis die Probleme behoben sind.
  4. Unter Berücksichtigung der Erfahrungen aus früheren Iterationen werden nach und nach 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 Dienste zukunftssicher sind.

Eine genaue Anleitung ist im Abschnitt Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss? verfügbar.

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 können Clients trotzdem Anfragen an die Google Maps Platform senden. Eventuell wird der Vorgang aber auch abgebrochen.

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

In den Google Maps Platform-Zertifikaten werden SANs (Subject Alternative Names) für DNS verwendet. Der Client muss also Zertifikate mit SANs unterstützen, die ganz links im Namen einen einzelnen Platzhalter als Label enthalten, z. B. *.googleapis.com.

Informationen zu den Anforderungen findest du in den FAQ zu GTS unter What are the recommended requirements for a TLS client to communicate with Google? (Was sind die empfohlenen Anforderungen für einen TLS-Client für die Kommunikation mit Google?).

Bei welchen Arten von Anwendungen können Probleme auftreten?

Die Anwendung verwendet den Root-Zertifikatspeicher des Systems ohne Einschränkungen durch den Entwickler

Google Maps Platform-Webdienstanwendungen

Wenn du ein gängiges Betriebssystem verwendest (z. B. Ubuntu, Red Hat, Windows 10, Windows Server 2019 oder OS X), das noch unterstützt und regelmäßig aktualisiert wird, sollte dein standardmäßiger Zertifikatspeicher bereits das Zertifikat GS Root R1 enthalten.

Falls du eine veraltete Betriebssystemversion verwendest, für die keine Updates mehr veröffentlicht werden, ist GS Root R1 unter Umständen nicht enthalten. Dein Root-Zertifikatspeicher enthält jedoch wahrscheinlich GlobalSign Root CA – R1, eine der ältesten und angesehensten Root-CAs.

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

Clientseitige Google Maps Platform-Anwendungen

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

Für native mobile Apps, die das Maps SDK for Android, Maps SDK for iOS, Places SDK for Android oder Places SDK for iOS nutzen, gelten die gleichen Regeln wie für Anwendungen, die die Google Maps Platform-Webdienste aufrufen.

Weitere Informationen findest du unter Können Probleme bei mobilen Apps auftreten?.

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

Du musst dein Zertifikatpaket selbst aktualisieren. Wie unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren? beschrieben, solltest du alle Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google in deinen eigenen Root-Zertifikatspeicher importieren.

Wenn du Zertifikate oder öffentliche Schlüssel für die Google-Domains anpinnst, mit denen deine Anwendung eine Verbindung herstellt, solltest du die entsprechenden Zertifikate und Schlüssel in die Liste der vertrauenswürdigen Entitäten in deiner Anwendung aufnehmen.

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

Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren?

Die Auswahl der Root-CAs im Paket vertrauenswürdiger Root-CAs von Google umfasst alle Zertifizierungsstellen, die in absehbarer Zukunft von Google-Diensten verwendet werden könnten.

Wenn du dein System zukunftssicher machen möchtest, musst du alle Zertifikate aus dem Paket in deinen Zertifikatspeicher importieren und ihn außerdem regelmäßig mit dem Paket synchronisieren.

Das ist besonders wichtig, wenn deine Dienste auf einer Betriebssystemversion ausgeführt werden, die nicht mehr unterstützt wird, du dein Betriebssystem und deine Bibliotheken aus einem anderen Grund nicht auf dem neuesten Stand halten kannst oder du einen eigenen Root-Zertifikatspeicher verwendest.

Unter Wie erhalte ich Vorabbenachrichtigungen zu künftigen Migrationen? kannst du nachlesen, wie du Updates zu anstehenden Root-CA-Migrationen erhältst. Indem du deinen Root-Zertifikatspeicher regelmäßig mit dem Paket synchronisierst, schützt du deine Dienste vor Unterbrechungen aufgrund künftiger CA-Änderungen und sorgst dafür, dass sie auch nach dem Wegfall von GTS Root R1 Cross und GlobalSign Root CA – R1 weiter laufen.

Weitere Hinweise findest du in den FAQ zu GTS unter I'm building a product that connects to Google services. What CA certificates do I need to trust? (Ich entwickle ein Produkt, das eine Verbindung zu Google-Diensten herstellt. Welchen CA-Zertifikaten muss ich vertrauen?).

Warum sollte ich keine untergeordneten oder Zwischen-CA-Zertifikate installieren?

Dann können nämlich Probleme mit deiner Anwendung auftreten, wenn wir ein neues Zertifikat einführen oder zu einer anderen Zwischen-CA wechseln. Beides ist jederzeit und ohne Vorankündigung möglich. Das gilt gleichermaßen für einzelne Serverzertifikate, etwa Zertifikate, die über maps.googleapis.com bereitgestellt werden, sowie für alle Zwischen-CAs wie GTS Root R1 Cross.

Um deine Dienste entsprechend zu schützen, solltest du nur Root Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google installieren und ausschließlich das Root-Zertifikat verwenden, um die Authentizität der gesamten Zertifikatskette zu validieren.

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 JavaScript-Anwendungen auftreten?

Die GTS-Root-Zertifikate sind in den meisten modernen Browsern bereits fest integriert und werden von diesen als vertrauenswürdig eingestuft. Für die meisten Endnutzer auf Legacy-Browsern sollte die Cross-Zertifizierungsstelle von GMO GlobalSign eine reibungslose Migration gewährleisten. Das schließt alle unterstützten Browser für die Maps JavaScript API ein.

Eigentlich sollten Endnutzer in allen modernen Browsern in der Lage sein, zu prüfen, welchen Zertifikaten der Browser vertraut, und diese entsprechend zu bearbeiten. Die Liste der Zertifikate ist normalerweise unter Einstellungen zu finden, das kann aber je nach Browser variieren.

Können Probleme bei mobilen Apps auftreten?

Android- und Apple iOS-Geräte, für die weiterhin Updates vom Hersteller veröffentlicht werden, sollten zukunftssicher sein. Die meisten älteren Android-Smartphones vertrauen zumindest dem Zertifikat GlobalSign Root CA – R1. Die Liste der vertrauenswürdigen Zertifikate kann aber je nach Hersteller, Gerätemodell und Android-Version variieren.

Die GTS-Root-CAs, einschließlich GTS Root R1, werden in den Android-Versionen vor Android 10 aber eventuell nur eingeschränkt unterstützt.

Für die aktuellen iOS-Versionen stellt Apple eine Liste vertrauenswürdiger Root-Zertifizierungsstellen auf der Supportseite zur Verfügung. GlobalSign Root CA – R1 wird jedoch auf allen iOS-Geräten ab Version 5 unterstützt.

Die GTS-Root-CAs, einschließlich GTS Root R1, werden seit iOS-Version 12.1.3 unterstützt.

Weitere Informationen findest du unter 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 hat in den letzten Jahren eng mit allen wichtigen Drittanbietern zusammengearbeitet, um gängige, vertrauenswürdige Root-Zertifikatpakete zu verwalten. 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.

Daher vertrauen Systeme, die derzeit unterstützt werden, höchstwahrscheinlich bereits den neuen GTS-Root-Zertifizierungsstellen von Google, einschließlich GTS Root R1. Selbst Legacy-Systeme unterstützen mit hoher Wahrscheinlichkeit GlobalSign Root CA – R1. Diese wird in den nächsten Jahren verwendet, um Zertifikate querzusignieren, die von Google ausgestellt wurden.

Google hat keinen Einfluss darauf, ab wann Zertifikate von Drittanbietern berücksichtigt werden. Aus diesem Grund solltest du 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 deiner OS-Distribution nicht enthalten ist, kannst du das Tool unter https://curl.haxx.se/ herunterladen. Dabei hast du die Möglichkeit, die Quelle herunterzuladen und das Tool selbst zu kompilieren oder ein vorkompiliertes Binärprogramm herunterzuladen, sofern eins für deine Plattform verfügbar ist.

OpenSSL herunterladen

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

Wireshark, tshark oder tcpdump

wireshark ist in den meisten Linux-Distributionen enthalten. Die Befehlszeilentools tshark und tcpdump sowie vorkompilierte Versionen von Wireshark und tshark für andere Betriebssysteme findest du unter https://www.wireshark.org.

Der Quellcode für tcpdump und LibPCAP ist unter https://www.tcpdump.org verfügbar.

Die Dokumentation für diese nützlichen Tools findest du im Nutzerhandbuch von Wireshark sowie auf den Manpages zu tshark und tcpdump (alle in englischer Sprache).

Java-Keytool herunterladen

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

Vorgehensweise bei einem Produktionsausfall

Zuerst solltest du die erforderlichen Root-Zertifikate aus dem Paket vertrauenswürdiger Root-CAs von Google in den Zertifikatspeicher deiner Anwendung importieren.

  1. Arbeite mit deinen Systemadministratoren zusammen und aktualisiere den lokalen Root-Zertifikatspeicher.
  2. In diesen FAQ findest du Hinweise für dein System.
  3. Falls du weitere plattform- oder systemspezifische Hilfe benötigst, wende dich an den technischen Support deines Systemanbieters.
  4. Allgemeine Unterstützung erhältst du von unserem Supportteam (siehe Abschnitt Google Maps Platform-Support kontaktieren). Hinweis: Bei plattformspezifischen Problemen ist nur eine Betreuung nach besten Kräften möglich.
  5. Markiere das öffentliche Problem 186840968, um Benachrichtigungen zur Migration zu erhalten.

Google Maps Platform-Support kontaktieren

Erste Schritte zur Fehlerbehebung

Unter Wie finde ich heraus, ob mein Root-Zertifikatspeicher aktualisiert werden muss? findest du allgemeine Informationen zur Fehlerbehebung.

Falls du Root-Zertifikate exportieren oder importieren musst, solltest du dir auch den Abschnitt Vertrauenswürdige Zertifikate ansehen.

Wenn das Problem nicht behoben wurde und du dich an den Google Maps Platform-Support wenden möchtest, halte bitte Antworten auf folgende Fragen bereit:

  1. Wo befinden sich die betroffenen Server?
  2. Welche Google-IP-Adressen ruft dein 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?

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

Unter Wo finde ich die erforderlichen Tools? kannst du nachlesen, wie du dir die nötigen Tools beschaffst.

Supportanfrage erstellen

Rufe Support und Ressourcen für Google Maps Platform auf und folge der Anleitung unter Supportfall erstellen.

Bei einer Supportanfrage musst du zusätzlich zu den unter Erste Schritte zur Fehlerbehebung aufgeführten Informationen auch Folgendes angeben:

  • Deine öffentlichen IP-Adressen.
  • Die öffentliche IP-Adresse deines DNS-Servers.
  • Gegebenenfalls einen tcpdump- oder Wireshark-Paketmitschnitt der fehlgeschlagenen TLS-Verhandlung mit https://maps.googleapis.com/ im pcap-Format. Achte darauf, dass das Paket dabei nicht gekürzt wird. Für ältere Versionen von tcpdump musst du dazu eventuell -s0 verwenden.
  • Wenn möglich, Log-Auszüge deines Dienstes, aus denen der genaue Grund für die fehlgeschlagene TLS-Verbindung hervorgeht, am besten mit vollständigen Informationen zur Serverzertifikatkette.

Unter Wo finde ich die erforderlichen Tools? kannst du nachlesen, wie du dir die nötigen Tools beschaffst.

Beiträge zum öffentlichen Problem 186840968

Wenn du Kommentare zum öffentlichen Problem 186840968 postest, mache bitte alle Angaben, die im Abschnitt Erste Schritte zur Fehlerbehebung aufgeführt sind.

Wie finde ich die öffentliche Adresse meines DNS heraus?

Unter Linux kannst du folgenden Befehl ausführen:

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

Unter Windows kannst du Nslookup im interaktiven Modus verwenden:

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

Wie interpretiere ich die curl-Ausgabe?

Wenn du curl mit den -vvI-Flags ausführst, erhältst du viele nützliche Informationen. Hier findest du 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

Wird curl mit den -vvI-Flags ausgeführt, dann wird auch der verwendete Root-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 --cacert-Flag 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/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

User-Agent

Ausgehende Anfragen enthalten den User-Agent-Header, der nützliche Informationen über curl und dein 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 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Fehler beim TLS-Handshake

Zeilen wie denen im folgenden Codebeispiel ist zu entnehmen, 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 Hinweis auf 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 im nächsten Codebeispiel ausgegeben. Dabei sollten die Cipher Suite, die für die verschlüsselte Verbindung verwendet wird, sowie Details zum akzeptierten Serverzertifikat 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:

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

Wie drucke ich die empfangenen Serverzertifikate menschenlesbar aus?

Wenn die Ausgabe im PEM-Format erfolgt (z. B. von openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null), kannst du das Zertifikat so ausdrucken:

  • Kopiere das gesamte Base64-codierte Zertifikat, einschließlich der Kopf- und Fußzeile:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • Danach:

    openssl x509 -inform pem -noout -text
    ````
    
  • Füge dann den Inhalt des Kopierpuffers in das Terminal ein.

  • Drücke die Eingabetaste.

Ein- und Ausgabebeispiele findest du im Abschnitt Wie drucke ich PEM-Zertifikate menschenlesbar aus?.

Wie sehen die quersignierten Google-Zertifikate in OpenSSL aus?

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

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

---
…

Vertrauenswürdige Zertifikate

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

Vertrauenswürdige Zertifikate auf Android-Geräten

Wie im Abschnitt Können Probleme bei mobilen Apps auftreten? erwähnt, können Android-Nutzer die Liste der vertrauenswürdigen Zertifikate seit Version 4 in den Einstellungen einsehen. In dieser Tabelle siehst du genau, welchem Pfad du in den Einstellungen folgen musst:

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 zeigt 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 GTS Root R1 GlobalSign Root CA – R1 GlobalSign Root R2 (läuft am 15. Dezember 2021 ab)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Der Root-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 auf seiner Supportwebsite aber entsprechende Links zur Verfügung:

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, ist der Menüpunkt Profile unter Umständen nicht zu sehen.

In dieser Tabelle ist angegeben, welche wichtigen Root-Zertifikate für welche iOS-Versionen verfügbar sind:

iOS-Version GTS Root R1 GlobalSign Root CA – R1 GlobalSign Root R2 (läuft am 15. Dezember 2021 ab)
5, 6, 7, 8, 9, 10, 11, 12.0
ab 12.1.3

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

Der Speicherort des Standard-Root-Zertifikatspeichers richtet sich nach dem Betriebssystem und der verwendeten SSL-/TLS-Bibliothek. Bei den meisten Linux-Distributionen findest du 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
  • /var/lib/ca-certificates: openSUSE

Andere mögliche Pfade:

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

Einige der Zertifikate in diesen Verzeichnissen sind wahrscheinlich symbolische Links zu Dateien in anderen Verzeichnissen.

OpenSSL-Root-Zertifikatspeicher

Bei Anwendungen, die OpenSSL verwenden, kannst du den konfigurierten Speicherort der installierten Komponenten einschließlich des Standard-Root-Zertifikatspeichers 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 Root-Zertifikatspeicher befindet sich im Unterverzeichnis certs.

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

Wenn OpenSSL wie im Beispiel oben den Standard-Root-Zertifikatspeicher des Systems verwendet, solltest du den Abschnitt Wo finde ich den Root-Zertifikatspeicher meines Systems und wie kann ich ihn aktualisieren? lesen und dich vergewissern, dass das Root-Zertifikatpaket des Systems auf dem neuesten Stand ist.

Eine Anleitung zum Abrufen von openssl findest du unter OpenSSL herunterladen.

Root-Zertifikatspeicher (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 findest du in der Dokumentation des Tools certutil zum Hinzufügen neuer Zertifikate (in englischer Sprache) sowie in der offiziellen Dokumentation des Betriebssystems.

Root-Zertifikatspeicher (Microsoft .NET)

Windows .NET-Entwickler werden zumindest in den folgenden Microsoft-Artikeln nützliche Informationen zur Aktualisierung ihres Root-Zertifikatspeichers finden:

Root-Zertifikatspeicher (Java)

Java-Anwendungen verwenden unter Umständen einen eigenen Root-Zertifikatspeicher. Diesen findest du auf Linux-Systemen normalerweise unter /etc/pki/java/cacerts oder /usr/share/ca-certificates-java. Wenn du deinen Java-Root-Zertifikatspeicher mit dem Befehlszeilentool keytool von Oracle aktualisieren möchtest, findest du auf den folgenden Stack Overflow- und Oracle-Seiten entsprechende Informationen:

Dateiformate für Zertifikate

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 gestattet 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 mit Tools wie openssl lässt sich das gesamte Zertifikat in eine für Menschen lesbare Form decodieren. Weitere Informationen findest du im Abschnitt Wie drucke ich PEM-Zertifikate menschenlesbar aus?.

Was ist eine CRT-Datei?

Bei Tools, mit denen Zertifikate im PEM-Format exportiert werden können, wird meistens mit der Dateierweiterung „.crt“ angezeigt, 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“? kannst du nachlesen, wie sich die Datei aufteilen lässt.

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

Mit dem folgenden einfachen Bash-Skript kannst du 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}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Dabei sollten – wie im folgenden Beispiel – mehrere einzelne PEM-Dateien erstellt werden:

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

Die PEM-Dateien wie 02265526.pem können dann einzeln importiert oder in ein von deinem Zertifikatspeicher unterstütztes Dateiformat konvertiert werden.

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

Mit dem Befehlszeilentool openssl kannst du Dateien zwischen allen gängigen Dateiformaten für Zertifikate konvertieren. Unten findest du Anleitungen für die Konvertierung von PEM-Dateien in die gängigsten Dateiformate für Zertifikate.

Eine vollständige Liste der verfügbaren Optionen ist in der offiziellen Dokumentation zu den OpenSSL-Befehlszeilendienstprogrammen (in englischer Sprache) enthalten.

Eine Anleitung zum Abrufen von openssl findest du unter OpenSSL herunterladen.

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

Mit openssl kannst du 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 kannst du 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 kannst du 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

Du musst ein Passwort für die Datei angeben, wenn du ein PKCS #12-Archiv erstellst. Speichere das Passwort unbedingt an einem sicheren Ort, wenn du die PKCS#12-Datei nicht sofort in dein System importierst.

Zertifikate aus dem Root-Zertifikatspeicher auflisten, drucken und exportieren

Wie exportiere ich ein Zertifikat aus dem Java Key Store als PEM-Datei?

Mit keytool kannst du den folgenden Befehl ausgeben, um ein Java Key Store-Zertifikat zu exportieren, das einem bestimmten Alias im PEM-Format entspricht:

keytool -exportcert -rfc -keystore certs.jks -storepass password -alias server &gt; server.pem

Ersetze dazu einfach die Variablen -keystore, -storepass und -alias oben durch die entsprechenden Werte für deine Umgebung.

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

Sieh dir hierzu die Dokumentation zum NSS-Tool certutil von Mozilla und diese Diskussion in der Red Hat-Community an: export certificate from cert8.db as a .pem file (beide in englischer Sprache).

Wie drucke ich PEM-Zertifikate menschenlesbar aus?

In den folgenden Beispielen wird davon ausgegangen, dass du die Datei GTS_Root_R1.pem mit folgendem Inhalt hast:

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

Wenn du den Befehl

openssl x509 -in GTS_Root_R1.pem -text

ausführst, sollte die Ausgabe in etwa so aussehen:

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

Eine Anleitung zum Abrufen von openssl findest du unter OpenSSL herunterladen.

Zertifikate mit dem Java-Keytool drucken

Wenn du den Befehl

keytool -printcert -file GTS_Root_R1.pem

ausführst, sollte die Ausgabe in etwa so aussehen:

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

Extensions:

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

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

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

Eine Anleitung zum Abrufen von keytool findest du unter Java-Keytool herunterladen.

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

Das richtet sich nach dem Betriebssystem und der SSL-/TLS-Bibliothek. Die Tools, mit denen Zertifikate in den und aus dem Root-Zertifikatspeicher importiert bzw. exportiert werden können, haben in der Regel auch eine Option zum Auflisten der installierten Zertifikate.

Wenn du die vertrauenswürdigen Root-Zertifikate erfolgreich in PEM-Dateien exportiert hast oder dein Root-Zertifikatspeicher bereits PEM-Dateien enthält, kannst du 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 dem Paket vertrauenswürdiger Root-CAs von Google):

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

Unter Umständen enthält die Datei auch nur den Zertifikatteil. In solchen Fällen kann der Name der Datei, z. B. GTS_Root_R1.pem, angeben, zu welcher Zertifizierungsstelle das Zertifikat gehört. Außerdem wird zwischen den Tokens -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- für jede Zertifizierungsstelle ein eigener Zertifikatstring angezeigt.

Im Paket vertrauenswürdiger Root-CAs von Google sind alle Zertifikate genau gekennzeichnet. Deshalb ist es auch ohne die oben aufgeführten Tools möglich, die Root-CAs aus dem Paket richtig mit denen in deinem Root-Zertifikatspeicher abzugleichen, entweder nach Issuer oder indem du die Zertifikatstrings in der PEM-Datei vergleichst.

Webbrowser können einen eigenen Root-Zertifikatspeicher nutzen oder den Standardspeicher des Betriebssystems nutzen. Du solltest jedoch in allen modernen Browsern die Möglichkeit haben, die Root-CAs, denen du vertraust, zu verwalten oder zumindest einzusehen. Weitere Informationen findest du unter Können Probleme bei JavaScript-Anwendungen auftreten?.

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

Anhang

Brauchst du weitere Informationen?

Halte dich in erster Linie immer an die Dokumentation deines Betriebssystems, deiner Programmiersprache(n) und aller externen Bibliotheken, die deine 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 findest du 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.

Du solltest dir außerdem die FAQ zu Google Trust Services ansehen.

Weiterführende Informationen, etwa zum „Certificate Pinning“, sind in diesem Artikel des Open Web Application Security Project (OWASP) und im Pinning Cheat Sheet (beide in englischer Sprache) verfügbar. Android-spezifische Anleitungen findest du in den Best Practices für Android-Entwickler im Trainingsdokument Security with HTTPS and SSL. Auch der Blogpost Android Security: SSL Pinning von Matthew Dolan könnte hilfreich sein. Er erläutert dort u. a. die Vor- und Nachteile von „Certificate Pinning“ und „Public Key Pinning“.

Weitere Informationen zur Verwaltung zusätzlicher vertrauenswürdiger Zertifikate unter Android findest du auch in den Best Practices 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, findest du in den entsprechenden Repositories des Betriebssystemanbieters.