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 o trwającej migracji głównego urzędu certyfikacji Google znajdziesz w artykule Co się dzieje?.

Terminologia

Poniżej przedstawiamy listę najważniejszych terminów, które warto znać w tym dokumencie. Bardziej wyczerpujące omówienie powiązanej terminologii znajdziesz w odpowiedziach na najczęstsze pytania dotyczące Google Trust Services.

Certyfikat SSL/TLS
Certyfikat wiąże klucz kryptograficzny z tożsamością.
Certyfikaty SSL/TLS służą do uwierzytelniania i nawiązywania bezpiecznych połączeń ze stronami internetowymi. Certyfikaty są wydawane i podpisywane kryptograficznie przez podmioty nazywane urzędami certyfikacji.
Przeglądarki korzystają z certyfikatów wystawionych przez zaufane urzędy certyfikacji, aby mieć pewność, że przesyłane informacje są wysyłane na właściwy serwer i że są szyfrowane podczas przesyłania.
SSL (Secure Sockets Layer)
Protokół Secure Sockets Layer był najpopularniejszym protokołem używanym do szyfrowania komunikacji w internecie. Protokół SSL nie jest już uważany za bezpieczny i nie należy go używać.
Protokół Transport Layer Security (TLS)
Transport Layer Security to następca protokołu SSL.
Urząd certyfikacji
Urząd certyfikacji jest jak cyfrowy urząd paszportowy dla osób i urządzeń. Udostępnia kryptograficznie chronione dokumenty (certyfikaty), aby potwierdzić, że dany podmiot (np. strona internetowa) jest tym, za kogo się podaje.
Przed wystawieniem certyfikatu urzędy certyfikacji odpowiadają za sprawdzenie, czy nazwy w certyfikacie są powiązane z osobą lub podmiotem, który o niego poprosi.
Termin „urząd certyfikacji” może oznaczać zarówno organizacje, jak Google Trust Services, jak i systemy, które wydają certyfikaty.
Magazyn certyfikatów głównych
Magazyn certyfikatów głównych zawiera zbiór 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 urząd certyfikacji mógł znaleźć się w magazynie certyfikatów głównych, musi spełniać rygorystyczne wymagania określone przez dostawcę oprogramowania do 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 podpisywane samodzielnie. Powiązane z nimi klucze prywatne są przechowywane w bardzo bezpiecznych miejscach i przechowywane w stanie offline, co zabezpiecza je przed nieautoryzowanym dostępem.
Pośredni urząd certyfikacji
Pośredni urząd certyfikacji (lub jego certyfikat) to certyfikat używany do podpisywania innych certyfikatów w łańcuchu certyfikatów.
Pośrednie urzędy certyfikacji służą przede wszystkim do wystawiania certyfikatów online, a jednocześnie umożliwiają pozostawianie certyfikatu głównego CA w trybie offline.
Pośrednie urzędy certyfikacji są też nazywane podrzędnymi urzędami certyfikacji.
Urząd certyfikacji
Urząd certyfikacji, czyli jego certyfikat, to certyfikat używany do podpisywania najniższego certyfikatu w łańcuchu certyfikatów.
Certyfikat ten jest nazywany potocznie certyfikatem subskrypcji, 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 (podpisywane kryptograficznie przez wydawcę). Łańcuch certyfikatów składa się z certyfikatu liścia, wszystkich certyfikatów wystawcy i certyfikatu głównego.
Podpisy krzyżowe
Klienci dostawcy oprogramowania aplikacji muszą zaktualizować magazyn certyfikatów głównych, aby zawierały nowe certyfikaty CA, aby były zaufane dla ich usług. Może minąć trochę czasu, zanim usługi zawierające nowe certyfikaty CA będą powszechnie używane.
Aby zwiększyć zgodność ze starszymi klientami, certyfikaty CA mogą być podpisywane krzyżowo przez inny, starszy urząd certyfikacji. Spowoduje to utworzenie drugiego certyfikatu CA dla tej samej tożsamości (nazwa i para kluczy).
W zależności od tego, jakie urzędy certyfikacji znajdują się w magazynie certyfikatów głównych, klienty tworzą inny łańcuch certyfikatów aż do zaufanego poziomu głównego.

Informacje ogólne

Co się dzieje?

Koncepcja

W 2017 r. firma Google rozpoczęła wieloletni projekt, którego celem było wydawanie i używanie własnych certyfikatów głównych – podpisów kryptograficznych stanowiących podstawę zabezpieczeń internetowych TLS używanych przez HTTPS.

Po zakończeniu pierwszej fazy bezpieczeństwo usług Google Maps Platform zagwarantowało GS Root R2, bardzo znany i powszechnie zaufany główny urząd certyfikacji. Firma Google pozyskała od GMO GlobalSign, aby ułatwić przejście na własne, samodzielnie przyznawane główne urzędy certyfikacji Google Trust Services (GTS).

Praktycznie wszystkie klienty TLS (takie jak przeglądarki internetowe, smartfony i serwery aplikacji) ufają temu certyfikatowi głównemu i dlatego podczas pierwszej fazy migracji udało im się nawiązać bezpieczne połączenie z serwerami Google Maps Platform.

Urząd certyfikacji z założenia nie może jednak wystawiać certyfikatów, które są ważne po upływie terminu ważności własnego certyfikatu. Ponieważ ważność GS Root R2 wygasa 15 grudnia 2021 r., Google przeniesie własne usługi do nowego urzędu certyfikacji GTS Root R1 Cross przy użyciu certyfikatu wystawionego przez główny urząd certyfikacji Google GTS Root R1.

Większość nowoczesnych systemów operacyjnych i bibliotek klienta TLS korzysta już z certyfikatów głównych urzędów certyfikacji GTS. Aby zapewnić płynne przejście na większość starszych systemów, firma Google uzyskała podpis krzyżowy z GMO GlobalSign za pomocą GlobalSign Root CA – R1 – jednego z najstarszych i najbardziej zaufanych głównych urzędów certyfikacji.

Dlatego większość klientów Google Maps Platform rozpoznaje już jeden z tych zaufanych głównych urzędów certyfikacji (albo oba) i druga faza migracji nie będzie mieć na niego wpływu.

Dotyczy to też klientów, którzy podjęli działania podczas pierwszej fazy migracji w 2018 roku, przy założeniu, że przestrzegali wtedy naszych instrukcji i zainstalowali wszystkie certyfikaty z zaufanych głównych urzędów certyfikacji Google.

Sprawdź swoje systemy, jeśli:

  • Twoje usługi obsługują platformy niestandardowe lub starsze albo masz własny magazyn certyfikatów głównych
  • nie podjęto żadnych działań w latach 2017–2018 podczas pierwszej fazy migracji głównego urzędów certyfikacji Google lub nie zainstalowano pełnego zestawu certyfikatów z zaufanego pakietu głównego urzędu certyfikacji Google

Jeśli powyższe warunki mają zastosowanie, konieczne może być zaktualizowanie Twoich klientów przy użyciu zalecanych certyfikatów głównych, aby zapewnić nieprzerwane korzystanie z Google Maps Platform podczas tej fazy migracji.

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

Zalecamy też dalsze synchronizowanie magazynów certyfikatów głównych z powyższym wyselekcjonowanym pakietem głównych urzędów certyfikacji, aby zabezpieczyć swoje usługi na przyszłe zmiany urzędów certyfikacji. Zostanie to jednak ogłoszone z wyprzedzeniem. Dalsze instrukcje znajdziesz w sekcjach Jak uzyskać aktualne informacje o tej fazie migracji i Jak mogę z wyprzedzeniem otrzymać powiadomienia o przyszłych migracji.

Podsumowanie techniczne

Zgodnie z ogłoszeniem na blogu Google o bezpieczeństwie z 15 marca 2021 r. na GS Root R2 główny urząd certyfikacji Google Maps Platform, który był używany na początku 2018 r., wygaśnie 15 grudnia 2021 r. Dlatego w tym roku Google przejdzie na nową wersję CA GTS Root R1 Cross. Oznacza to, że nasze usługi będą stopniowo przechodzić na certyfikaty TLS liści wydane przez ten nowy urząd certyfikacji.

Prawie wszystkie nowoczesne klienty i systemy TLS są już skonfigurowane za pomocą certyfikatu głównego GTS R1 lub powinny otrzymać go w ramach standardowych aktualizacji oprogramowania. Główny urząd certyfikacji GlobalSign – R1 powinien być nawet dostępny w starszych starszych systemach.

Musisz jednak zweryfikować swoje systemy co najmniej wtedy, gdy spełnione są oba te warunki:

  • jeśli usługi działają na niestandardowych lub starszych platformach lub masz własny magazyn certyfikatów głównych
  • nie podjęto żadnych działań w latach 2017–2018 podczas pierwszej fazy migracji głównego urzędów certyfikacji Google lub nie zainstalowano pełnego zestawu certyfikatów z zaufanego pakietu głównego urzędu certyfikacji Google

Sekcja Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji zawiera ogólne wskazówki dotyczące testowania, czy taka zmiana będzie miała wpływ na Twój system.

Zajrzyj do pytania Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google?, aby uzyskać więcej informacji.

Jak mogę uzyskać aktualne informacje na temat tej fazy migracji?

Oznacz problem publiczny 186840968 przy aktualizacji. Te najczęstsze pytania są też aktualizowane w trakcie procesu migracji za każdym razem, gdy napotkamy tematy, które mogą być ogólne.

Jak mogę otrzymać powiadomienie o przyszłych migracji?

Zachęcamy do obserwowania bloga o bezpieczeństwie w Google. Będziemy też starać się jak najszybciej aktualizować dokumentację poszczególnych usług zgodnie z ogłoszeniem publikowanym na blogu.

Zasubskrybuj też powiadomienia Google Maps Platform, ponieważ regularnie publikujemy na forum informacje o zmianach, które mogą dotyczyć większej liczby klientów.

Korzystamy z wielu usług Google. Czy migracja głównego urzędu certyfikacji będzie miała wpływ na wszystkie?

Tak. Migracja głównego urzędu certyfikacji zostanie przeprowadzona we wszystkich usługach i interfejsach API Google, ale harmonogram może się różnić w zależności od usługi. Gdy jednak upewnisz się, że magazyny certyfikatów głównych używane przez Twoje aplikacje klienckie Google Maps Platform zawierają wszystkie urzędy certyfikacji wymienione w pakiecie zaufanych urzędów certyfikacji Google, bieżąca migracja nie powinna mieć wpływu na Twoje usługi, a ich synchronizacja zapewni ochronę przed przyszłymi zmianami głównego urzędów certyfikacji.

Zapoznaj się z pytaniami: Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędów certyfikacji Google? i Które aplikacje są narażone na awarię?, aby uzyskać więcej informacji.

Sekcja Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji poniżej, zawiera też ogólne instrukcje testowania systemu.

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

Przetestuj środowisko aplikacji pod kątem testowych punktów końcowych:

System będzie ogólnie zgodny z tą zmianą głównego urzędu certyfikacji, jeśli:

  • usługa działa w popularnym systemie operacyjnym, zachowasz system operacyjny i biblioteki, z których korzysta Twoja usługa, oraz nie utrzymujesz własnego magazynu certyfikatów głównych lub
  • postępujesz zgodnie z naszymi poprzednimi zaleceniami i zainstalowałeś wszystkie główne urzędy certyfikacji z zaufanych głównych urzędów certyfikacji Google
.

Klienci, których może dotyczyć ten problem, powinni natychmiast zainstalować certyfikaty z zaufanego pakietu głównego urzędu certyfikacji Google, aby uniknąć przerw w działaniu usługi w przyszłości.

Zajrzyj do pytania Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google?, aby uzyskać więcej informacji.

Czy istnieje proste narzędzie do sprawdzenia naszego magazynu certyfikatów głównych?

Podczas analizy mogą Ci się przydać 2 narzędzia wiersza poleceń curl i openssl. Obie opcje są dostępne na większości platform i mają szeroki zakres opcji testowania konfiguracji.

Instrukcje pobierania funkcji curl znajdziesz w sekcji Przygotowywanie curl poniżej.

Przedstawione poniżej polecenia openssl dotyczą wersji 1.1.1 lub nowszej. Wersje starsze niż 1.1.1 nie są obsługiwane. Jeśli używasz starszej wersji, w razie potrzeby uaktualnij lub zmodyfikuj te polecenia. Instrukcje, jak uzyskać openssl, znajdziesz w sekcji Uzyskiwanie OpenSSL poniżej.

Inne przydatne narzędzia znajdziesz też w sekcji Gdzie znajdę potrzebne narzędzia? poniżej.

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

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

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

Weryfikowanie pakietu zaufanego głównego urzędu certyfikacji Google

Pobierz zaufany pakiet głównego urzędu certyfikacji Google, a następnie 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; \
curl -vvI --cacert roots.pem https://good.gtsr1.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

  1. Pierwszy etap (migracja do GS Root R2), który ogłoszono w styczniu 2017 r., rozpoczął się pod koniec 2017 r. i zakończył się w pierwszej połowie 2018 roku.
  2. Drugi etap (przejście na GTS Root R1 Cross) został ogłoszony w marcu 2021 r.

Harmonogramy dalszych faz migracji będziemy ogłaszać z dużym wyprzedzeniem przed wygaśnięciem certyfikatów.

Jednak w przyszłości będzie można zabezpieczyć aplikacje na przyszłość, jeśli będziesz utrzymywać magazyn certyfikatów głównych zsynchronizowany z wyselekcjonowaną listą głównych urzędów certyfikacji w pakiecie zaufanych głównych urzędów certyfikacji Google.

Zobacz też pytanie: Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google?.

Ogólny plan wdrażania w każdej usłudze Google

  1. Wdrażanie etapowe rozpoczyna się w jednym centrum danych.
  2. Wdrażanie etapowe jest stopniowo rozszerzane na kolejne centra danych, aż do momentu, gdy staną się dostępne na całym świecie.
  3. W przypadku wykrycia poważnych problemów na dowolnym etapie testów można tymczasowo wycofać zmiany na czas ich rozwiązywania.
  4. Na podstawie danych wejściowych z poprzednich iteracji kolejne usługi Google są uwzględniane we wdrażaniu, dopóki nie zostaną stopniowo przeniesione wszystkie usługi Google do nowych certyfikatów.

Kogo to będzie dotyczyć, kiedy i gdzie?

W miarę migracji nowych centrów danych coraz więcej deweloperów Google Maps Platform będzie otrzymywać nowe certyfikaty. Zmiany będą częściowo zlokalizowane, ponieważ żądania klientów są zwykle przekazywane do serwerów w centrach danych znajdujących się w pobliżu geograficznie.

Nie możemy z wyprzedzeniem określić, kogo i kiedy dotyczy ta zmiana, dlatego zalecamy wszystkim naszym klientom przeprowadzenie weryfikacji i zapewnienie obsługi swoich usług z dużym wyprzedzeniem przed ewentualnymi fazami migracji głównego urzędu certyfikacji Google.

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

Na co zwrócić uwagę

Klienty, które nie mają wymaganego certyfikatu głównego, nie będą mogły zweryfikować swojego 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ą wysyłać żądanie Google Maps Platform lub odmówić wykonania żądania.

Jakie minimalne wymagania musi spełniać klient TLS, aby mógł komunikować się z Google Maps Platform?

Certyfikaty Google Maps Platform wykorzystują alternatywne nazwy podmiotu (SAN) DNS, dlatego obsługa certyfikatów klienta musi obsługiwać sieci SAN, które mogą zawierać pojedynczy symbol wieloznaczny, jako skrajną etykietę od lewej w nazwie, np. *.googleapis.com.

Inne wymagania znajdziesz w sekcji Jakie są zalecane wymagania, aby klient TLS mógł komunikować się z Google? w Najczęstszych pytaniach dotyczących GTS.

Jakiego typu aplikacje są zagrożone awarią?

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

Aplikacje usług internetowych Google Maps Platform

Jeśli używasz głównego systemu operacyjnego, np. Ubuntu, Red Hat, Windows 10 lub Server 2019 bądź OS X), który jest nadal utrzymywany i regularnie aktualizowany, domyślny magazyn certyfikatów głównych powinien już zawierać certyfikat GTS Root R1.

Jeśli używasz starszej wersji systemu operacyjnego, która nie otrzymuje już aktualizacji, być może masz certyfikat GTS Root R1. Jednak magazyn certyfikatów głównych będzie najprawdopodobniej zawierał główny urząd certyfikacji GlobalSign – R1, jeden z najstarszych i najpopularniejszych głównych urzędów certyfikacji.

W przypadku aplikacji mobilnych wywołujących usługi internetowe Google Maps Platform bezpośrednio z urządzenia użytkownika obowiązują wskazówki z pytania Czy aplikacje mobilne są zagrożone awarią?.

Aplikacje Google Maps Platform po stronie klienta

Aplikacje Maps JavaScript API opierają się zwykle na certyfikatach głównych przeglądarki, w której są uruchamiane. Więcej informacji znajdziesz w sekcji Czy aplikacje JavaScript mogą ulec awarii?.

W przypadku natywnych aplikacji mobilnych korzystających z dowolnego pakietu SDK Map Google na Androida, pakietu Maps SDK na iOS, pakietu Places SDK na Androida lub pakietu Places SDK na iOS obowiązują te same reguły, które obowiązują w przypadku aplikacji wywołujących usługi internetowe Google Maps Platform.

Więcej informacji znajdziesz w pytaniu Czy aplikacje mobilne mogą przestać działać?.

aplikacja używa własnego pakietu certyfikatów lub zaawansowanych funkcji zabezpieczeń takich jak przypinanie certyfikatów;

Pamiętaj, aby samodzielnie zaktualizować pakiet certyfikatów. Jak już wspominaliśmy w odpowiedzi na pytanie: Dlaczego mam utrzymywać synchronizację magazynu certyfikatów głównych z pakietem zaufanych certyfikatów głównych Google? Zalecamy zaimportowanie wszystkich certyfikatów z zaufanych głównych urzędów certyfikacji Google do własnego magazynu certyfikatów głównych.

Jeśli przypinasz certyfikaty lub klucze publiczne do domen Google, z którymi łączy się Twoja aplikacja, dodaj te certyfikaty i klucze publiczne do listy zaufanych encji w aplikacji.

Więcej informacji o przypinaniu certyfikatów lub kluczy publicznych znajdziesz w zasobach zewnętrznych w sekcji Potrzebujesz więcej informacji?

Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google?

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

Dlatego, jeśli chcesz zabezpieczyć swój system na przyszłość, sprawdź, czy magazyn certyfikatów głównych zawiera wszystkie certyfikaty z pakietu, i wypracuj zwyczaju synchronizowania ich obu.

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 instalować poprawek systemu operacyjnego i bibliotek lub korzystasz z własnego magazynu certyfikatów głównych.

Zapoznaj się z pytaniem Jak mogę otrzymywać z wyprzedzeniem powiadomienia o przyszłych migracji?, żeby dowiedzieć się, jak otrzymywać aktualizacje o przyszłych migracji głównego urzędu certyfikacji. Rutynowo synchronizowanie magazynu certyfikatów głównych z wyselekcjonowaną listą pozwala chronić usługi przed przerwami w działaniu w przyszłości z powodu zmian w urzędzie certyfikacji oraz utrzymywać je po wygaśnięciu ważności zarówno GTS Root R1 Cross, jak i GlobalSign Root CA – R1.

Zadaj też pytanie: Tworzę usługę, która łączy się z usługami Google. Jakim certyfikatom CA muszę ufać? Więcej rekomendacji znajdziesz w odpowiedziach na najczęstsze pytania na temat GTS.

Dlaczego nie należy instalować żadnych certyfikatów liścia ani pośrednich CA?

Może to spowodować uszkodzenie Twojej aplikacji, gdy tylko zarejestrujemy nowy certyfikat lub zmienimy pośrednie urzędy certyfikacji. Każda z tych sytuacji może wystąpić w dowolnym momencie i bez wcześniejszego powiadomienia. Będzie też miała zastosowanie do poszczególnych certyfikatów serwera, np. udostępnianych przez maps.googleapis.com, a także wszystkich naszych pośrednich urzędów certyfikacji, np. GTS Root R1 Cross.

Aby chronić swoje usługi, instaluj tylkocertyfikaty główne z zaufanych pakietów głównych urzędów certyfikacji Google. Sprawdzaj wiarygodność całego łańcucha certyfikatów, w którym jest on zakotwiczony.

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

Czy aplikacje JavaScript są narażone na awarie?

Certyfikaty główne GTS są już dobrze osadzone i godne zaufania w większości współczesnych przeglądarek. Podpis krzyżowy z GMO GlobalSign powinien zapewnić płynną migrację nawet w przypadku większości użytkowników korzystających ze starszych przeglądarek. Dotyczy to wszystkich oficjalnie przeglądarek obsługujących Maps JavaScript API.

Każda nowoczesna przeglądarka powinna umożliwiać użytkownikom weryfikację i zazwyczaj edytowanie certyfikatów ufanych przez przeglądarkę. Dokładna lokalizacja różni się w zależności od przeglądarki, ale listę certyfikatów zwykle można znaleźć w Ustawieniach.

Czy aplikacje mobilne mogą się zepsuć?

Urządzenia z Androidem i Apple iOS, które nadal będą regularnie otrzymywać aktualizacje od ich producenta, powinny być na miarę przyszłościowe. 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 obsługa głównych urzędów certyfikacji GTS, w tym GTS Root R1, może być nadal ograniczona w wersjach Androida starszych niż 10.

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

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

Zapoznaj się z pytaniem: Jak sprawdzić zaufane certyfikaty główne na telefonie komórkowym? Więcej informacji.

Kiedy moja przeglądarka lub system operacyjny uwzględnia certyfikaty główne Google Trust Services?

W ostatnich latach firma Google intensywnie współpracowała ze wszystkimi dużymi firmami zewnętrznymi w celu utrzymania popularnych i zaufanych pakietów certyfikatów głównych. Są to na przykład producenci systemów operacyjnych, takich jak Apple i Microsoft, oraz własne zespoły Google ds. Androida i Chrome OS; deweloperzy przeglądarek, np. Mozilla, Apple, Microsoft, czy też zespół Google Chrome; producenci sprzętu, np. telefony, dekodery, telewizory, konsole do gier, drukarki.

W związku z tym jest bardzo prawdopodobne, że dowolny aktualnie obsługiwany system obsługuje już nowe główne urzędy certyfikacji GTS Google, w tym GTS Root R1, a nawet starsze systemy, najprawdopodobniej będzie obsługiwać główny urząd certyfikacji GlobalSign – R1, który przez następne lata będzie używany do podpisywania krzyżowego certyfikatów wystawionych przez Google.

Google nie ma jednak na nie wpływu, dlatego najlepiej jest zadbać o regularne stosowanie dostępnych aktualizacji systemu.

Wybrane firmy zewnętrzne, takie jak program certyfikatów Mozilli CA, mogły własne ramy czasowe uwzględniania certyfikatów.

Rozwiązywanie problemów

Gdzie znajdę potrzebne narzędzia?

Tworzę zawinięcie

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

Uzyskiwanie OpenSSL

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

Uzyskiwanie dostępu do programu Wireshark, Tshark lub Tcpdump

Większość dystrybucji Linuksa oferuje wireshark, natomiast jego narzędzie wiersza poleceń tshark i tcpdump, wstępnie skompilowane wersje pierwszych 2 systemów operacyjnych można znaleźć na stronie https://www.wireshark.org.

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

Dokumentację tych przydatnych narzędzi znajdziesz w przewodniku użytkownika Wireshark, na stronie man aplikacji Tshark oraz na stronie man w aplikacji Tcpdump.

Pobieram narzędzie Keytool Java

Narzędzie wiersza poleceń keytool powinno być dostarczane z każdą wersją środowiska wykonawczego Java (JDK) i Java Runtime Environment. Zainstaluj je, aby uzyskać keytool.. Jednak używanie keytool raczej nie jest konieczne do weryfikacji certyfikatu głównego, chyba że Twoja aplikacja została utworzona w języku Java.

Co zrobić w przypadku przerwy w działaniu środowiska produkcyjnego

Podstawowym działaniem jest zainstalowanie wymaganych certyfikatów głównych z pakietu zaufanych certyfikatów głównych Google w magazynie certyfikatów głównych, których używa Twoja aplikacja.

  1. Skontaktuj się z administratorami systemu, aby uaktualnić lokalny magazyn certyfikatów głównych.
  2. Przeczytaj te najczęstsze pytania, aby znaleźć wskazówki dotyczące Twojego systemu.
  3. Jeśli potrzebujesz dodatkowej pomocy w konkretnej platformie lub systemie, skontaktuj się z zespołem pomocy technicznej oferowanym przez dostawcę systemu.
  4. Aby uzyskać ogólną pomoc, skontaktuj się z naszym zespołem pomocy zgodnie z opisem w sekcji Kontakt z zespołem pomocy Google Maps Platform. Uwaga: w przypadku problemów związanych z konkretną platformą podajemy wskazówki tylko w miarę możliwości.
  5. Oznacz problem publiczny 186840968 gwiazdką, aby opublikować więcej aktualizacji związanych z migracją.

Kontakt 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 mój magazyn certyfikatów głównych wymaga aktualizacji.

Sekcja Zarządzanie zaufanymi certyfikatami zawiera też cenne informacje na temat importowania lub eksportowania certyfikatów głównych.

Jeśli problem nie został rozwiązany i zdecydujesz się skontaktować z zespołem pomocy Google Maps Platform, przygotuj również te informacje:

  1. Gdzie znajdują się serwery, których dotyczy problem?
  2. Na które adresy IP Google wywołuje Twoja usługa?
  3. Których interfejsów API dotyczy ten problem?
  4. Kiedy dokładnie wystąpił problem?

  5. Dane wyjściowe tych poleceń:

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

Instrukcje dotyczące uzyskiwania potrzebnych narzędzi znajdziesz w sekcji Gdzie znajdę potrzebne narzędzia?.

Przesyłanie zgłoszenia do zespołu pomocy

Instrukcje tworzenia zgłoszenia do zespołu pomocy znajdziesz w sekcji 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ż te informacje:

  • Jakie są Twoje publiczne adresy IP?
  • Jaki jest publiczny adres IP Twojego serwera DNS?
  • Jeśli to możliwe, przechwycony pakiet tcpdump lub Wireshark nie powiódł się negocjacji TLS z https://maps.googleapis.com/ w formacie PCAP z wykorzystaniem wystarczająco dużej długości zrzutu, aby zarejestrować cały pakiet bez obcinania go (np. z użyciem metody -s0 w starszych wersjach protokołu tcpdump).
  • Jeśli to możliwe, dzienniki z Twojej usługi zawierające dokładny powód błędu połączenia TLS, najlepiej z pełnym łańcuchem certyfikatów serwera.

Instrukcje dotyczące uzyskiwania potrzebnych narzędzi znajdziesz w sekcji Gdzie znajdę potrzebne narzędzia?.

Publikuję w numerze publicznym 186840968

Podczas publikowania komentarza na temat problemu publicznego 186840968 podaj informacje wymienione w sekcji Wstępne rozwiązywanie problemów.

Jak mogę ustalić publiczny adres mojego DNS?

W Linuksie możesz uruchomić to polecenie:

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

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

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

Jak interpretować dane wyjściowe curl

Użycie funkcji curl z flagami -vvI zawiera wiele przydatnych informacji. Oto kilka instrukcji dotyczących interpretacji danych wyjściowych:

  • Wiersze zaczynające się od „*” zawierają dane wyjściowe negocjacji TLS oraz informacje o zakończeniu połączenia.
  • Wiersze zaczynające się od „>” zawierają wychodzące żądanie HTTP wysłane przez usługę curl.
  • Wiersze zaczynające się od „<” zawierają odpowiedź HTTP otrzymaną z serwera.
  • Jeśli protokół to HTTPS, obecność wierszy „>” lub „<” oznacza udane uzgadnianie połączenia TLS.

Użyto biblioteki TLS i pakietu certyfikatów głównych

Uruchomienie polecenia curl z flagami -vvI również wyświetla magazyn używanych 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 komputera Red Hat z systemem Linux z plikiem curl połączonym 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 komputera Ubuntu lub Debiana z systemem Linux mogą zawierać te wiersze:

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

Dane wyjściowe z komputera Ubuntu lub Debiana z systemem Linux przy użyciu pliku PEM certyfikatu głównego Google podanego z flagą --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: */*
>

Nieudane uzgadnianie 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ż może wskazywać na to, że próba nawiązania połączenia nie powiodła się:

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

Pomyślne uzgadnianie połączenia TLS

Pomyślne uzgadnianie połączenia TLS wskazuje na obecność wierszy podobnych do tych w tym przykładowym kodzie. Pakiet szyfrowania używany do zaszyfrowanego połączenia powinien być widoczny oraz informacje o akceptowanym certyfikacie serwera. Ponadto obecność wierszy zaczynających się od > lub < oznacza, że ruch HTTP ładunku jest prawidłowo przesyłany przez szyfrowane 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ą w formacie PEM, np. dane wyjściowe z openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, możesz wydrukować udostępniany certyfikat, wykonując te czynności:

  • Skopiuj cały certyfikat zakodowany w standardzie 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.

Informacje o danych wejściowych i wynikach znajdziesz w sekcji Jak drukować certyfikaty PEM w sposób zrozumiały dla człowieka.

Jak wyglądają certyfikaty Google podpisane krzyżowo w OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.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.demo.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 pytaniu Czy aplikacje mobilne mogą się zepsuć? Android od wersji 4.0 zezwala użytkownikom telefonu na sprawdzanie listy zaufanych certyfikatów w Ustawieniach. Ta tabela przedstawia dokładną ścieżkę 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 > Lokalizacja i zabezpieczenia > Szyfrowanie i dane logowania > Zaufane dane logowania
10+ Ustawienia > Zabezpieczenia > Zaawansowane > Szyfrowanie i dane logowania > Zaufane dane logowania

W tej tabeli pokazujemy prawdopodobną dostępność najważniejszych certyfikatów głównych na Androida na podstawie weryfikacji ręcznej z użyciem dostępnych obecnie obrazów systemu urządzenia wirtualnego z Androidem (AVD). Historia wersji ca-certificates AOSP. Historia wersji repozytorium Git, w której obrazy systemu nie były już dostępne:

Wersja Androida GTS – główny R1 Główny urząd certyfikacji GlobalSign – 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+

Aktualizowanie magazynu certyfikatów głównych systemu Android zwykle nie jest możliwe bez aktualizacji oprogramowania układowego lub uzyskania dostępu do roota. Jednak w przypadku większości wersji Androida, które są wciąż powszechnie używane, obecny zestaw zaufanych certyfikatów głównych prawdopodobnie zapewni nieprzerwaną obsługę przez wiele lat, poza okresem eksploatacji większości obecnie używanych urządzeń.

Począwszy od wersji 7.0 Android zapewnia deweloperom aplikacji bezpieczną metodę dodawania zaufanych certyfikatów, które są zaufane tylko dla ich aplikacji. W tym celu połącz certyfikaty z aplikacją i utworzysz niestandardową konfigurację zabezpieczeń sieci zgodnie z opisem w dokumencie szkoleniowym Android – sprawdzone metody dotyczące bezpieczeństwa i prywatności Konfiguracja bezpieczeństwa sieci.

Deweloperzy aplikacji innych firm nie będą jednak mogli wpływać na konfigurację zabezpieczeń sieci ruchu pochodzącego z pliku APK usług Google Play, więc takie działania prawdopodobnie wystarczyłyby tylko do częściowego obejścia.

Na starszych starszych urządzeniach jedyną dostępną opcją byłoby korzystanie z urzędów certyfikacji dodanych przez użytkowników, które zostały zainstalowane przez firmowe zasady grupy zastosowane na urządzeniu użytkownika lub przez samych użytkowników.

Magazyn zaufania systemu iOS

Apple nie pokazuje bezpośrednio użytkownikowi swojego domyślnego zestawu zaufanych certyfikatów głównych, ale firma udostępnia linki do zestawów zaufanych głównych urzędów certyfikacji w przypadku systemu iOS w wersji 5 i nowszych w artykułach pomocy Apple:

Jednak wszystkie dodatkowe certyfikaty zainstalowane na urządzeniu z iOS powinny być widoczne w sekcji Ustawienia > Ogólne > Profil. Jeśli nie masz zainstalowanych żadnych dodatkowych certyfikatów, pozycja menu Profil może się nie wyświetlić.

W poniższej tabeli przedstawiono dostępność najważniejszych certyfikatów głównych w poszczególnych wersjach iOS na podstawie podanych wyżej źródeł:

Wersja iOS GTS – główny R1 Główny urząd certyfikacji GlobalSign – R1 GlobalSign Root R2 (ważny do 15 grudnia 2021 r.)
5, 6, 7, 8, 9, 10, 11, 12,0
12.1.3+

Gdzie są przechowywane moje systemowe certyfikaty główne i jak mogę je 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 Linuksa 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 certyfikatów mogą obejmować:

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

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

Zaktualizuj odpowiedni pakiet.

Magazyn certyfikatów głównych OpenSSL

W przypadku aplikacji korzystających z OpenSSL można 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 ciąg OPENSSLDIR, który odpowiada katalogowi najwyższego poziomu, w którym znajduje się biblioteka, a jej konfiguracje znajdują się w tym miejscu:

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 magazynu certyfikatów głównych systemu (jak w powyższym przykładzie), sprawdź sekcję najwyższego poziomu. Gdzie znajdują się moje systemowe certyfikaty główne i jak mogę je zaktualizować?, aby upewnić się, że systemowy pakiet certyfikatów głównych jest aktualny.

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

Magazyn certyfikatów głównych Java

Aplikacje w języku Java mogą korzystać z własnego magazynu certyfikatów głównych, który w systemach Linux znajduje się zwykle pod adresem /etc/pki/java/cacerts lub /usr/share/ca-certificates-java, którym można zarządzać za pomocą narzędzia wiersza poleceń keytool Javy.

Aby zaimportować pojedynczy certyfikat do magazynu certyfikatów Java, uruchom następujące polecenie:

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

Wystarczy, że zastąp cert.pem plikiem certyfikatu odpowiadającym każdemu rekomendowanemu certyfikatowi głównemu, alias unikalnym, ale zrozumiałym 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ą też domyślnie korzystać z systemowej bazy danych certyfikatów, która zwykle znajduje się w katalogu /etc/pki/nssdb lub z indywidualnego dla użytkownika magazynu domyślnego w ${HOME}/.pki/nssdb.

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

Aby zaimportować plik pojedynczego certyfikatu do bazy danych NSS, uruchom to polecenie:

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

Wystarczy, że zastąpisz cert.pem plikiem certyfikatu odpowiadającym każdemu rekomendowanemu certyfikatowi głównemu, cert-name – pseudonimem certyfikatu, a certdir – ścieżką bazy danych certyfikatu używaną w Twoim środowisku.

Więcej informacji znajdziesz w oficjalnej instrukcji obsługi narzędzia NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Magazyn certyfikatów głównych Microsoft .NET

Do aktualizacji magazynu certyfikatów głównych mogą być przydatne te artykuły Microsoftu:

Formaty plików certyfikatów

Co to jest plik PEM?

E-mail z rozszerzoną ochroną prywatności to standardowy format pliku tekstowego do przechowywania i wysyłania certyfikatów, kluczy itp. kryptograficznych, sformalizowany jako standard de-jure w RFC 7468.

Sam format pliku jest zrozumiały dla człowieka, ale informacje o certyfikatach binarnych zakodowanych w Base64 – nie. Specyfikacja PEM pozwala jednak na umieszczanie tekstu objaśniającego przed lub za treścią certyfikatu zakodowanego w formie tekstowej. Wiele narzędzi korzysta z tej funkcji, aby wyświetlać także czyste podsumowanie najważniejszych elementów danych w certyfikacie.

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

Co to jest plik „.crt”?

Narzędzia umożliwiające eksportowanie certyfikatów w formacie PEM zwykle używają rozszerzenia pliku „.crt”, aby wskazać, że plik zawiera kodowanie tekstowe.

Co to jest plik DER?

Distinguished Encoding Rules (DER) to standardowy format binarny służący do kodowania certyfikatów. Certyfikaty w plikach PEM to zwykle certyfikaty DER zakodowane w standardzie Base64.

Co to jest plik „.cer”?

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

Mój system odmawia importowania wszystkich certyfikatów z folderu roots.pem

Niektóre systemy, np. Java keytool może importować z pliku PEM tylko jeden certyfikat, nawet jeśli zawiera on kilka certyfikatów. Zobacz pytanie: Jak wyodrębnić poszczególne certyfikaty z folderu roots.pem?, aby dowiedzieć się, jak najpierw podzielić plik.

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

Możesz podzielić roots.pem na certyfikaty komponentu, korzystając z tego prostego 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, takie jak 02265526.pem, możesz następnie zaimportować oddzielnie lub przekonwertować na format akceptowany przez Twój magazyn certyfikatów.

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

Narzędzie wiersza poleceń OpenSSL openssl może służyć do konwertowania plików ze wszystkich powszechnie używanych formatów plików certyfikatów. Poniżej znajdziesz instrukcje konwersji z pliku PEM na najczęściej używane formaty pliku certyfikatu.

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

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

Jak przekonwertować plik PEM na format DER?

Za pomocą openssl możesz wykonać to polecenie, aby przekonwertować plik z 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 uruchomić to polecenie w celu przekonwertowania pliku z 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 wykonać poniższe polecenie w celu przekonwertowania pliku z PEM na PKCS #12:

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

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

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ą keytool możesz wykonać poniższe polecenie, aby wyświetlić listę wszystkich certyfikatów w magazynie certyfikatów wraz z aliasami, których możesz użyć do wyeksportowania każdego z nich:

keytool -v -list -keystore certs.jks

Po prostu 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, uruchom następujące polecenie:

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

Wystarczy, że zastąp certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku i podaj wartości 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.

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

Za pomocą certutil możesz wykonać poniższe 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

Wystarczy, że zastąp certdir ścieżką bazy danych certyfikatu używaną w Twoim środowisku. Wyświetli się też pseudonim każdego certyfikatu, który będzie potrzebny, jeśli zechcesz go wyeksportować.

Aby wyeksportować pojedynczy certyfikat w formacie PEM, uruchom następujące polecenie:

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

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

Więcej informacji znajdziesz w oficjalnej instrukcji obsługi narzędzia NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Jak drukować certyfikaty 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 przy użyciu OpenSSL

Uruchamiam polecenie

openssl x509 -in GTS_Root_R1.pem -text

powinien wyświetlić 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 pobierania openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Drukowanie certyfikatów za pomocą narzędzia Java Keytool

Uruchamiam to polecenie

keytool -printcert -file GTS_Root_R1.pem

powinien wyświetlić 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 pobierania narzędzia keytool znajdziesz w sekcji Pobieranie klucza Java.

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

Zależy to od systemu operacyjnego i biblioteki SSL/TLS. Narzędzia umożliwiające 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 Twój magazyn certyfikatów głównych zawiera już zapisane pliki PEM, możesz spróbować otworzyć te pliki w dowolnym edytorze tekstu, ponieważ ma on format zwykłego tekstu.

Plik PEM może być prawidłowo oznaczony etykietami i zawierać czytelne dla człowieka informacje o powiązanym urzędzie certyfikacji (przykład z zaufanego pakietu głównego urzędu 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, na przykład GTS_Root_R1.pem, może opisywać, do którego urzędu certyfikacji należy certyfikat. Ciąg certyfikatu między tokenami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE----- również będzie unikalny dla każdego urzędu certyfikacji.

Jednak nawet jeśli nie masz powyższych narzędzi, a każdy certyfikat w zaufanym pakiecie głównego urzędu certyfikacji Google jest prawidłowo oznaczony etykietami, możesz niezawodnie dopasować główne urzędy certyfikacji z pakietu do tych z magazynu certyfikatów głównych za pomocą Issuer lub porównując ciągi certyfikatów pliku PEM.

Przeglądarki mogą korzystać z własnego magazynu certyfikatów głównych lub z domyślnego certyfikatu dostarczonego przez system. Wszystkie nowoczesne przeglądarki powinny jednak umożliwiać zarządzanie zbiorem zaufanych głównych urzędów certyfikacji lub przynajmniej wyświetlanie tego zestawu. Więcej informacji znajdziesz w pytaniu Czy aplikacje JavaScript mogą ulec awarii?.

Instrukcje dotyczące telefonów komórkowych znajdziesz w osobnym pytaniu: 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 z bibliotek zewnętrznych, z których korzysta Twoja aplikacja.

Wszelkie inne źródła informacji, w tym te najczęstsze pytania, mogą być nieaktualne lub nieprawidłowe z innego powodu i nie powinny być uznawane za wiarygodne. Jednak wciąż możesz znaleźć przydatne informacje w wielu społecznościach pytań i odpowiedzi w Stack Exchange oraz w witrynach takich jak AdamW na Linuksie i potwierdzaniu bloga.

Zapoznaj się też z najczęstszymi pytaniami na temat Google Trust Services.

Więcej informacji o zaawansowanych tematach, takich jak przypinanie certyfikatów, znajdziesz w artykułach Open Web Application Security Project (OWASP) Certificate and Public Key Przypinanie i Pinning Cheat Sheet. Instrukcje dotyczące urządzeń z Androidem znajdziesz w oficjalnym dokumencie szkoleniowym Sprawdzone metody dotyczące bezpieczeństwa i prywatności w Androidzie Bezpieczeństwo przez HTTPS i SSL. Aby porozmawiać o różnicy między przypinaniem certyfikatu a kluczem publicznym na Androidzie, warto zapoznać się z postem na blogu Matthew Dolana: Android Security: SSL Przypinanie.

Dalsze informacje o zarządzaniu dodatkowymi zaufanymi certyfikatami na Androidzie znajdziesz w dokumentacji szkoleniowej dotyczącej Androida – Sprawdzone metody dotyczące bezpieczeństwa i prywatności oraz w poście na blogu JeroenHD na blogu JeroenHD na Androidzie 7 Nougat i urzędach certyfikacji.

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