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

Diese FAQs sind in folgende Abschnitte gegliedert:

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

Terminologie

Nachfolgend haben wir eine Liste der Begriffe zusammengestellt, die für das Verständnis dieser FAQs am wichtigsten sind. Eine ausführlichere Übersicht der entsprechenden Terminologie finden Sie in den FAQs 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 kryptografisch 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 Zertifizierungsstellen prüfen, ob die Namen im Zertifikat zu dem Nutzer oder der Entität gehören, der bzw. 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, ihr 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-, Endbenutzer- oder untergeordnetes Zertifikat bezeichnet. In diesen FAQs 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 abgelaufen ist, hat Google seine eigenen Dienste zu einer neuen Zertifizierungsstelle migriert – GTS Root R1 Cross. Dabei wird ein von der eigenen Root-Zertifizierungsstelle von Google (GTS Root R1) ausgestelltes Zertifikat verwendet.

Die meisten modernen Betriebssysteme und TLS-Clientbibliotheken vertrauen den GTS-Root-CAs bereits. Um aber auch für eine reibungslose Umstellung für einen Großteil der Legacy-Systeme zu sorgen, hat Google eine Cross-Zertifizierungsstelle von GMO GlobalSign erworben: GlobalSign Root CA – R1 ist 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.

Sie sollten Ihre Systeme prüfen, wenn Folgendes zutrifft:

  • Ihre Dienste laufen auf nicht standardmäßigen oder Legacy-Plattformen und/oder Sie verwenden einen eigenen Root-Zertifikatspeicher.
  • Sie haben 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, müssen Sie Ihre Clients unter Umständen mit den empfohlenen Root-Zertifikaten aktualisieren. Nur so kann die Google Maps Platform während dieser Migrationsphase unterbrechungsfrei genutzt werden.

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

Wir empfehlen Ihnen außerdem, Ihren Root-Zertifikatspeicher weiter mit dem oben erwähnten Root-CA-Paket zu synchronisieren, um Ihre Dienste auf zukünftige Änderungen vorzubereiten. Änderungen an den Root-CAs werden immer im Voraus bekannt gegeben. Weitere Informationen finden Sie 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.

Sie sollten Ihre Systeme jedoch zumindest dann prüfen, wenn die beiden folgenden Punkte zutreffen:

  • Ihre Dienste laufen auf nicht standardmäßigen oder Legacy-Plattformen und/oder Sie verwenden einen eigenen Root-Zertifikatspeicher.
  • Sie haben 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? können Sie nachlesen, wie Sie ermitteln, ob Ihr System betroffen ist.

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

Wie erhalte ich aktuelle Informationen über diese Migrationsphase?

Markieren Sie 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 FAQs entsprechend aktualisiert.

Wie erhalte ich Vorabbenachrichtigungen zu künftigen Migrationen?

Am besten folgen Sie 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.

Sie sollten 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 Sie jedoch alle CAs aus dem Paket vertrauenswürdiger Root-Zertifizierungsstellen von Google im Root-Zertifikatspeicher Ihrer Google Maps Platform-Clientanwendungen installiert haben, sollten Ihre Dienste nicht mehr von der laufenden Migration betroffen sein. Wenn Sie Speicher und Paket regelmäßig synchronisieren, sind Sie außerdem bestens auf zukünftige Root-CA-Änderungen vorbereitet.

Weitere Informationen finden Sie unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-Zertifizierungsstellen 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? können Sie nachlesen, wie Sie Ihr System testen.

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

Testen Sie Ihre Anwendungsumgebung mit den unten aufgeführten Testendpunkten:

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

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

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

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 finden Sie unter Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-Zertifizierungsstellen 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 Ihrer Einrichtung.

Eine Anleitung zum Abrufen von curl finden Sie unter curl herunterladen.

Die unten aufgeführten openssl-Befehle sind für Version 1.1.1 oder höher. Frühere Versionen werden nicht unterstützt. Wenn Sie eine ältere Version verwenden, nehmen Sie ein Upgrade vor oder ändern diese Befehle entsprechend. Eine Anleitung zum Abrufen von openssl finden Sie 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.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Paket vertrauenswürdiger Root-CAs von Google verifizieren

Laden Sie das Paket vertrauenswürdiger Root-CAs von Google herunter und gehen Sie 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.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

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 Sie Ihren Root-Zertifikatspeicher regelmäßig mit den Zertifikaten aus dem Paket vertrauenswürdiger Root-CAs von Google synchronisieren, sind Ihre Anwendungen jedoch immer bestens vorbereitet.

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

Allgemeiner Roll-out-Plan für die einzelnen Google-Dienste

  1. Der gestaffelte Roll-out 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 finden Sie in den FAQs 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 Sie ein gängiges Betriebssystem verwenden (z. B. Ubuntu, Red Hat, Windows 10, Windows Server 2019 oder OS X), das noch unterstützt und regelmäßig aktualisiert wird, sollte Ihr standardmäßiger Zertifikatspeicher bereits das Zertifikat GS Root R1 enthalten.

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

Für mobile Anwendungen, 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 finden Sie 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 finden Sie unter Können Probleme bei mobilen Anwendungen 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 Warum sollte ich meinen Root-Zertifikatspeicher regelmäßig mit dem Paket vertrauenswürdiger Root-Zertifizierungsstellen von Google synchronisieren? beschrieben, sollten Sie alle Zertifikate aus dem Paket vertrauenswürdiger Root-Zertifizierungsstellen von Google in Ihren eigenen Root-Zertifikatspeicher importieren.

Wenn Sie Zertifikate oder öffentliche Schlüssel für die Google-Domains pinnen, 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.

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

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

Wenn Sie Ihr System zukunftssicher machen möchten, müssen Sie alle Zertifikate aus dem Paket in Ihren Zertifikatspeicher importieren und ihn außerdem regelmäßig mit dem Paket synchronisieren.

Das ist besonders wichtig, wenn Ihre Dienste auf einer Betriebssystemversion ausgeführt werden, die nicht mehr unterstützt wird, Sie Ihr Betriebssystem und Ihre Bibliotheken aus einem anderen Grund nicht auf dem neuesten Stand halten können oder Sie einen eigenen Root-Zertifikatspeicher verwenden.

Unter Wie erhalte ich Vorabbenachrichtigungen zu künftigen Migrationen? können Sie nachlesen, wie Sie Updates zu anstehenden Root-CA-Migrationen erhalten. Indem Sie Ihren Root-Zertifikatspeicher regelmäßig mit dem Paket synchronisieren, schützen Sie Ihre Dienste vor Unterbrechungen aufgrund künftiger CA-Änderungen und sorgen dafür, dass sie auch nach dem Wegfall von GTS Root R1 Cross und GlobalSign Root CA – R1 weiter laufen.

Weitere Hinweise finden Sie in den FAQs 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 Ihrer 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 Ihre Dienste entsprechend zu schützen, sollten Sie 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 reibungslose Migration mit der Cross-Zertifizierungsstelle von GMO GlobalSign funktionieren. 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 finden Sie 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 ChromeOS-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 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, 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 finden Sie 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 finden Sie im Nutzerhandbuch von Wireshark sowie auf den Manpages zu tshark und tcpdump.

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 dem Paket vertrauenswürdiger Root-CAs von Google in den Zertifikatspeicher Ihrer Anwendung importieren.

  1. Arbeiten Sie mit Ihren Systemadministratoren zusammen und aktualisieren Sie den lokalen Root-Zertifikatspeicher.
  2. In diesen FAQs 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). Hinweis: Bei plattformspezifischen Problemen ist nur eine Betreuung nach besten Kräften möglich.
  5. Markieren Sie 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? finden Sie allgemeine Informationen zur Fehlerbehebung.

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

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

  1. Wo befinden sich die 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?

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

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

Supportanfrage erstellen

Rufen Sie Support und Ressourcen für Google Maps Platform auf und folgen Sie der Anleitung unter Supportanfrage erstellen.

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

  • Ihre öffentlichen IP-Adressen.
  • Die öffentliche IP-Adresse Ihres DNS-Servers.
  • Wenn möglich, eine tcpdump- oder Wireshark-Paketaufzeichnung der fehlgeschlagenen TLS-Verhandlung mit https://maps.googleapis.com/ im pcap-Format. Achten Sie darauf, dass das Paket dabei nicht gekürzt wird. Für ältere Versionen von tcpdump müssen Sie dazu -s0 verwenden.
  • Wenn möglich, Log-Auszüge Ihres 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? können Sie nachlesen, wie Sie sich die nötigen Tools beschaffen.

Beiträge zum öffentlichen Problem 186840968

Wenn Sie Kommentare zum öffentlichen Problem 186840968 posten, machen Sie bitte alle Angaben, die im Abschnitt Erste Schritte zur Fehlerbehebung aufgeführt sind.

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 Nslookup im interaktiven Modus verwenden:

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

Wie interpretiere ich die curl-Ausgabe?

Wenn Sie curl mit den -vvI-Flags 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, 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 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 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 (wie z. B. die Ausgabe von openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null), können Sie das Zertifikat so ausdrucken:

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

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

  • Danach:

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

  • Fügen Sie dann den Inhalt des Kopierpuffers in das Terminal ein.

  • Drücken Sie die Eingabetaste.

Ein- und Ausgabebeispiele finden Sie 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.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

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

---
…

Vertrauenswürdige Zertifikate

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 Anwendungen auftreten? erwähnt wird, haben Nutzer von Mobilgeräten seit Android-Version 4.0 die Möglichkeit, die Liste der vertrauenswürdigen Zertifikate in den Einstellungen zu prüfen. In dieser 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 zeigt die wahrscheinliche Verfügbarkeit der wichtigsten Root-Zertifikate nach Android-Version. Sie beruht auf einer manuellen Überprüfung 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 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.

iOS Trust Store

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

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 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
  • /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, können Sie 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, sollten Sie den Abschnitt Wo finde ich den Root-Zertifikatspeicher meines Systems und wie kann ich ihn aktualisieren? lesen und prüfen, ob das Root-Zertifikatpaket des Systems auf dem neuesten Stand ist.

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

Root-Zertifikatspeicher (Java)

Java-Anwendungen verwenden unter Umständen einen eigenen Root-Zertifikatspeicher. Diesen finden Sie auf Linux-Systemen normalerweise unter /etc/pki/java/cacerts oder /usr/share/ca-certificates-java. Er kann über das Befehlszeilentool Java keytool verwaltet werden.

Führen Sie den folgenden Befehl aus, um ein einzelnes Zertifikat in Ihren Java-Zertifikatspeicher zu importieren:

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

Ersetzen Sie cert.pem einfach durch die Zertifikatsdatei jedes empfohlenen Root-Zertifikats, alias durch einen eindeutigen, aber aussagekräftigen Alias für das Zertifikat und certs.jks durch die Zertifikatdatenbankdatei Ihrer Umgebung.

Weitere Informationen finden Sie in den folgenden Oracle- und Stack Overflow-Artikeln:

Root-Zertifikatspeicher (Mozilla NSS)

Anwendungen mit Mozilla NSS 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.

Verwenden Sie das Tool certutil, um Ihre NSS-Datenbank zu aktualisieren.

Führen Sie den folgenden Befehl aus, um ein einzelnes Zertifikat in Ihre NSS-Datenbank zu importieren:

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

Ersetzen Sie cert.pem einfach durch die Zertifikatsdatei jedes empfohlenen Root-Zertifikats, cert-name durch einen aussagekräftigen Alias für das Zertifikat und certdir durch den Zertifikatdatenbankpfad Ihrer Umgebung.

Weitere Informationen finden Sie im offiziellen Nutzerhandbuch zu NSS Tools certutil sowie in der Dokumentation Ihres Betriebssystems.

Root-Zertifikatspeicher (Microsoft .NET)

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

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 menschenlesbar, 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 visuell lesbare Form decodieren. Weitere Informationen finden Sie 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, z. B. Java keytool, können nur ein einzelnes Zertifikat aus einer PEM-Datei importieren, auch wenn sie mehrere enthält. Unter Wie extrahiere ich einzelne Zertifikate aus der Datei „roots.pem“? können Sie nachlesen, wie sich die Datei vor dem Import aufteilen lässt.

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

Mit dem folgenden einfachen Bash-Script 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}" $(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 Ihrem Zertifikatspeicher unterstütztes Dateiformat konvertiert werden.

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

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

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

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.

Zertifikate aus dem Root-Zertifikatspeicher auflisten, drucken und exportieren

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

Mit keytool lässt sich der folgende Befehl ausgeben, um alle Zertifikate in Ihrem Zertifikatspeicher zusammen mit dem Alias aufzulisten, mit dem Sie sie exportieren können:

keytool -v -list -keystore certs.jks

Ersetzen Sie certs.jks einfach durch die Zertifikatdatenbankdatei Ihrer Umgebung. Mit diesem Befehl werden auch die Alias der einzelnen Zertifikate angezeigt, die für den Export erforderlich sind.

Führen Sie den folgenden Befehl aus, um ein einzelnes Zertifikat im PEM-Format zu exportieren:

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

Ersetzen Sie certs.jks einfach durch die Zertifikatdatenbankdatei Ihrer Umgebung und geben Sie einen alias und alias.pem für das zu exportierende Zertifikat an.

Weitere Informationen finden Sie im englischsprachigen Handbuch Java Platform, Standard Edition Tools Reference: keytool.

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

Mit certutil lässt sich der folgende Befehl ausgeben, um alle Zertifikate in Ihrem Zertifikatspeicher zusammen mit dem Alias aufzulisten, mit dem Sie sie exportieren können:

certutil -L -d certdir

Ersetzen Sie certdir einfach durch den Zertifikatdatenbankpfad Ihrer Umgebung. Mit diesem Befehl werden auch die Alias der einzelnen Zertifikate angezeigt, die für den Export erforderlich sind.

Führen Sie den folgenden Befehl aus, um ein einzelnes Zertifikat im PEM-Format zu exportieren:

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

Ersetzen Sie certdir einfach durch den Zertifikatdatenbankpfad Ihrer Umgebung und geben Sie einen cert-name und cert.pem für das zu exportierende Zertifikat an.

Weitere Informationen finden Sie im offiziellen Nutzerhandbuch zu NSS Tools certutil sowie in der Dokumentation Ihres Betriebssystems.

Wie drucke ich PEM-Zertifikate menschenlesbar aus?

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

# 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 Sie den Befehl

openssl x509 -in GTS_Root_R1.pem -text

ausführen, 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 finden Sie unter OpenSSL herunterladen.

Zertifikate mit dem Java-Keytool drucken

Wenn Sie den Befehl

keytool -printcert -file GTS_Root_R1.pem

ausführen, 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 finden Sie 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 Sie die vertrauenswürdigen Root-Zertifikate erfolgreich in PEM-Dateien exportiert haben oder Ihr Root-Zertifikatspeicher bereits PEM-Dateien enthält, können Sie die Dateien in einem beliebigen Texteditor öffnen, da sie im „Nur Text“-Format vorliegen.

In manchen Fällen sind die Zertifikate in der PEM-Datei einwandfrei gekennzeichnet und die Datei liefert visuell lesbare Informationen der zugehörigen Zertifizierungsstelle (z. B. aus dem Paket vertrauenswürdiger Root-Zertifizierungsstellen 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 ist möglicherweise dem Namen der Datei, z. B. GTS_Root_R1.pem, zu entnehmen, 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-Zertifizierungsstellen 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 Ihrem Root-Zertifikatspeicher abzugleichen, entweder nach Issuer oder indem Sie die Zertifikatstrings in der PEM-Datei vergleichen.

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

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, Ihrer Programmiersprache(n) und aller externen Bibliotheken, die Ihre Anwendung verwendet.

Alle anderen Informationsquellen einschließlich dieser FAQs 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 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 außerdem die FAQs zu Google Trust Services ansehen.

Weiterführende Informationen, etwa zum „Certificate Pinning“, sind im Artikel Certificate and Public Key Pinning des Open Web Application Security Project (OWASP) und im Pinning Cheat Sheet verfügbar. Android-spezifische Anleitungen finden Sie 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 finden Sie auch in den Best Practices zu Sicherheit und Datenschutz 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 inoffiziellen Android-Forks beruhen, z. B. LineageOS, finden Sie in den entsprechenden Repositories des Betriebssystemanbieters.