Najczęstsze pytania dotyczące migracji głównego urzędu certyfikacji w Google Maps Platform

Niniejszy dokument obejmuje następujące sekcje:

Bardziej szczegółowe informacje znajdziesz w artykule O co chodzi?.

Terminologia

Poniżej znajdziesz listę najważniejszych terminów, które musisz znać, aby zrozumieć ten dokument. Szersze omówienie powiązanej terminologii znajdziesz w odpowiedziach na najczęstsze pytania dotyczące Google Trust Services.

Certyfikat TLS/SSL
Certyfikat wiąże klucz kryptograficzny z tożsamością.
Certyfikaty TLS/SSL służą do uwierzytelniania i nawiązywania bezpiecznych połączeń z witrynami. Certyfikaty są wystawiane i podpisywane kryptograficznie przez podmioty znane jako urzędy certyfikacji.
Przeglądarki korzystają z certyfikatów wydawanych przez zaufane urzędy certyfikacji, aby mieć pewność, że przesyłane informacje są wysyłane na właściwy serwer i są szyfrowane podczas przesyłania.
Secure Sockets Layer (SSL)
Protokół Secure Sockets Layer był najczęściej stosowanym protokołem do szyfrowania komunikacji internetowej. Protokół SSL nie jest już uważany za bezpieczny i nie jest już obsługiwany w usługach Google.
Transport Layer Security (TLS)
Protokół TLS jest następcą protokołu SSL.
Urząd certyfikacji
Urząd certyfikacji jest jak cyfrowe biuro paszportowe dla urządzeń i osób. Wystawia ona chronione kryptograficznie dokumenty (certyfikaty), które potwierdzają, że podmiot (np. witryna) jest tym, za kogo się podaje.
Przed wydaniem certyfikatu urzędy certyfikacji są odpowiedzialne za sprawdzenie, czy nazwy w certyfikacie są powiązane z osobą lub podmiotem, który o niego prosi.
Termin „urząd certyfikacji” może odnosić się zarówno do organizacji takich jak Google Trust Services, jak i do systemów, które wystawiają certyfikaty.
Infrastruktura klucza publicznego (PKI)
Infrastruktura kluczy publicznych to zestaw technologii, zasad i procedur, które umożliwiają urzędowi certyfikacji weryfikowanie tożsamości osoby przesyłającej prośbę o certyfikat, tworzenie certyfikatu potwierdzającego tę weryfikację oraz korzystanie z certyfikatu przez użytkowników internetu.
Umożliwia to kryptografia klucza publicznego.
PKI jest też używana w sieciach wewnętrznych, ale najczęściej służy do włączania szyfrowanej komunikacji w internecie. Przeglądarki internetowe ufają certyfikatom wydanym przez urzędy certyfikacji uwzględnione w ich magazynie certyfikatów głównych.
Kryptografia klucza publicznego
Kryptografia klucza publicznego to forma kryptografii wykorzystująca pary kluczy. Jeden z kluczy jest publiczny i można go rozpowszechniać, a drugi jest prywatny i musi być utrzymywany w tajemnicy.
Dane zaszyfrowane za pomocą klucza publicznego można odszyfrować za pomocą odpowiedniego klucza prywatnego i odwrotnie.
Umożliwia to stosowanie koncepcji podpisów cyfrowych i szyfrowania kluczem publicznym, które są podstawowymi elementami protokołów takich jak TLS. W ich przypadku 2 strony mogą się wzajemnie uwierzytelniać i udostępniać sobie zaszyfrowane dane bez wcześniejszej wymiany informacji tajnych.
Magazyn certyfikatów głównych (lub magazyn zaufanych certyfikatów)
Magazyn certyfikatów głównych zawiera zestaw urzędów certyfikacji zaufanych przez dostawcę oprogramowania aplikacji. Większość przeglądarek i systemów operacyjnych ma własny magazyn certyfikatów głównych.
Aby zostać uwzględniony w magazynie certyfikatów głównych, urząd certyfikacji musi spełniać rygorystyczne wymagania określone przez dostawcę oprogramowania aplikacji.
Zwykle obejmują one zgodność ze standardami branżowymi, takimi jak wymagania CA/Browser Forum.
Główny urząd certyfikacji
Główny urząd certyfikacji (a dokładniej jego certyfikat) to najwyższy certyfikat w łańcuchu certyfikatów.
Główne certyfikaty CA są zwykle podpisane samodzielnie. Powiązane z nimi klucze prywatne są przechowywane w wysoce zabezpieczonych obiektach i utrzymywane w stanie offline, aby chronić je przed nieautoryzowanym dostępem.
Pośredni urząd certyfikacji
Pośredni urząd certyfikacji (a dokładniej jego certyfikat) to certyfikat używany do podpisywania innych certyfikatów w łańcuchu certyfikatów.
Pośrednie urzędy certyfikacji istnieją głównie po to, aby umożliwić wystawianie certyfikatów online, a jednocześnie pozostawić główny certyfikat CA w trybie offline.
Pośrednie urzędy certyfikacji są też nazywane podrzędnymi urzędami certyfikacji.
Wydający urząd certyfikacji
Urząd certyfikacji wydający certyfikaty, a dokładniej jego certyfikat, to certyfikat używany do podpisywania certyfikatu znajdującego się na samym dole łańcucha certyfikatów.
Ten certyfikat na samym dole jest zwykle nazywany certyfikatem subskrybenta, certyfikatem jednostki końcowej lub certyfikatem liścia. W tym dokumencie będziemy też używać terminu certyfikat serwera.
Łańcuch certyfikatów
Certyfikaty są powiązane z wydawcą (podpisane kryptograficznie przez niego). Łańcuch certyfikatów składa się z certyfikatu liścia, wszystkich certyfikatów wystawcy i certyfikatu głównego.
Podpisywanie krzyżowe
Klienci dostawców oprogramowania aplikacji muszą zaktualizować magazyn certyfikatów głównych, aby uwzględnić nowe certyfikaty CA, które będą zaufane przez ich produkty. Zanim produkty zawierające nowe certyfikaty urzędu certyfikacji staną się powszechnie używane, minie trochę czasu.
Aby zwiększyć zgodność ze starszymi klientami, certyfikaty CA mogą być „podpisane krzyżowo” przez inny, starszy i uznany urząd certyfikacji. W ten sposób utworzysz drugi certyfikat urzędu certyfikacji dla tej samej tożsamości (nazwy i pary kluczy).
W zależności od urzędów certyfikacji uwzględnionych w magazynie certyfikatów głównych klienci będą tworzyć różne łańcuchy certyfikatów aż do głównego urzędu certyfikacji, któremu ufają.

Informacje ogólne

O co chodzi?

Podsumowanie: jeśli nie zastosujesz się do wskazówek podanych na stronie https://pki.goog/faq/#connecting-to-google, istnieje duże prawdopodobieństwo, że w przyszłości wystąpią przerwy w działaniu usług związane z certyfikatami.

Koncepcja

W 2017 r. Google rozpoczęło wieloletni projekt polegający na wydawaniu i używaniu własnych certyfikatów głównych, czyli podpisów kryptograficznych, które są podstawą zabezpieczeń internetowych TLS używanych przez protokół HTTPS.

Po pierwszym etapie zabezpieczenia TLS usług Platformy Map Google były zapewniane przez GS Root R2, bardzo dobrze znanego i szeroko zaufanego głównego urzędu certyfikacji, który Google przejął od GMO GlobalSign, aby ułatwić przejście na własne certyfikaty główne Google Trust Services (GTS).

Praktycznie wszyscy klienci TLS (np. przeglądarki internetowe, smartfony i serwery aplikacji) ufali temu certyfikatowi głównemu, dzięki czemu w pierwszej fazie migracji mogli nawiązać bezpieczne połączenie z serwerami Platformy Map Google.

Urząd certyfikacji NIE MOŻE jednak z założenia wystawiać certyfikatów, które są ważne po upływie terminu ważności jego własnego certyfikatu. Certyfikat GS Root R2 wygasł 15 grudnia 2021 r., więc Google przeniosło swoje usługi na nowy urząd certyfikacji GTS Root R1 Cross, używając certyfikatu wydanego przez własny główny urząd certyfikacji GTS Root R1.

Chociaż większość nowoczesnych systemów operacyjnych i bibliotek klienta TLS już ufa głównym urzędom certyfikacji GTS, aby zapewnić płynne przejście w przypadku większości starszych systemów, Google uzyskało podpis krzyżowy od GMO GlobalSign przy użyciu GlobalSign Root CA – R1, jednego z najstarszych i najbardziej zaufanych dostępnych głównych urzędów certyfikacji.

Dlatego większość klientów Google Maps Platform powinna już rozpoznawać jeden z tych zaufanych głównych urzędów certyfikacji (lub oba), a druga faza migracji nie powinna mieć na nich żadnego wpływu.

Dotyczy to również klientów, którzy podjęli działania w pierwszej fazie migracji w 2018 r., pod warunkiem że postąpili zgodnie z naszymi instrukcjami, instalując wszystkie certyfikaty z naszego zaufanego pakietu głównych urzędów certyfikacji Google. Powinni oni sprawdzać, czy ten plik został zaktualizowany, i aktualizować swój magazyn zaufania co najmniej raz na 6 miesięcy.

Jeśli masz problemy z połączeniem z usługami Google Maps Platform, sprawdź swoje systemy, jeśli:

  • Twoje usługi działają na niestandardowych lub starszych platformach albo utrzymujesz własny sklep z certyfikatami głównymi.
  • w latach 2017–2018, podczas pierwszej fazy migracji głównego urzędu certyfikacji Google, nie podjęto żadnych działań lub nie zainstalowano pełnego zestawu certyfikatów z zaufanego pakietu głównego urzędu certyfikacji Google.

Jeśli powyższe warunki są spełnione, klienci mogą wymagać aktualizacji o zalecane certyfikaty główne, aby zapewnić nieprzerwane korzystanie z Google Maps Platform w tej fazie migracji.

Więcej szczegółów technicznych znajdziesz poniżej. Ogólne instrukcje znajdziesz w sekcji Jak sprawdzić, czy magazyn certyfikatów głównych wymaga aktualizacji.

Zalecamy też, aby nadal synchronizować sklepy z certyfikatami głównymi z powyższym pakietem wyselekcjonowanych głównych urzędów certyfikacji, aby zabezpieczyć usługi przed przyszłymi zmianami głównych urzędów certyfikacji. Będziemy jednak informować o nich z wyprzedzeniem. Więcej informacji o tym, jak być na bieżąco, znajdziesz w sekcjach Jak otrzymywać aktualizacje dotyczące tego etapu migracji? i Jak otrzymywać powiadomienia o przyszłych migracjach?.

Podsumowanie techniczne

Zgodnie z informacją opublikowaną 15 marca 2021 r. na blogu Google Security, GS Root R2, czyli główny urząd certyfikacji używany przez Google Maps Platform od początku 2018 r., wygasł 15 grudnia 2021 r. Dlatego Google przeniesie się na nowo wydany urząd certyfikacji GTS Root R1 Cross.

Prawie wszystkie nowoczesne klienty i systemy TLS są już wstępnie skonfigurowane z certyfikatem GTS Root R1 lub powinny go otrzymać w ramach zwykłych aktualizacji oprogramowania. Certyfikat GlobalSign Root CA – R1 powinien być dostępny nawet w starszych systemach.

Jednak przynajmniej weryfikuj swoje systemy, jeśli spełnione są oba te warunki:

  • Twoje usługi działają na niestandardowych lub starszych platformach albo utrzymujesz własny sklep z certyfikatami głównymi.
  • w latach 2017–2018, podczas pierwszej fazy migracji głównego urzędu certyfikacji Google, nie podjęto żadnych działań lub nie zainstalowano pełnego zestawu certyfikatów z zaufanego pakietu głównego urzędu certyfikacji Google.

W artykule Jak sprawdzić, czy sklep z certyfikatami głównymi wymaga aktualizacji znajdziesz wskazówki, jak sprawdzić, czy Twój system będzie dotknięty tym problemem.

Szczegółowe informacje znajdziesz w odpowiedzi na pytanie Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównych certyfikatów CA Google?.

Jak otrzymywać informacje o tym etapie migracji?

Oznacz gwiazdką publiczny problem 186840968, aby otrzymywać powiadomienia o aktualizacjach. Te najczęstsze pytania są też aktualizowane w trakcie procesu migracji, gdy napotykamy tematy, które mogą być interesujące dla ogółu użytkowników.

Jak mogę otrzymywać wcześniejsze powiadomienia o przyszłych migracjach?

Nowe certyfikaty główne będą ogłaszane na stronie https://pki.goog/updates/. Możesz zasubskrybować kanał RSS, aby otrzymywać powiadomienia o aktualizacjach. Ogłaszamy tylko nowe korzenie. Zmiany łańcucha certyfikatów polegające na przełączaniu się między starszymi certyfikatami głównymi nie są ogłaszane i mogą nastąpić w dowolnym momencie. Aby zapewnić niezawodne połączenia z Google, nie możesz przypinać do pojedynczego głównego lub pośredniego certyfikatu głównego. Musisz ufać pełnemu zestawowi certyfikatów głównych Google, o których mowa na stronie https://pki.goog/faq/#connecting-to-google.

Zalecamy śledzenie bloga Google o bezpieczeństwie. Po opublikowaniu informacji na blogu będziemy też starali się jak najszybciej aktualizować dokumentację poszczególnych usług.

Zasubskrybuj też powiadomienia Google Maps Platform, ponieważ regularnie publikujemy na forum aktualizacje dotyczące zmian, które mogą mieć wpływ na większą liczbę klientów.

Korzystamy z wielu usług Google. Czy migracja głównego urzędu certyfikacji wpłynie na wszystkie te certyfikaty?

Tak, migracja głównego urzędu certyfikacji nastąpi we wszystkich usługach i interfejsach API Google, ale harmonogram może się różnić w zależności od usługi. Gdy jednak sprawdzisz, że magazyny certyfikatów głównych używane przez aplikacje klienckie Platformy Map Google zawierają wszystkie urzędy certyfikacji wymienione w zaufanym pakiecie głównych urzędów certyfikacji Google, Twoje usługi nie powinny być objęte trwającą migracją. Synchronizowanie tych magazynów (co najmniej raz na 6 miesięcy) ochroni Cię też przed przyszłymi zmianami głównych urzędów certyfikacji.

Więcej informacji znajdziesz w odpowiedziach na pytania:Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem certyfikatów głównych CA Google? i Jakie rodzaje aplikacji są narażone na awarie?.

W artykule Jak sprawdzić, czy sklep z certyfikatami głównymi wymaga aktualizacji znajdziesz też ogólne instrukcje testowania systemu.

Jak sprawdzić, czy magazyn certyfikatów głównych wymaga aktualizacji

Przetestuj środowisko aplikacji pod kątem wszystkich certyfikatów głównych w sekcji „Root CAs” na stronie https://pki.goog/repository/.

System będzie na ogół zgodny ze zmianami głównych urzędów certyfikacji, jeśli:

  • usługa działa w ramach obsługiwanego systemu operacyjnego, a zarówno system operacyjny, jak i biblioteki używane przez usługę są aktualne i nie prowadzisz własnego magazynu certyfikatów głównych lub:
  • postępujesz zgodnie z naszymi poprzednimi zaleceniami i masz zainstalowane wszystkie certyfikaty główne z zaufanego pakietu certyfikatów głównych Google oraz regularnie aktualizujesz swój magazyn zaufanych certyfikatów;

Klienci, których może dotyczyć ten problem, powinni natychmiast zainstalować certyfikaty z zaufanego pakietu certyfikatów głównych CA Google, aby uniknąć przyszłych przerw w działaniu usługi.

Szczegółowe informacje znajdziesz w odpowiedzi na pytanie Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównych certyfikatów CA Google?.

Czy istnieje narzędzie, za pomocą którego mogę zweryfikować nasz sklep z certyfikatami głównymi?

Podczas analizy mogą Ci się przydać 2 narzędzia wiersza poleceń: curl i openssl. Oba są dostępne na większości platform i oferują wiele opcji testowania konfiguracji.

Instrukcje pobierania curl znajdziesz w sekcji Pobieranie narzędzia curl poniżej.

Polecenia openssl podane poniżej dotyczą wersji 1.1.1 lub nowszej. Wersje starsze niż 1.1.1 nie są już obsługiwane. Jeśli używasz starszej wersji, uaktualnij lub zmodyfikuj te polecenia w odpowiedni sposób. Instrukcje uzyskiwania openssl znajdziesz w sekcji Uzyskiwanie OpenSSL poniżej.

Więcej przydatnych narzędzi znajdziesz w sekcji Gdzie mogę znaleźć potrzebne narzędzia? poniżej.

Konkretne instrukcje testowania znajdziesz w artykule Jak sprawdzić, czy magazyn certyfikatów głównych wymaga aktualizacji.

Testowanie domyślnego magazynu głównych certyfikatów

Ten przykład dotyczy GTS R1. Testy należy przeprowadzić na wszystkich certyfikatach głównych GTS.

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;

Weryfikowanie zaufanego pakietu certyfikatów głównych Google

Pobierz pakiet zaufanych certyfikatów głównych Google, a potem wykonaj te czynności:

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

Jak i kiedy będzie kontynuowana migracja głównego urzędu certyfikacji Google z 2017 r.?

  1. Pierwszy etap (migracja do GS Root R2), ogłoszony w styczniu 2017 r., rozpoczął się pod koniec 2017 r. i zakończył w pierwszej połowie 2018 r.
  2. Drugi etap (przenoszenie do GTS Root R1 Cross) został ogłoszony w marcu 2021 r. i wdrożony w miesiącach poprzedzających wygaśnięcie certyfikatu GS Root R2 w dniu 15 grudnia 2021 r.

Harmonogramy nowych certyfikatów głównych będą ogłaszane z dużym wyprzedzeniem przed wygaśnięciem przyszłych certyfikatów, ale przejścia między istniejącymi certyfikatami głównymi nie będą ogłaszane.

Zadbaj o przyszłość swoich aplikacji, synchronizując sklep z certyfikatami głównymi z wyselekcjonowaną listą głównych urzędów certyfikacji w zaufanym pakiecie głównych urzędów certyfikacji Google.

Więcej informacji znajdziesz w odpowiedzi na pytanie Dlaczego warto synchronizować magazyn certyfikatów głównych z pakietem zaufanych certyfikatów głównych CA Google?.

Ogólny plan wdrożenia każdej usługi Google

  1. Wdrażanie etapowe rozpoczyna się w jednym centrum danych.
  2. Wdrażanie jest stopniowo rozszerzane na kolejne centra danych, aż do uzyskania globalnego zasięgu.
  3. Jeśli na którymkolwiek etapie zostaną wykryte poważne problemy, testy mogą zostać tymczasowo wycofane, dopóki nie zostaną rozwiązane.
  4. Na podstawie opinii z poprzednich iteracji do procesu wdrażania dodawane są kolejne usługi Google, aż wszystkie zostaną przeniesione na nowe certyfikaty.

Kogo, kiedy i gdzie to dotyczy?

Coraz więcej deweloperów korzystających z Google Maps Platform zacznie otrzymywać nowe certyfikaty w miarę przenoszenia kolejnych centrów danych. Zmiany będą w pewnym stopniu zlokalizowane, ponieważ żądania klientów są zwykle przekazywane do serwerów w centrach danych znajdujących się w pobliżu geograficznym.

Nie możemy z wyprzedzeniem określić, kto, kiedy i gdzie zostanie dotknięty tymi zmianami, dlatego zalecamy wszystkim klientom, aby zweryfikowali i zabezpieczyli swoje usługi z dużym wyprzedzeniem przed możliwymi etapami migracji głównego urzędu certyfikacji Google.

Dodatkowe wskazówki znajdziesz w artykule Jak sprawdzić, czy magazyn certyfikatów głównych wymaga aktualizacji.

Na co zwrócić uwagę

Klienci, w których nie skonfigurowano wymaganego certyfikatu głównego, nie będą mogli zweryfikować połączenia TLS z Google Maps Platform. W takiej sytuacji klienci zwykle wyświetlają ostrzeżenie o niepowodzeniu weryfikacji certyfikatu.

W zależności od konfiguracji TLS klienci mogą nadal wysyłać żądanie do Google Maps Platform lub mogą odmówić kontynuowania żądania.

Jakie są minimalne wymagania, które musi spełniać klient TLS, aby komunikować się z Google Maps Platform?

Certyfikaty Google Maps Platform używają alternatywnych nazw podmiotów (SAN) DNS, więc obsługa certyfikatów klienta musi obsługiwać nazwy SAN, które mogą zawierać pojedynczy symbol wieloznaczny jako etykietę po lewej stronie nazwy, np. *.googleapis.com.

Starsze wersje TLS 1.0 i 1.1 są nadal obsługiwane, ale odradzamy ich używanie i zalecamy korzystanie z TLS 1.3, jeśli to możliwe.

Inne wymagania i rekomendacje znajdziesz w sekcjach Jakie są zalecane wymagania dotyczące klienta TLS, aby mógł komunikować się z Google? i Dlaczego wiele usług Google nadal zezwala na połączenia przy użyciu protokołów TLS 1.0 i TLS 1.1? w najczęstszych pytaniach dotyczących GTS.

Które rodzaje aplikacji są narażone na awarię?

Aplikacja używa systemowego magazynu certyfikatów głównych bez żadnych ograniczeń nałożonych przez dewelopera.

Aplikacje usług internetowych Google Maps Platform

Jeśli używasz popularnego systemu operacyjnego, który jest nadal utrzymywany i regularnie aktualizowany, domyślny magazyn certyfikatów głównych powinien już zawierać certyfikaty główne GTS.

Jeśli używasz starszej wersji systemu operacyjnego, która nie otrzymuje już aktualizacji, możesz mieć certyfikaty główne GTS lub nie. Jednak Twój magazyn certyfikatów głównych prawdopodobnie będzie zawierać certyfikat GlobalSign Root CA – R1, czyli jeden z najstarszych i najbardziej zaufanych głównych urzędów certyfikacji, który jest używany do wzajemnego podpisywania głównych urzędów certyfikacji GTS w razie potrzeby.

W przypadku aplikacji mobilnych, które wywołują usługi internetowe platformy Map Google bezpośrednio z urządzenia użytkownika, obowiązują wytyczne z odpowiedzi na pytanie Czy aplikacje mobilne są narażone na awarie?.

Aplikacje Google Maps Platform po stronie klienta

Aplikacje korzystające z interfejsu Maps JavaScript API zwykle opierają się na certyfikatach głównych przeglądarki internetowej, w której są uruchamiane. Więcej informacji znajdziesz w sekcji Czy aplikacje JavaScript są narażone na awarie?.

W przypadku aplikacji mobilnych korzystających z dowolnego pakietu SDK Map Google na Androida, pakietu SDK Map Google na iOS, pakietu SDK Miejsc na Androida lub pakietu SDK Miejsc na iOS obowiązują te same zasady co w przypadku aplikacji wywołujących usługi internetowe Google Maps Platform.

Więcej informacji znajdziesz w odpowiedzi na pytanie Czy aplikacje mobilne są narażone na awarie?.

Aplikacja używa własnego pakietu certyfikatów lub zaawansowanych funkcji zabezpieczeń, takich jak przypinanie certyfikatów.

Musisz samodzielnie zaktualizować pakiet certyfikatów. Jak wspomnieliśmy w odpowiedzi na pytanie Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem certyfikatów głównych Google?, zalecamy zaimportowanie wszystkich certyfikatów z zaufanego pakietu certyfikatów głównych Google do własnego magazynu certyfikatów głównych i regularne aktualizowanie tego magazynu.

Google odradza przypinanie certyfikatów lub kluczy publicznych w przypadku domen Google, z którymi łączy się Twoja aplikacja. Jeśli przypniesz, istnieje zwiększone ryzyko złamania.

Więcej informacji o przypinaniu certyfikatów lub kluczy publicznych znajdziesz w zasobach zewnętrznych wymienionych w odpowiedzi na pytanie Potrzebujesz więcej informacji?.

Dlaczego warto synchronizować magazyn certyfikatów głównych z pakietem zaufanych głównych urzędów certyfikacji Google?

Wyselekcjonowana lista głównych urzędów certyfikacji w zaufanym pakiecie głównych urzędów certyfikacji Google obejmuje wszystkie urzędy certyfikacji, które mogą być w najbliższej przyszłości używane przez usługi Google.

Dlatego, jeśli chcesz zabezpieczyć swój system na przyszłość, zdecydowanie zalecamy sprawdzenie, czy Twój magazyn certyfikatów głównych zawiera wszystkie certyfikaty z pakietu, i regularne synchronizowanie tych dwóch elementów co najmniej raz na 6 miesięcy.

Jest to szczególnie ważne, jeśli Twoje usługi działają w nieobsługiwanej wersji systemu operacyjnego, z innych powodów nie możesz aktualizować systemu operacyjnego i bibliotek lub prowadzisz własny sklep z certyfikatami głównymi.

Odpowiedź na pytanie Jak mogę otrzymywać wcześniejsze powiadomienia o przyszłych migracjach? zawiera informacje o tym, jak otrzymywać aktualizacje dotyczące przyszłych migracji głównych urzędów certyfikacji. Regularne synchronizowanie magazynu certyfikatów głównych z wyselekcjonowaną listą zabezpieczy Twoje usługi przed przyszłymi przerwami w działaniu spowodowanymi zmianami urzędów certyfikacji i umożliwi ich działanie po wygaśnięciu certyfikatów GTS Root R1 Cross i GlobalSign Root CA – R1.

Zapoznaj się też z odpowiedzią na pytanie:Tworzę produkt, który łączy się z usługami Google. Jakie certyfikaty urzędu certyfikacji muszę uznać za zaufane? Więcej rekomendacji znajdziesz w tym artykule.

Dlaczego nie należy instalować certyfikatów liściowych ani certyfikatów przejściowych urzędów certyfikacji?

W ten sposób ryzykujesz, że w dowolnym momencie, gdy zarejestrujemy nowy certyfikat lub zmienimy pośrednie urzędy certyfikacji, Twoja aplikacja przestanie działać. Może to nastąpić w dowolnym momencie i bez uprzedniego powiadomienia. Dotyczy to zarówno pojedynczych certyfikatów serwera, takich jak te obsługiwane przez maps.googleapis.com, jak i naszych pośrednich urzędów certyfikacji, np. GTS Root R1 Cross.

Aby chronić swoje usługi przed tym zagrożeniem, instaluj tylko certyfikaty główne z zaufanego pakietu głównych urzędów certyfikacji Google i polegaj wyłącznie na certyfikacie głównym w celu weryfikacji wiarygodności całego łańcucha certyfikatów, do którego jest on przypisany.

Każda nowoczesna implementacja biblioteki TLS powinna być w stanie automatycznie zweryfikować takie łańcuchy zaufania, o ile główny urząd certyfikacji jest zaufany.

Czy aplikacje w JavaScript mogą przestać działać?

Certyfikaty główne GTS są już dobrze osadzone i zaufane przez większość nowoczesnych przeglądarek, a podpis krzyżowy od GlobalSign powinien zapewnić płynną migrację nawet w przypadku większości użytkowników korzystających ze starszych przeglądarek. Obejmuje to wszystkie oficjalnie obsługiwane przeglądarki w przypadku interfejsu Maps JavaScript API.

Każda nowoczesna przeglądarka powinna umożliwiać użytkownikom weryfikowanie i zwykle edytowanie certyfikatów, którym ufa przeglądarka. Dokładna lokalizacja różni się w zależności od przeglądarki, ale listę certyfikatów można zwykle znaleźć w sekcji Ustawienia.

Czy aplikacje mobilne są narażone na awarie?

Urządzenia z Androidem i Apple iOS, które nadal otrzymują regularne aktualizacje od producenta, również powinny być odporne na przyszłe zmiany. Większość starszych modeli telefonów z Androidem zawiera co najmniej certyfikat GlobalSign Root CA – R1, chociaż lista zaufanych certyfikatów może się różnić w zależności od producenta telefonu, modelu urządzenia i wersji Androida.

Jednak w przypadku wersji Androida starszych niż 10 obsługa głównych urzędów certyfikacji GTS, w tym GTS Root R1, może być ograniczona.

W przypadku urządzeń z iOS firma Apple prowadzi na swoich stronach pomocy listę zaufanych głównych urzędów certyfikacji dla każdej z najnowszych wersji iOS. Jednak wszystkie wersje iOS 5 i nowsze obsługują główny certyfikat CA GlobalSign – R1.

Główne urzędy certyfikacji GTS, w tym GTS Root R1, są obsługiwane od wersji iOS 12.1.3.

Więcej informacji znajdziesz w odpowiedzi na pytanie Jak sprawdzić zaufane certyfikaty główne na telefonie komórkowym?.

Kiedy moje przeglądarka lub system operacyjny będą zawierać certyfikaty główne Google Trust Services?

W ciągu ostatnich lat Google ściśle współpracował ze wszystkimi głównymi firmami zewnętrznymi, które utrzymują powszechnie używane i zaufane pakiety certyfikatów głównych. Przykłady to producenci systemów operacyjnych, tacy jak Apple i Microsoft, ale też zespoły Google zajmujące się Androidem i ChromeOS; deweloperzy przeglądarek, tacy jak Mozilla, Apple, Microsoft, ale też zespół Google zajmujący się Chrome; producenci sprzętu, np. telefonów, dekoderów, telewizorów, konsol do gier czy drukarek.

Dlatego jest bardzo prawdopodobne, że każdy aktywnie utrzymywany system obsługuje już główne urzędy certyfikacji GTS, a nawet starsze systemy najprawdopodobniej obsługują główny urząd certyfikacji GlobalSign – R1, który będzie używany do podpisywania krzyżowego wielu certyfikatów wydawanych przez Google w najbliższych latach.

Jednak terminy uwzględniania certyfikatów innych firm w dużej mierze wykraczają poza kontrolę Google, dlatego najlepszą ogólną radą, jaką możemy Ci zaoferować, jest regularne stosowanie dostępnych aktualizacji systemu.

Wybrane firmy zewnętrzne, takie jak program certyfikacji CA Mozilla, mogą mieć udokumentowane własne harmonogramy uwzględniania certyfikatów.

Rozwiązywanie problemów

Gdzie mogę znaleźć potrzebne narzędzia?

Podkręcanie

Jeśli Twoja dystrybucja systemu operacyjnego nie udostępnia curl, możesz pobrać go ze strony https://curl.haxx.se/. Możesz pobrać kod źródłowy i samodzielnie skompilować narzędzie lub pobrać wstępnie skompilowany plik binarny, jeśli jest dostępny dla Twojej platformy.

Pobieranie OpenSSL

Jeśli Twoja dystrybucja systemu operacyjnego nie udostępnia openssl, możesz pobrać źródło z https://www.openssl.org/ i skompilować narzędzie. Listę plików binarnych utworzonych przez inne firmy znajdziesz na stronie https://www.openssl.org/community/binaries.html. Żadna z tych kompilacji nie jest jednak obsługiwana ani w żaden sposób rekomendowana przez zespół OpenSSL.

Pobieranie narzędzi Wireshark, Tshark lub Tcpdump

Większość dystrybucji Linuksa oferuje wireshark, a jego narzędzia wiersza poleceń tshark i tcpdump. Wstępnie skompilowane wersje pierwszych dwóch narzędzi dla innych systemów operacyjnych można znaleźć na stronie https://www.wireshark.org.

Kod źródłowy Tcpdump i LibPCAP znajdziesz na stronie https://www.tcpdump.org.

Dokumentację tych przydatnych narzędzi znajdziesz w Przewodniku użytkownika Wiresharka, na stronie podręcznika Tshark i na stronie podręcznika Tcpdump.

Pobieranie narzędzia keytool w języku Java

Narzędzie wiersza poleceń keytool powinno być dostarczane z każdą wersją pakietu Java Development Kit (JDK) lub środowiska Java Runtime Environment (JRE). Zainstaluj te certyfikaty, aby uzyskać keytool.. Używanie keytool jest jednak mało prawdopodobne, aby było konieczne do weryfikacji certyfikatu głównego, chyba że aplikacja jest zbudowana w języku Java.

Co zrobić w przypadku awarii w środowisku produkcyjnym

Głównym działaniem, które musisz wykonać, jest zainstalowanie wymaganych certyfikatów głównych z zaufanego pakietu głównych certyfikatów CA Google w magazynie certyfikatów głównych używanym przez Twoją aplikację.

  1. Skontaktuj się z administratorami systemu, aby zaktualizować lokalny magazyn certyfikatów głównych.
  2. W tym artykule z odpowiedziami na najczęstsze pytania znajdziesz wskazówki dotyczące Twojego systemu.
  3. Jeśli potrzebujesz dodatkowej pomocy dotyczącej platformy lub systemu, skorzystaj z kanałów pomocy technicznej oferowanych przez dostawcę systemu.
  4. Aby uzyskać ogólną pomoc, skontaktuj się z naszym zespołem pomocy zgodnie z opisem w sekcji Kontaktowanie się z zespołem pomocy Google Maps Platform. Uwaga: w przypadku problemów dotyczących konkretnych platform wskazówki są udzielane w miarę możliwości.

  5. Oznacz publiczny problem 186840968 gwiazdką, aby otrzymywać dalsze aktualizacje dotyczące migracji.

    Kontaktowanie się z zespołem pomocy Google Maps Platform

Wstępne rozwiązywanie problemów

Ogólne instrukcje rozwiązywania problemów znajdziesz w sekcji Jak sprawdzić, czy magazyn certyfikatów głównych wymaga aktualizacji.

Sekcja Zarządzanie zaufanymi certyfikatami może również zawierać przydatne informacje, jeśli musisz importować lub eksportować certyfikaty główne.

Jeśli problem nadal występuje i zdecydujesz się skontaktować z zespołem pomocy Google Maps Platform, przygotuj się na podanie tych informacji:

  1. Gdzie znajdują się serwery, których dotyczy problem?
  2. Z których adresów IP Google korzysta Twoja usługa?
  3. Których interfejsów API dotyczy ten problem?
  4. Kiedy dokładnie pojawił się problem?

  5. Wyniki tych poleceń:

    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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

Instrukcje dotyczące uzyskiwania wymaganych narzędzi znajdziesz w odpowiedzi na pytanie Gdzie mogę zdobyć potrzebne narzędzia?.

Przesyłanie zgłoszenia do zespołu pomocy

Postępuj zgodnie z instrukcjami tworzenia zgłoszenia na stronie Pomoc i zasoby Google Maps Platform.

Przesyłając zgłoszenie do zespołu pomocy, oprócz danych wymienionych w sekcji Wstępne rozwiązywanie problemów podaj też:

  • Jakie są Twoje publiczne adresy IP?
  • Jaki jest publiczny adres IP Twojego serwera DNS?
  • Jeśli to możliwe, zrzut pakietów tcpdump lub Wireshark z nieudanej negocjacji TLS w odniesieniu do https://maps.googleapis.com/ w formacie PCAP, z wystarczająco długim rozmiarem zrzutu, aby przechwycić cały pakiet bez obcinania go (np. za pomocą -s0 w starszych wersjach tcpdump).
  • Jeśli to możliwe, wyciągi z dzienników usługi pokazujące dokładną przyczynę niepowodzenia połączenia TLS, najlepiej z pełnymi informacjami o łańcuchu certyfikatów serwera.

Instrukcje dotyczące uzyskiwania wymaganych narzędzi znajdziesz w odpowiedzi na pytanie Gdzie mogę zdobyć potrzebne narzędzia?.

Post on public issue 186840968

Gdy publikujesz komentarz w przypadku publicznego problemu 186840968, podaj informacje wymienione w sekcji Wstępne rozwiązywanie problemów.

Jak mogę określić publiczny adres DNS?

W systemie Linux możesz uruchomić to polecenie:

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

W systemie Windows możesz użyć polecenia nslookup w trybie interaktywnym: 

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

Interpretowanie danych wyjściowych polecenia curl

Uruchomienie polecenia curl z flagami -vvI dostarcza wielu przydatnych informacji. Oto kilka wskazówek dotyczących interpretacji wyników:

  • Wiersze zaczynające się od „*” zawierają dane wyjściowe negocjacji TLS, a także informacje o zakończeniu połączenia.
  • Wiersze zaczynające się od „>” wyświetlają wychodzące żądanie HTTP, które wysyła curl.
  • Wiersze zaczynające się od „<” wyświetlają odpowiedź HTTP otrzymaną z serwera.
  • Jeśli protokołem był HTTPS, obecność wierszy „>” lub „<” oznacza udane uzgadnianie TLS.

Używana biblioteka TLS i pakiet certyfikatów głównych

Uruchomienie polecenia curl z flagami -vvI powoduje też wydrukowanie używanego magazynu certyfikatów głównych, ale dokładne dane wyjściowe mogą się różnić w zależności od systemu, jak pokazano tutaj.

Dane wyjściowe z maszyny z systemem Red Hat Linux, na której curl jest połączony z NSS mogą zawierać te wiersze:

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

Dane wyjściowe z urządzenia z systemem Ubuntu lub Debian Linux mogą zawierać te wiersze:

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

Dane wyjściowe z maszyny z systemem Ubuntu lub Debian Linux, która używa głównego certyfikatu Google w pliku PEM podanym za pomocą flagi --cacert, mogą zawierać te wiersze:

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

Klient użytkownika

Żądania wychodzące zawierają nagłówek User-Agent, który może zawierać przydatne informacje o curl i Twoim systemie.

Przykład z komputera z systemem Red Hat Linux:

> 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: */*
>

Nie udało się uzgodnić połączenia TLS

Wiersze takie jak te w tym przykładowym kodzie wskazują, że połączenie zostało przerwane w trakcie uzgadniania połączenia TLS z powodu niezaufanego certyfikatu serwera. Brak danych wyjściowych debugowania rozpoczynających się od > lub < również jest silnym wskaźnikiem nieudanej próby połączenia:

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

Uzgadnianie połączenia TLS zakończone powodzeniem

O pomyślnym uzgodnieniu TLS świadczą podobne wiersze do tych w tym przykładowym kodzie. Należy podać używany pakiet szyfrujący dla zaszyfrowanego połączenia, a także szczegóły zaakceptowanego certyfikatu serwera. Obecność wierszy zaczynających się od > lub < wskazuje, że ruch HTTP z ładunkiem jest przesyłany przez zaszyfrowane połączenie TLS:

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

Jak wydrukować otrzymane certyfikaty serwera w formie czytelnej dla człowieka

Zakładając, że dane wyjściowe są sformatowane w formacie PEM, np. dane wyjściowe z openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, możesz wydrukować certyfikat serwera, wykonując te czynności:

  • Skopiuj cały certyfikat zakodowany w Base64, w tym nagłówek i stopkę:

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

  • Następnie:

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

  • Następnie wklej zawartość bufora kopiowania w terminalu.

  • Naciśnij klawisz Return.

Przykłady danych wejściowych i wyjściowych znajdziesz w sekcji Jak wydrukować certyfikaty PEM w formie czytelnej dla człowieka.

Jak wyglądają certyfikaty Google z podpisem krzyżowym w OpenSSL?

{# disableFinding(LINE_OVER_80)}

…
---
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

---
…

Zarządzanie zaufanymi certyfikatami

Jak mogę sprawdzić zaufane certyfikaty główne na telefonie komórkowym?

Zaufane certyfikaty Androida

Jak wspomnieliśmy w odpowiedzi na pytanie Czy aplikacje mobilne są narażone na awarie?, Od wersji 4.0 Android umożliwia użytkownikom telefonów weryfikowanie listy zaufanych certyfikatów w Ustawieniach. W tej tabeli znajdziesz dokładną ścieżkę do menu Ustawienia:

Wersja Androida Ścieżka menu
1.x, 2.x, 3.x Nie dotyczy
4.x, 5.x, 6.x, 7.x Ustawienia > Zabezpieczenia > Zaufane dane logowania
8.x, 9 Ustawienia > Bezpieczeństwo i lokalizacja > Szyfrowanie i dane logowania > Zaufane dane logowania
10+ Ustawienia > Zabezpieczenia > Zaawansowane > Szyfrowanie i dane logowania > Zaufane dane logowania

Ta tabela ilustruje prawdopodobną dostępność najważniejszych certyfikatów głównych w poszczególnych wersjach Androida na podstawie weryfikacji ręcznej z użyciem dostępnych obrazów systemu Android Virtual Device (AVD) oraz historii wersji repozytorium Git ca-certificates w AOSP, gdy obrazy systemu nie były już dostępne:

Wersja Androida GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (ważny do 15 grudnia 2021 r.)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Aktualizacja magazynu głównych certyfikatów systemu Android jest zwykle niemożliwa bez aktualizacji oprogramowania lub zrootowania urządzenia. Jednak w przypadku większości wersji Androida, które są nadal powszechnie używane, obecny zestaw zaufanych certyfikatów głównych prawdopodobnie zapewni nieprzerwane działanie przez wiele lat, czyli dłużej niż okres użytkowania większości obecnych urządzeń.

Od wersji 7.0 Android oferuje deweloperom aplikacji bezpieczną metodę dodawania zaufanych certyfikatów, które są zaufane tylko przez ich aplikację. W tym celu należy dołączyć certyfikaty do aplikacji i utworzyć niestandardowe ustawienia bezpieczeństwa sieci, zgodnie z opisem w dokumencie szkoleniowym Sprawdzone metody dotyczące bezpieczeństwa i prywatności na Androidzie – Ustawienia bezpieczeństwa sieci.

Jednak deweloperzy aplikacji innych firm nie będą mogli wpływać na konfigurację zabezpieczeń sieci w przypadku ruchu pochodzącego z pliku APK Usług Google Play, więc takie działania prawdopodobnie zapewnią tylko częściowe rozwiązanie.

Na starszych urządzeniach starszego typu jedyną dostępną opcją jest korzystanie z dodanych przez użytkowników urzędów certyfikacji. Mogą one być instalowane przez firmową zasadę grupy stosowaną na urządzeniu użytkownika lub przez samych użytkowników.

Magazyn zaufania iOS

Apple nie wyświetla bezpośrednio domyślnego zestawu zaufanych certyfikatów głównych użytkownikowi telefonu, ale w artykułach pomocy Apple znajdują się linki do zestawów zaufanych głównych urzędów certyfikacji dla systemów iOS w wersji 5 i nowszych:

Wszystkie dodatkowe certyfikaty zainstalowane na urządzeniu z iOS powinny być widoczne w sekcji Ustawienia > Ogólne > Profil. Jeśli nie są zainstalowane żadne dodatkowe certyfikaty, pozycja menu Profil może się nie wyświetlać.

Ta tabela ilustruje dostępność najważniejszych certyfikatów głównych w poszczególnych wersjach iOS na podstawie powyższych źródeł:

Wersja iOS GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (ważny do 15 grudnia 2021 r.)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Gdzie znajduje się magazyn certyfikatów głównych systemu i jak mogę go zaktualizować?

Lokalizacja domyślnego magazynu certyfikatów głównych różni się w zależności od systemu operacyjnego i używanej biblioteki SSL/TLS. Jednak w większości dystrybucji systemu Linux domyślne certyfikaty główne można znaleźć w jednej z tych ścieżek:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, starsze wersje RHEL i CentOS
  • /etc/pki/ca-trust/source/anchors i /usr/share/pki/ca-trust-source: Fedora, nowsze wersje RHEL i CentOS
  • /var/lib/ca-certificates: OpenSUSE

Inne ścieżki certyfikatu mogą obejmować:

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

Niektóre certyfikaty w tych katalogach są prawdopodobnie linkami symbolicznymi do plików w innych katalogach.

Magazyn głównych certyfikatów OpenSSL

W przypadku aplikacji korzystających z OpenSSL możesz sprawdzić skonfigurowaną lokalizację zainstalowanych komponentów, w tym domyślny magazyn certyfikatów głównych, za pomocą tego polecenia:

openssl version -d

Polecenie wyświetla znak OPENSSLDIR, który odpowiada katalogowi najwyższego poziomu, w którym znajdują się biblioteka i jej konfiguracje:

OPENSSLDIR: "/usr/lib/ssl"

Magazyn certyfikatów głównych znajduje się w podkatalogu 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
…

Jeśli OpenSSL korzysta z domyślnego systemowego magazynu certyfikatów głównych, jak w powyższym przykładzie, sprawdź sekcję najwyższego poziomu Gdzie znajduje się mój systemowy magazyn certyfikatów głównych i jak mogę go zaktualizować?, aby upewnić się, że pakiet systemowych certyfikatów głównych jest aktualny.

Instrukcje dotyczące uzyskiwania openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Magazyn certyfikatów głównych Java

Aplikacje Java mogą używać własnego magazynu certyfikatów głównych, który w systemach Linux zwykle znajduje się w lokalizacji /etc/pki/java/cacerts lub /usr/share/ca-certificates-java. Można nim zarządzać za pomocą narzędzia wiersza poleceń Java keytool.

Aby zaimportować pojedynczy certyfikat do magazynu certyfikatów Java, wpisz to polecenie:

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

Zastąp cert.pem plikiem certyfikatu odpowiadającym każdemu zalecanemu certyfikatowi głównemu, alias unikalnym, ale znaczącym aliasem certyfikatu, a certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku.

Więcej informacji znajdziesz w tych artykułach Oracle i Stack Overflow:

Magazyn certyfikatów głównych Mozilla NSS

Aplikacje korzystające z Mozilla NSS mogą domyślnie używać bazy danych certyfikatów w całym systemie, która zwykle znajduje się w /etc/pki/nssdb, lub domyślnego magazynu specyficznego dla użytkownika w ${HOME}/.pki/nssdb.

Do aktualizacji bazy danych NSS użyj narzędzia certutil.

Aby zaimportować pojedynczy plik certyfikatu do bazy danych NSS, wpisz to polecenie:

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

Zastąp cert.pem plikiem certyfikatu odpowiadającym każdemu zalecanemu certyfikatowi głównemu, cert-name – znaczącym pseudonimem certyfikatu, a certdir – ścieżką do bazy danych certyfikatów używanej w Twoim środowisku.

Więcej informacji znajdziesz w oficjalnym podręczniku NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Magazyn certyfikatów głównych Microsoft .NET

Deweloperom korzystającym z platformy .NET w systemie Windows mogą się przydać co najmniej te artykuły Microsoft:

Formaty plików certyfikatów

Co to jest plik PEM?

Privacy-Enhanced Mail (PEM) to standardowy format pliku tekstowego do przechowywania i wysyłania certyfikatów kryptograficznych, kluczy itp., który został sformalizowany jako standard prawny w  RFC 7468.

Sam format pliku jest czytelny dla człowieka, ale informacje o danych certyfikatu binarnego zakodowanych w formacie Base64 nie są. Specyfikacja PEM dopuszcza jednak umieszczanie tekstu wyjaśniającego przed lub po tekście zakodowanego korpusu certyfikatu, a wiele narzędzi korzysta z tej funkcji, aby zapewnić podsumowanie najważniejszych elementów danych w certyfikacie w formie zwykłego tekstu.

Narzędzia takie jak openssl mogą też służyć do dekodowania całego certyfikatu do postaci czytelnej dla człowieka. Więcej informacji znajdziesz w sekcji Jak wydrukować certyfikaty PEM w czytelnej formie.

Co to jest plik „.crt”?

Narzędzia, które umożliwiają eksportowanie certyfikatów w formacie PEM, zwykle używają rozszerzenia „.crt”, aby wskazać, że plik korzysta z kodowania tekstowego.

Co to jest plik DER?

Wyróżniające się reguły kodowania (DER) to standardowy format binarny do kodowania certyfikatów. Certyfikaty w plikach PEM są zazwyczaj certyfikatami DER zakodowanymi w formacie Base64.

Co to jest plik „.cer”?

Wyeksportowany plik z sufiksem „.cer” może zawierać certyfikat zakodowany w formacie PEM, ale zwykle jest to certyfikat binarny, zazwyczaj zakodowany w formacie DER. Zgodnie z konwencją pliki „.cer” zawierają zwykle tylko jeden certyfikat.

System odmawia importowania wszystkich certyfikatów z pliku roots.pem

Niektóre systemy, np. Javakeytool może importować z pliku PEM tylko 1 certyfikat, nawet jeśli zawiera on kilka certyfikatów. Odpowiedź na pytanie Jak wyodrębnić poszczególne certyfikaty z pliku roots.pem? zawiera informacje o tym, jak najpierw podzielić plik.

Jak wyodrębnić poszczególne certyfikaty z pliku roots.pem?

Możesz podzielić roots.pem na poszczególne certyfikaty za pomocą tego skryptu bash:

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

Powinno to spowodować utworzenie kilku pojedynczych plików PEM podobnych do tych wymienionych tutaj:

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

Poszczególne pliki PEM, np. 02265526.pem, można następnie zaimportować oddzielnie lub przekonwertować na format pliku akceptowany przez magazyn certyfikatów.

Jak przekonwertować plik PEM na format obsługiwany przez mój system

Narzędzie wiersza poleceń OpenSSLopenssl umożliwia konwertowanie plików między wszystkimi powszechnie używanymi formatami plików certyfikatów. Poniżej znajdziesz instrukcje konwertowania pliku PEM na najczęściej używane formaty plików certyfikatów.

Pełną listę dostępnych opcji znajdziesz w oficjalnej dokumentacji narzędzi wiersza poleceń OpenSSL.

Instrukcje dotyczące uzyskiwania openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Jak przekonwertować plik PEM na format DER?

Za pomocą narzędzia openssl możesz wydać to polecenie, aby przekonwertować plik z formatu PEM na DER:

openssl x509 -in roots.pem -outform der -out roots.der
Jak przekonwertować plik PEM na PKCS #7?

Za pomocą openssl możesz wydać to polecenie, aby przekonwertować plik z formatu PEM na PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Jak przekonwertować plik PEM na PKCS #12 (PFX)?

Za pomocą openssl możesz wydać to polecenie, aby przekonwertować plik z formatu PEM na PKCS #12:

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

Podczas tworzenia archiwum PKCS #12 musisz podać hasło do pliku. Jeśli nie zaimportujesz od razu pliku PKCS #12 do systemu, przechowuj hasło w bezpiecznym miejscu.

Wyświetlanie, drukowanie i eksportowanie certyfikatów z magazynu certyfikatów głównych

Jak wyeksportować certyfikat z magazynu kluczy Java jako plik PEM?

Za pomocą narzędzia keytool możesz wydać to polecenie, aby wyświetlić listę wszystkich certyfikatów w magazynie certyfikatów wraz z aliasem, którego możesz użyć do wyeksportowania każdego z nich:

keytool -v -list -keystore certs.jks

Zastąp certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku. To polecenie wyświetli też alias każdego certyfikatu, który będzie potrzebny, jeśli chcesz go wyeksportować.

Aby wyeksportować pojedynczy certyfikat w formacie PEM, wpisz to polecenie:

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

Zastąp certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku i podaj alias oraz alias.pem odpowiadające certyfikatowi, który chcesz wyeksportować.

Więcej informacji znajdziesz w podręczniku Java Platform, Standard Edition Tools Reference: keytool{: .external}.

Jak wyeksportować certyfikaty z magazynu certyfikatów głównych NSS jako plik PEM?

Za pomocą narzędzia certutil możesz wydać to polecenie, aby wyświetlić listę wszystkich certyfikatów w magazynie certyfikatów wraz z pseudonimem, którego możesz użyć do wyeksportowania każdego z nich:

certutil -L -d certdir

Zastąp certdir ścieżką do bazy danych certyfikatów używaną w Twoim środowisku. To polecenie wyświetli też pseudonim każdego certyfikatu, który będzie potrzebny, jeśli chcesz go wyeksportować.

Aby wyeksportować pojedynczy certyfikat w formacie PEM, wpisz to polecenie:

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

Zastąp certdir ścieżką do bazy danych certyfikatów używanej w Twoim środowisku i podaj wartości cert-name i cert.pem odpowiadające certyfikatowi, który chcesz wyeksportować.

Więcej informacji znajdziesz w oficjalnym podręczniku NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Drukowanie certyfikatów PEM w formie czytelnej dla człowieka

W poniższych przykładach zakładamy, że masz plik GTS_Root_R1.pem o tej zawartości:

# 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-----
Drukowanie plików certyfikatów za pomocą OpenSSL

Wydawanie polecenia

openssl x509 -in GTS_Root_R1.pem -text

powinno zwrócić wynik podobny do tego:

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
        …

Instrukcje dotyczące uzyskiwania openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Drukowanie certyfikatów za pomocą narzędzia keytool w języku Java

Wydanie tego polecenia

keytool -printcert -file GTS_Root_R1.pem

powinno zwrócić wynik podobny do tego:

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>
]
]

Instrukcje dotyczące uzyskiwania keytool znajdziesz w sekcji Uzyskiwanie narzędzia keytool w języku Java.

Jak sprawdzić, jakie certyfikaty są zainstalowane w magazynie certyfikatów głównych?

Różni się to w zależności od systemu operacyjnego i biblioteki SSL/TLS. Narzędzia, które umożliwiają importowanie i eksportowanie certyfikatów do i z magazynu certyfikatów głównych, zwykle udostępniają też opcję wyświetlania listy zainstalowanych certyfikatów.

Jeśli udało Ci się wyeksportować zaufane certyfikaty główne do plików PEM lub magazyn certyfikatów głównych zawiera już zapisane pliki PEM, możesz spróbować otworzyć te pliki w dowolnym edytorze tekstu, ponieważ jest to format pliku tekstowego.

Plik PEM może być odpowiednio oznaczony, dzięki czemu zawiera informacje czytelne dla człowieka o powiązanym urzędzie certyfikacji (przykład z pakietu zaufanych głównych urzędów certyfikacji 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-----

Plik może też zawierać tylko część certyfikatu. W takich przypadkach nazwa pliku, np. GTS_Root_R1.pem, może wskazywać, do którego urzędu certyfikacji należy certyfikat. Ciąg znaków certyfikatu między tokenami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE----- jest też niepowtarzalny dla każdego urzędu certyfikacji.

Nawet jeśli nie masz powyższych narzędzi, możesz niezawodnie dopasować główne urzędy certyfikacji z pakietu zaufanych głównych urzędów certyfikacji Google do tych z magazynu certyfikatów głównych, ponieważ każdy certyfikat w pakiecie jest prawidłowo oznaczony. Możesz to zrobić za pomocą Issuer lub porównując ciągi certyfikatów w plikach PEM.

Przeglądarki internetowe mogą korzystać z własnego magazynu certyfikatów głównych lub polegać na domyślnym magazynie dostarczonym przez system operacyjny. Wszystkie nowoczesne przeglądarki powinny jednak umożliwiać zarządzanie zestawem zaufanych głównych urzędów certyfikacji lub przynajmniej wyświetlanie tego zestawu. Więcej informacji znajdziesz w odpowiedzi na pytanie Czy aplikacje JavaScript są narażone na awarie?.

Instrukcje dotyczące telefonów komórkowych znajdziesz w odpowiedzi na pytanie Jak sprawdzić zaufane certyfikaty główne na telefonie komórkowym?.

Dodatek

Potrzebujesz więcej informacji?

Zawsze korzystaj przede wszystkim z dokumentacji systemu operacyjnego, dokumentacji języków programowania aplikacji oraz dokumentacji zewnętrznych bibliotek używanych przez aplikację.

Każde inne źródło informacji, w tym te najczęstsze pytania, może być nieaktualne lub w inny sposób nieprawidłowe i nie należy go traktować jako wiarygodnego. Możesz jednak znaleźć przydatne informacje na wielu forach pytań i odpowiedzi Stack Exchange.

Zapoznaj się też z najczęstszymi pytaniami dotyczącymi Google Trust Services.

Jeśli chcesz poznać podstawy kryptografii, infrastruktury klucza publicznego, certyfikatów i łańcuchów certyfikatów, obejrzyj playlistę PKI Bootcamp w YouTube autorstwa Paula Turnera.

Więcej informacji o zaawansowanych tematach, takich jak przypinanie certyfikatów, znajdziesz w artykule Certificate and Public Key Pinning (Przypinanie certyfikatów i kluczy publicznych) oraz w arkuszu z przydatnymi informacjami na temat przypinania organizacji Open Web Application Security Project (OWASP). Instrukcje dotyczące Androida znajdziesz w oficjalnym dokumencie szkoleniowym Android Best Practices for Security & Privacy Security with HTTPS and SSL (w języku angielskim). Więcej informacji o przypinaniu certyfikatów i kluczy publicznych na Androidzie znajdziesz w poście na blogu Matthew Dolana Android Security: SSL Pinning.

Więcej informacji o zarządzaniu dodatkowymi zaufanymi certyfikatami na Androidzie znajdziesz w dokumencie szkoleniowym Sprawdzone metody dotyczące bezpieczeństwa i prywatności na Androidzie w sekcji Konfiguracja bezpieczeństwa sieci.

Pełną listę głównych urzędów certyfikacji zaufanych przez AOSP znajdziesz w repozytorium Git ca-certificates. W przypadku wersji opartych na nieoficjalnych wersjach Androida, np. LineageOS, zapoznaj się z odpowiednimi repozytoriami udostępnionymi przez dostawcę systemu operacyjnego.