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 obecnej migracji głównego certyfikatu uwierzytelniającego Google znajdziesz w artykule Co się dzieje?.

Terminologia

Poniżej znajdziesz listę najważniejszych terminów, które musisz znać, aby móc korzystać z tego dokumentu. Bardziej wyczerpujące informacje na temat terminologii znajdziesz w odpowiedziach na najczęstsze pytania na temat usług 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. Certyfikaty są wydawane i podpisywane kryptograficznie przez podmioty zwane urzędami certyfikacji.
Przeglądarki korzystają z certyfikatów wydanych przez zaufane urzędy certyfikacji, aby wiedzieć, że przesyłane informacje są wysyłane na właściwy serwer i szyfrowane podczas przesyłania.
Secure Sockets Layer (SSL)
Protokół Secure Sockets Layer jest najpopularniejszym protokołem używanym do szyfrowania komunikacji w internecie. Protokół SSL nie jest już uważany za bezpieczny i nie powinien być używany.
Transport Layer Security (TLS)
Transport Layer Security jest następcą protokołu SSL.
Urząd certyfikacji (CA)
Urząd certyfikacji jest jak cyfrowy urząd paszportowy dla urządzeń i ludzi. Wystawia ona dokumenty chronione za pomocą szyfrowania (certyfikaty), aby potwierdzić, że dana osoba (np. witryna) jest tym, za kogo się podaje.
Przed wystawieniem certyfikatu urzędy certyfikacji muszą sprawdzić, 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 systemów wydających certyfikaty.
Magazyn certyfikatów głównych
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łasne repozytorium certyfikatów głównych.
Aby zostać uwzględnionym w magazynie głównych urzędów certyfikacji, urząd certyfikacji musi spełniać rygorystyczne wymagania określone przez dostawcę oprogramowania aplikacji.
Zwykle obejmuje to zgodność ze standardami branżowymi, takimi jak wymagania Forum CA/Browser.
Główny urząd certyfikacji
Główny urząd certyfikacji (a dokładniej jego certyfikat) to certyfikat najwyższego w łańcuchu certyfikatów.
Certyfikaty głównego urzędu certyfikacji są zwykle podpisane samodzielnie. Klucze prywatne powiązane z tymi kartami są przechowywane w bardzo bezpiecznych lokalizacjach i utrzymywane w stanie offline, aby chronić je przed nieautoryzowanym dostępem.
Urząd certyfikacji pośredniczący
Pośredni urząd certyfikacji (lub, ściślej mówiąc, jego certyfikat) to certyfikat używany do podpisywania innych certyfikatów w łańcuchu certyfikatów.
Przejściowe urzędy certyfikacji umożliwiają wystawianie certyfikatów online, a jednocześnie pozwalają certyfikatowi głównego urzędu certyfikacji pozostać offline.
Pośrednie urzędy certyfikacji są też nazywane podrzędnymi urzędami certyfikacji.
Urząd certyfikacji wydający
Urząd wydający certyfikat (a dokładniej – jego certyfikat) to certyfikat używany do podpisywania najniższego poziomu w łańcuchu certyfikatów.
Ten dolny certyfikat 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ą (szyfrowanym podpisem). Łańcuch certyfikatów składa się z certyfikatu liścia, wszystkich certyfikatów jego 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 urzędu certyfikacji, aby ich produkty były zaufane. Korzystanie z usług zawierających nowe certyfikaty CA może trochę potrwać.
Aby zwiększyć zgodność ze starszymi klientami, certyfikaty CA można „podpisać 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 urzędów certyfikacji zawartych w ich magazynie certyfikatów głównych klienci będą tworzyć różne łańcuchy certyfikatów aż do zaufanego głównego urzędu certyfikacji.

Informacje ogólne

Co się dzieje?

Koncepcja

W 2017 r. Google rozpoczęło wieloletni projekt dotyczący wydawania i używania własnych certyfikatów głównych, czyli podpisów kryptograficznych, które stanowią podstawę bezpieczeństwa internetowego TLS używanego przez HTTPS.

Po pierwszym etapie zabezpieczenia TLS usług Google Maps Platform zostały zagwarantowane przez GS Root R2, bardzo dobrze znany i powszechnie zaufany główny urząd certyfikacji (CA), który firma Google nabyła od GMO GlobalSign, by ułatwić przejście na własne, własne główne urzędy certyfikacji Google Trust Services (GTS).

Praktycznie wszyscy klienci TLS (np. przeglądarki internetowe, smartfony i serwery aplikacji) ufają temu certyfikatowi głównemu, dzięki czemu w pierwszym etapie migracji mogli nawiązać bezpieczne połączenie z serwerami platformy Mapy Google.

Jednak urząd certyfikacji może z założenia nie wydawać certyfikatów, które są ważne dłużej niż do czasu wygaśnięcia własnego certyfikatu. 15 grudnia 2021 r. wygasa certyfikat GS Root R2, dlatego Google przeniesie swoje usługi do nowego urzędu certyfikacji GTS Root R1 Cross, używając certyfikatu wydanego przez własny główny urząd certyfikacji Google GTS Root R1.

Chociaż zdecydowana większość nowoczesnych systemów operacyjnych i bibliotek klientów TLS ufa już zaufanym urzędom certyfikacji głównej GTS, Google uzyskało od GMO GlobalSign certyfikat krzyżowy z GlobalSign Root CA – R1, który jest jednym z najstarszych i najbardziej zaufanych urzędów certyfikacji głównej.

Dlatego większość klientów Google Maps Platform rozpoznaje już 1 lub oba te zaufane główne urzędy certyfikacji i druga faza migracji nie będzie miała na nie żadnego wpływu.

Dotyczy to również klientów, którzy podjęli działania w pierwszej fazie migracji w 2018 r., o ile w tym czasie zastosowali się do naszych instrukcji i zainstalowali wszystkie certyfikaty z zaufanej paczki urzędu głównego certyfikacji Google.

Zweryfikuj systemy, jeśli:

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

Jeśli ma to zastosowanie, konieczne może być zaktualizowanie klientów za pomocą zalecanych certyfikatów głównych, aby zapewnić nieprzerwany dostęp do Google Maps Platform podczas tej fazy migracji.

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

Zalecamy też, aby certyfikaty główne były nadal przechowywane zgodnie z powyższym zbiorem urzędów certyfikacji głównej, aby chronić usługi przed przyszłymi zmianami w urzędach certyfikacji głównej. Ogłosimy to z wyprzedzeniem. Dalsze instrukcje znajdziesz w sekcjach Jak uzyskać aktualne informacje na temat tej fazy migracji? i Jak mogę otrzymywać z wyprzedzeniem powiadomienia o kolejnych migracjach?.

Podsumowanie techniczne

Zgodnie z ogłoszeniem opublikowanym 15 marca 2021 r. na blogu Google o bezpieczeństwie GS Root R2 główny urząd certyfikacji używany przez Google Maps Platform od początku 2018 r. wygaśnie 15 grudnia 2021 r. Dlatego w tym roku Google przeprowadzi migrację do nowo wydanego certyfikatu CA GTS Root R1 Cross. Oznacza to, że nasze usługi będą stopniowo przechodzić na certyfikaty TLS wydawane przez ten nowy urząd certyfikacji.

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

Należy jednak sprawdzić swoje systemy co najmniej w przypadku spełnienia obu tych warunków:

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

W sekcji Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji znajdziesz ogólne wskazówki dotyczące sprawdzania, czy Twój system będzie miał problemy.

Więcej informacji znajdziesz w odpowiedzi na pytanie Dlaczego powinienem utrzymywać synchronizację magazynu certyfikatów głównych z zaufanym pakietem certyfikatów głównych CA Google?.

Jak uzyskać aktualne informacje na temat tego etapu migracji?

Oznacz gwiazdką numer publiczny 186840968, aby zaktualizować informacje. Te najczęstsze pytania są aktualizowane podczas migracji, gdy tylko natrafimy na tematy, które mogą być interesujące dla wszystkich użytkowników.

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

Zachęcamy do obserwowania bloga o bezpieczeństwie w Google. Postaramy się też jak najszybciej zaktualizować dokumentację poszczególnych usług po opublikowaniu ogłoszenia na blogu.

Zasubskrybuj też powiadomienia z platformy Map Google, ponieważ regularnie publikujemy na forum informacje o zmianach, które mogą mieć wpływ na większą liczbę klientów.

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

Tak, migracja głównego urzędu certyfikacji będzie miała miejsce we wszystkich usługach i interfejsach API Google, ale harmonogram może się różnić w zależności od usługi. Jeśli jednak upewnisz się, że magazyny certyfikatów głównych używane przez aplikacje klienckie Google Maps Platform zawierają wszystkie urzędy certyfikacji wymienione w zaufanym pakiecie głównych urzędów certyfikacji Google, migracja nie powinna mieć wpływu na Twoje usługi, a ich synchronizowanie zabezpieczy Cię przed przyszłymi zmianami głównego urzędu certyfikacji.

Więcej informacji znajdziesz w odpowiedziach na pytania Dlaczego warto synchronizować magazyn certyfikatów głównych z pakietem zaufanych głównych urzędów certyfikacji Google? oraz Jakiego rodzaju aplikacje są narażone na awarię?.

W sekcji Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji znajdziesz też ogólne instrukcje testowania systemu.

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

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

System jest w ogóle zgodny z tą zmianą łańcucha zaufania głównego, jeśli:

  • usługa działa na obsługiwanym systemie operacyjnym, a Ty aktualizujesz zarówno system operacyjny, jak i biblioteki, których używa usługa, nie utrzymujesz własnego magazynu certyfikatów głównych, lub:
  • wykonane zostały poprzednie zalecenia i zainstalowano wszystkie główne urzędy certyfikacji z zaufanego pakietu głównych urzędów certyfikacji Google

Klienci, których to dotyczy, 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.

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

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

Podczas analizowania problemów przydatne mogą być 2 narzędzia wiersza poleceń: curl i openssl. Oba są dostępne na większości platform i zapewniają wiele opcji testowania konfiguracji.

Instrukcje uzyskiwania curl znajdziesz w sekcji Uzyskiwanie curl poniżej.

Polecenia openssl podane poniżej są przeznaczone do wersji 1.1.1 lub nowszej. Wersje starsze niż 1.1.1 nie są obsługiwane. Jeśli używasz wcześniejszej wersji, uaktualnij lub zmodyfikuj te polecenia zgodnie z potrzebami. Instrukcje dotyczące instalacji openssl znajdziesz w sekcji Instalowanie OpenSSL poniżej.

W sekcji Gdzie mogę znaleźć potrzebne narzędzia? znajdziesz więcej przydatnych narzędzi.

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

Testowanie domyślnego magazynu 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.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 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.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Jak i kiedy będzie kontynuowana migracja głównego certyfikatu głównego Google?

  1. Pierwszy etap (migracja do GS Root R2) ogłosiliśmy w styczniu 2017 r., rozpoczęto pod koniec 2017 roku i zakończył się w pierwszej połowie 2018 roku.
  2. Druga faza (przejście na GTS Root R1 Cross) została ogłoszona w marcu 2021 r. i będzie wdrażana w najbliższych miesiącach, zanim wygaśnie GS Root R2 15 grudnia 2021 r.

Harmonogramy kolejnych etapów migracji zostaną ogłoszone z dużym wyprzedzeniem przed wygaśnięciem certyfikatu.

Aplikacje można jednak przygotować na przyszłość, jeśli będziesz synchronizować magazyn certyfikatów głównych 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 zaufanego głównego urzędu certyfikacji Google?.

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

  1. Wdrażanie etapowe rozpoczyna się w jednym centrum danych.
  2. Stopniowo rozszerzamy wdrożenie na kolejne centra danych, aż uzyskasz globalny zasięg.
  3. Jeśli na którymkolwiek etapie wykryjemy poważne problemy, testy mogą zostać cofnięte tymczasowo, aby rozwiązać problemy.
  4. Na podstawie informacji z poprzednich iteracji kolejne usługi Google są włączane do wdrażania, aż w końcu wszystkie usługi Google zostaną przeniesione na nowe certyfikaty.

Kto, kiedy i gdzie będzie objęty zmianą?

Coraz większa liczba deweloperów korzystających z Google Maps Platform zacznie otrzymywać nowe certyfikaty po przeniesieniu nowych centrów danych. Zmiany będą w pewnym stopniu zlokalizowane, ponieważ żądania klientów są zwykle przekierowywane do serwerów w najbliżej położonym geograficznie centrum danych.

Nie możemy z pewnością określić, kogo, kiedy i gdzie to dotyczy, dlatego zalecamy wszystkim naszym klientom, aby zweryfikowali swoje usługi i przygotowali je na przyszłość odpowiednio wcześniej przed ewentualnymi etapami migracji głównego urzędu certyfikacji Google.

Aby uzyskać więcej informacji, zapoznaj się z sekcją Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji.

Na co zwrócić uwagę

Klienty, którzy nie mają skonfigurowanego wymaganego certyfikatu głównego, nie będą mogli zweryfikować swojego połączenia TLS z Google Maps Platform. W takim przypadku klienci zwykle wyświetlają ostrzeżenie, że weryfikacja certyfikatu się nie udała.

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

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

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

Pozostałe wymagania znajdziesz w sekcji Jakie są zalecane wymagania dotyczące klienta TLS na potrzeby komunikacji z Google? w artykule Najczęstsze pytania dotyczące GTS.

Które aplikacje mogą przestać działać?

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

Aplikacje usług internetowych Google Maps Platform

Jeśli używasz popularnego systemu operacyjnego, np. Ubuntu, Red Hat, Windows 10 lub Server 2019, OS X), który jest wciąż utrzymywany i jest 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 nie masz certyfikatu GTS Root R1. Jednak magazyn certyfikatów głównych zawiera najprawdopodobniej główny urząd certyfikacji GlobalSign – R1, jeden z najstarszych i najbardziej zaufanych 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 mogą ulec uszkodzeniu?.

Aplikacje Google Maps Platform po stronie klienta

Aplikacje korzystające z interfejsu Maps JavaScript API zwykle korzystają z certyfikatów głównych przeglądarki internetowej, w której są uruchomione. Więcej informacji znajdziesz w sekcji Czy aplikacje JavaScript mogą przestać działać?.

W przypadku natywnych aplikacji mobilnych korzystających z dowolnego z tych pakietów SDK: Maps SDK na Androida, Maps SDK na iOS, Places SDK na Androida lub Places SDK na iOS obowiązują te same zasady co w przypadku aplikacji wywołujących usługi sieciowe Google Maps Platform.

Więcej informacji znajdziesz w artykule Czy aplikacje mobilne mogą się zepsuć?.

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

Pamiętaj, aby samodzielnie zaktualizować pakiet certyfikatów. Zgodnie z odpowiedzią na pytanie Dlaczego warto zsynchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google? zalecamy zaimportowanie wszystkich certyfikatów z zaufanego pakietu głównego urzędu certyfikacji Google do własnego magazynu certyfikatów głównych.

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

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

Dlaczego powinienem utrzymywać synchronizację magazynu certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google?

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

Dlatego jeśli chcesz, aby Twój system był w przyszłości bezpieczny, zalecamy, aby sprawdzić, czy magazyn certyfikatów głównych zawiera wszystkie certyfikaty z pakietu, i przyzwyczaić się do utrzymywania ich w zsynchronizowanej formie.

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

Przeczytaj artykuł Jak mogę otrzymywać z wyprzedzeniem powiadomienia o przyszłych migracjach, aby dowiedzieć się, jak otrzymywać informacje o przyszłych migracjach głównego urzędu certyfikacji. Regularne zsynchronizowanie magazynu certyfikatów głównych z listą zweryfikowanych certyfikatów zapewni ochronę usług przed przyszłymi przerwami w ich działaniu spowodowanymi zmianami w urzędach certyfikacji. Dzięki temu usługi będą działać także po wygaśnięciu ważności certyfikatów GTS Root R1 Cross i GlobalSign Root CA – R1.

Odpowiedź na to pytanie znajdziesz w sekcji Tworzę produkt, który łączy się z usługami Google. Jakim certyfikatom CA mam ufać? Więcej informacji znajdziesz w Najczęstszych pytaniach na temat GTS.

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

Może to spowodować przerwanie działania aplikacji w każdej chwili, gdy 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. Dotyczy ona w równym stopniu poszczególnych certyfikatów serwera (na przykład wyświetlanych przez maps.googleapis.com), a także wszelkich naszych pośrednich urzędów certyfikacji, takich jak GTS Root R1 Cross.

Aby zabezpieczyć swoje usługi, instaluj tylko certyfikaty główne z zaufanego pakietu głównego urzędu certyfikacji Google, a następnie korzystaj z samego certyfikatu głównego, aby sprawdzić wiarygodność całego łańcucha certyfikatów zakotwiczonego w nim.

Każda nowoczesna biblioteka TLS powinna mieć możliwość automatycznego weryfikowania takich łańcuchów zaufania, o ile główny urząd certyfikacji jest zaufany.

Czy aplikacje JavaScript mogą ulec awarii?

Certyfikaty główne GTS są już dobrze osadzone i uznane przez większość nowoczesnych przeglądarek, a certyfikat krzyżowy GMO GlobalSign powinien zapewnić płynną migrację nawet w przypadku większości użytkowników końcowych korzystających ze starszych przeglądarek. Dotyczy to wszystkich oficjalnie przeglądarek obsługiwanych przez Maps JavaScript API.

Każda nowoczesna przeglądarka powinna umożliwiać użytkownikom sprawdzanie i zwykle edytowanie certyfikatów zaufanych. Choć dokładna lokalizacja różni się w zależności od przeglądarki, listę certyfikatów można zwykle znaleźć w Ustawieniach.

Czy aplikacje mobilne mogą ulec awarii?

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

Obsługa certyfikatów głównych GTS, w tym GTS Root R1, może być jednak ograniczona w wersjach Androida starszych niż 10.

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

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

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

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

W ciągu ostatnich lat firma Google intensywnie współpracowała ze wszystkimi największymi firmami, dbając o utrzymanie popularnych i zaufanych pakietów certyfikatów głównych. Przykłady: producenci systemów operacyjnych, tacy jak Apple i Microsoft, ale też zespoły Google ds. Androida i ChromeOS; deweloperzy przeglądarek, tacy jak Mozilla, Apple i Microsoft, ale też zespół Google ds. Chrome; producenci sprzętu, tacy jak producenci telefonów, dekoderów, telewizorów, konsol do gier czy drukarek.

Jest więc bardzo prawdopodobne, że każdy obecnie utrzymywany system obsługuje już nowe urzędy certyfikacji głównej GTS firmy Google, w tym GTS Root R1. Jest też bardzo prawdopodobne, że nawet starsze systemy obsługują GlobalSign Root CA – R1, który będzie używany do podpisywania krzyżowego certyfikatów wydanych przez Google w najbliższych latach.

Ponieważ jednak harmonogram uwzględniania certyfikatów innych firm w dużej mierze pozostaje poza kontrolą Google, zalecamy regularne instalowanie dostępnych aktualizacji systemu.

Niektóre firmy zewnętrzne, np. Mozilla CA Certificate Program, mogą mieć udokumentowane własne harmonogramy uwzględniania certyfikatów.

Rozwiązywanie problemów

Gdzie mogę znaleźć potrzebne narzędzia?

Pobieranie skrętu

Jeśli dystrybucja systemu operacyjnego nie zawiera pakietu curl, możesz go pobrać z https://curl.haxx.se/. Możesz pobrać kod źródłowy i sam skompilować narzędzie lub pobrać skompilowany plik binarny, jeśli jest dostępny na Twojej platformie.

Uzyskiwanie OpenSSL

Jeśli w Twojej dystrybucji systemu operacyjnego nie ma openssl, możesz pobrać źródło ze strony https://www.openssl.org/ i skompilować narzędzie. Listę binarnych plików binarnych utworzonych przez osoby trzecie można znaleźć na stronie https://www.openssl.org/community/binaries.html. Jednak żadna z tych kompilacji nie jest obsługiwana ani w żaden inny sposób rekomendowana przez zespół OpenSSL.

Pobieranie Wireshark, Tshark lub Tcpdump

Choć w większości dystrybucji Linuksa dostępna jest usługa wireshark, narzędzie wiersza poleceń tshark i tcpdump, wstępnie skompilowane wersje pierwszych 2 dla innych systemów operacyjnych znajdziesz na https://www.wireshark.org.

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

Dokumentację tych przydatnych narzędzi znajdziesz w przewodniku użytkownika Wireshark, stronie man Tsharka i stronie man Tcpdumpa.

Pobieranie narzędzia keytool w Javie

Narzędzie wiersza poleceń keytool powinno być dostarczane z każdą wersją pakietu Java Development Kit (JDK) lub środowiska wykonawczego Java Runtime Environment (JRE). Zainstaluj te pliki, aby uzyskać keytool.. Jednak do weryfikacji certyfikatu głównego prawdopodobnie nie jest potrzebne korzystanie z keytool, chyba że aplikacja została utworzona w języku Java.

Co zrobić w przypadku przerwy w działaniu wersji produkcyjnej

Podstawowym sposobem działania jest zainstalowanie wymaganych certyfikatów głównych z zaufanego pakietu głównego urzędu certyfikacji Google w certyfikatach głównych, z których korzysta Twoja aplikacja.

  1. Skontaktuj się z administratorami systemu, aby zaktualizować lokalny magazyn certyfikatów głównych.
  2. Sprawdź te odpowiedzi na najczęstsze pytania, aby dowiedzieć się, co zrobić w przypadku Twojego systemu.
  3. Jeśli potrzebujesz dodatkowej pomocy dotyczącej konkretnej platformy lub systemu, skontaktuj się z kanałami pomocy technicznej oferowanymi 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ą udzielamy wskazówek tylko w miarę możliwości.
  5. Oznacz gwiazdką problem publiczny 186840968, aby wyświetlić dalsze aktualizacje związane 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 też może zawierać cenne informacje, gdy musisz zaimportować lub wyeksportować certyfikaty główne.

Jeśli problem nie zostanie rozwiązany i zdecydujesz się skontaktować z zespołem pomocy Google Maps Platform, przygotuj się też do podania tych informacji:

  1. Gdzie znajdują się serwery, których to dotyczy?
  2. Do jakich adresów IP Google dzwoni 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;

Instrukcje uzyskiwania wymaganych narzędzi znajdziesz w odpowiedzi na pytanie Gdzie znajdę potrzebne narzędzia?.

Przesyłanie zgłoszenia do zespołu pomocy

Postępuj zgodnie z instrukcjami dotyczącymi tworzenia zgłoszenia do zespołu pomocy w sekcji Pomoc i zasoby Google Maps Platform.

Przesyłając zgłoszenie do zespołu pomocy, oprócz danych wymienionych w sekcji Początkowe rozwiązywanie problemów podaj również:

  • Jakie są Twoje publiczne adresy IP?
  • Jaki jest publiczny adres IP Twojego serwera DNS?
  • Jeśli to możliwe, przechwyć pakiety tcpdump lub Wireshark nieudane negocjacje TLS z https://maps.googleapis.com/ w formacie PCAP z użyciem wystarczająco dużej długości zrzutu, aby przechwycić cały pakiet bez obcinania go (np. -s0 w starszych wersjach pakietu tcpdump).
  • Jeśli to możliwe, dzienniki zawierają fragmenty Twoich usług zawierające dokładny powód niepowodzenia połączenia TLS, najlepiej wraz z informacjami o pełnym łańcuchu certyfikatów serwera.

Instrukcje uzyskiwania wymaganych narzędzi znajdziesz w odpowiedzi na pytanie Gdzie znajdę potrzebne narzędzia?.

Publikowanie w sprawie problemu publicznego: 186840968

Publikując komentarz do problemu publicznego 186840968, podaj informacje wymienione w sekcji Wstępne rozwiązywanie problemów.

Jak mogę określić publiczny adres DNS?

W Linuksie możesz uruchomić to polecenie:

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

W systemie Windows można używać narzędzia nslookup w trybie interaktywnym:

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

Interpretowanie danych wyjściowych curl

Uruchomienie polecenia curl z flagami -vvI dostarcza wielu przydatnych informacji. Oto kilka instrukcji, które pomogą Ci zinterpretować wyniki:

  • Linie zaczynające się od „*” wyświetlają dane wyjściowe negocjacji TLS, a także informacje o zakończeniu połączenia.
  • Wiersze zaczynające się od „>” zawierają wychodzące żądanie HTTP wysyłane przez curl.
  • Wiersze rozpoczynające się od „<” zawierają odpowiedź HTTP otrzymaną z serwera.
  • Jeśli protokół to HTTPS, obecność linii „>” lub „<” oznacza, że proces TLS został pomyślnie zakończony.

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

Uruchomienie curl z flagami -vvI powoduje również wydrukowanie magazynu 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 z systemem Red Hat z systemem Linux i połączeniem curl 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 maszyny 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 pliku PEM certyfikatu głównego Google podanego 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 dostarczyć przydatnych informacji o curl i Twoim systemie.

Przykład dla komputera Red Hat z systemem 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

Linie takie jak te w tym przykładzie kodu wskazują, że połączenie zostało przerwane w trakcie procesu TLS-handshake z powodu niezaufanego certyfikatu serwera. Brak danych wyjściowych debugowania rozpoczynających się od > lub < także wskazuje na nieudaną próbę nawiązania połączenia:

*** 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 sygnalizuje obecność wierszy podobnych do tych w tym przykładowym kodzie. Na liście powinny znajdować się informacje o zestawie mechanizmów szyfrowania używanych w przypadku zaszyfrowanego połączenia oraz szczegóły akceptowanego certyfikatu serwera. Ponadto obecność wierszy zaczynających się od > lub < oznacza, że ruch HTTP ładunku jest pomyślnie przesyłany przez połączenie zaszyfrowane 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 zrozumiałej 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ć wyświetlany certyfikat, wykonując te czynności:

  • Skopiuj cały certyfikat zakodowany w formacie 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 drukować certyfikaty PEM w formie zrozumiałej 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.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 już wspomnieliśmy w pytaniu: Czy aplikacje mobilne mogą się zepsuć?, Od wersji 4.0 Android pozwala użytkownikom telefonów komórkowych weryfikować listę zaufanych certyfikatów w sekcji Ustawienia. Ta tabela pokazuje 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 > Lokalizacja i blokady > Szyfrowanie i dane logowania > Zaufane dane logowania
10+ Ustawienia > Bezpieczeństwo > Zaawansowane > Szyfrowanie i dane logowania > Zaufane dane logowania

Ta tabela przedstawia prawdopodobną dostępność najważniejszych certyfikatów głównych w poszczególnych wersjach Androida na podstawie ręcznej weryfikacji z użyciem obecnie dostępnych obrazów systemu wirtualnego urządzenia z Androidem (AVD), przy użyciu historii wersji certyfikatów ca Gita AOSP, w której nie były już dostępne obrazy systemowe:

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 certyfikatów głównych systemu Android zwykle nie jest możliwa bez aktualizacji oprogramowania lub uzyskania dostępu do roota. Jednak w przypadku większości nadal powszechnie używanych wersji Androida aktualny zestaw zaufanych certyfikatów głównych prawdopodobnie będzie zapewniać niezakłócone działanie usługi przez wiele lat, wykraczając poza efektywny okres eksploatacji większości obecnie używanych urządzeń.

Począwszy od wersji 7.0 Android oferuje deweloperom aplikacji bezpieczną metodę dodawania zaufanych certyfikatów, które są zaufane tylko przez ich aplikacje. Aby to zrobić, dołącz certyfikaty do aplikacji i utwórz niestandardowe ustawienia zabezpieczeń sieci zgodnie z opisem w dokumentacji szkoleniowej Sprawdzone metody dotyczące bezpieczeństwa i prywatności na urządzeniach z Androidem Ustawienia zabezpieczeń sieci.

Deweloperzy aplikacji innych firm nie będą jednak mogli wpływać na konfigurację zabezpieczeń sieci dotyczących ruchu pochodzącego z pakietu APK Usług Google Play, dlatego prawdopodobnie wystarczy częściowe obejście tego problemu.

Na starszych urządzeniach jedyną dostępną opcją jest zaufanie do certyfikatów uwierzytelniających dodanych przez użytkownika, zainstalowanych przez zasady korporacyjne grupy na urządzeniu użytkownika lub przez samego użytkownika.

Magazyn zaufania iOS

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

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

Ta tabela przedstawia 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 jest magazyn systemowych certyfikatów głównych i jak mogę go zaktualizować?

Lokalizacja domyślnego magazynu certyfikatów głównych zależy 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:

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

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

Magazyn certyfikatów głównych OpenSSL

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

openssl version -d

Polecenie powoduje wyświetlenie elementu OPENSSLDIR, który odpowiada katalogowi najwyższego poziomu, w którym znajduje się biblioteka wraz z jej konfiguracjami:

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 przykładzie powyżej, sprawdź sekcję najwyższego poziomu Gdzie jest mój magazyn certyfikatów głównych systemu i jak mogę go zaktualizować?, aby mieć pewność, że pakiet certyfikatów głównych systemu jest aktualny.

Instrukcje uzyskiwania dostępu do openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Magazyn certyfikatów głównych Java

Aplikacje w języku Java mogą używać własnego magazynu certyfikatów głównych, który w systemach Linux znajduje się zwykle w katalogu /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, uruchom to polecenie:

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

Wystarczy zastąpić 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 certyfikatu używanym w Twoim środowisku.

Więcej informacji znajdziesz w tych artykułach na stronach 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 folderze /etc/pki/nssdb, lub domyślnego sklepu użytkownika w folderze ${HOME}/.pki/nssdb.

Aby zaktualizować bazę 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

Po prostu zastąp cert.pem plikiem certyfikatu odpowiadającym każdemu rekomendowanemu certyfikatowi głównemu, cert-name – odpowiednią nazwą certyfikatu, a certdir ścieżką bazy danych certyfikatów używaną w Twoim środowisku.

Więcej informacji znajdziesz w oficjalnej instrukcji NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Magazyn certyfikatów głównych Microsoft .NET

Przy aktualizacji magazynu certyfikatów głównych dla programistów Windows .NET mogą znaleźć się przynajmniej te artykuły firmy Microsoft:

Formaty plików certyfikatu

Co to jest plik PEM?

Privacy Enhanced Mail (PEM) to de facto standardowy format pliku tekstowego do przechowywania i wysyłania certyfikatów kryptograficznych, kluczy itp., sformalizowany jako standard de jure w specyfikacji RFC 7468.

Chociaż format pliku jest zrozumiały dla człowieka, informacje z certyfikatu binarnego zakodowanego w Base64 już nie. Specyfikacja PEM zezwala jednak na wyświetlanie tekstu objaśniającego przed lub po zakodowanej treści certyfikatu. Wiele narzędzi korzysta z tej funkcji, aby wyświetlać w formie jawnego tekstu podsumowanie najważniejszych elementów danych w certyfikacie.

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

Co to jest plik „.crt”?

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

Co to jest plik DER?

Wyróżniające się reguły kodowania (DER) to standardowy format binarny używany do obsługi certyfikatów kodowania. Certyfikaty w plikach PEM to zwykle certyfikaty DER zakodowane w Base64.

Co to jest plik „.cer”?

Wyeksportowany plik z przyrostkiem „.cer” może zawierać certyfikat zakodowany w formacie PEM, ale częściej jest to plik binarny, zwykle z kodowaniem DER. Zgodnie z konwencją pliki „.cer” zawierają zwykle tylko 1 certyfikat.

Mój system odmawia zaimportowania wszystkich certyfikatów z witryny roots.pem

Niektóre systemy, np. Java keytool może importować tylko 1 certyfikat z pliku PEM, nawet jeśli zawiera on kilka certyfikatów. Aby dowiedzieć się, jak można najpierw podzielić plik, przeczytaj artykuł Jak wyodrębnić poszczególne certyfikaty z roots.pem?.

Jak wyodrębnić pojedyncze certyfikaty z pliku roots.pem?

Możesz podzielić plik roots.pem na certyfikaty komponentów, używając 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 pakietu narzędzi OpenSSL 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 uzyskiwania dostępu do openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

Jak przekonwertować plik PEM na format DER?

Za pomocą openssl możesz uruchomić 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?

Aby przekonwertować plik z formatu PEM na format PKCS #7, możesz użyć tego polecenia:

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

Za pomocą openssl możesz uruchomić to polecenie, aby przekonwertować plik 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. Jeśli nie zaimportujesz od razu pliku PKCS 12 do swojego 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ą keytool możesz wydać to polecenie, aby wyświetlić wszystkie certyfikaty 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

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órego będziesz potrzebować, 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

Po prostu 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.

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

Przy użyciu certutil możesz uruchomić to polecenie, aby wyświetlić listę wszystkich certyfikatów w magazynie certyfikatów wraz z pseudonimem, którego możesz używać do eksportowania każdego z nich:

certutil -L -d certdir

Po prostu zastąp certdir ścieżką bazy danych certyfikatów używaną w Twoim środowisku. To polecenie wyświetli też pseudonim każdego certyfikatu – potrzebny do jego wyeksportowania.

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

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

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

Więcej informacji znajdziesz w oficjalnej instrukcji NSS Tools certutil oraz w dokumentacji systemu operacyjnego.

Jak drukować certyfikaty PEM w postaci zrozumiałej dla człowieka

W tych przykładach zakładamy, że masz plik GTS_Root_R1.pem z następującą 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

Wykonywanie polecenia

openssl x509 -in GTS_Root_R1.pem -text

powinno wyświetlić zapytanie podobne 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 uzyskiwania dostępu do openssl znajdziesz w sekcji Uzyskiwanie OpenSSL.

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

Wykonuję następujące polecenie

keytool -printcert -file GTS_Root_R1.pem

powinno wyświetlić zapytanie podobne 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 instalowania keytool znajdziesz w sekcji Pobieranie narzędzia keytool w języku Java.

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

To zależy od systemu operacyjnego i biblioteki SSL/TLS. Jednak narzędzia, które umożliwiają importowanie i eksportowanie certyfikatów do i z magazynu certyfikatów głównych, zwykle udostępniają też jednak 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 plik w formacie zwykłego tekstu.

Plik PEM może być odpowiednio oznaczony etykietami zawierającymi 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-----

Może też zawierać tylko część certyfikatu. W takich przypadkach nazwa pliku, na przykład GTS_Root_R1.pem, może określać, do którego urzędu certyfikacji należy dany certyfikat. Ciąg certyfikatu między tokenami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE----- będzie też unikalny dla każdego urzędu certyfikacji.

Nawet jeśli nie masz powyższych narzędzi, a każdy certyfikat w zaufanym pakiecie głównego urzędu certyfikacji Google jest odpowiednio 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 przez porównanie ciągów certyfikatów pliku PEM.

Przeglądarki internetowe mogą używać własnego magazynu certyfikatów głównych lub korzystać z domyślnego magazynu dostarczonego przez system operacyjny. Wszystkie nowoczesne przeglądarki powinny jednak umożliwiać zarządzanie lub przynajmniej wyświetlanie zestawu głównych urzędów certyfikacji, którym ufają. Więcej informacji znajdziesz w odpowiedzi na pytanie Czy aplikacje JavaScript mogą ulec awarii?.

Instrukcje dotyczące telefonów komórkowych znajdziesz w odrębnym pytaniu Jak sprawdzić zaufane certyfikaty kwalifikujące się jako root 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 bibliotek zewnętrznych, których używa Twoja aplikacja.

Wszelkie inne źródła informacji w tym te FAQ mogą być nieaktualne lub w inny sposób nieprawidłowe i nie należy ich traktować jako wiarygodnych. Nadal możesz jednak znaleźć przydatne informacje w wielu społecznościach pytań i odpowiedzi w Stack Exchange, a także na stronach takich jak AdamW na Linuksie czy blogu z potwierdzeniem.

Zapoznaj się też z najczęstszymi pytaniami na temat usług zaufania Google.

Więcej informacji na temat zaawansowanych zagadnień, takich jak przypinanie certyfikatów, znajdziesz w artykule o przypinaniu certyfikatów i kluczy publicznych (Open Web Application Security Project, OWASP) oraz w przypinaniu ściągawki. Instrukcje dotyczące Androida znajdziesz w oficjalnym dokumencie szkoleniowym Sprawdzone metody zapewniania bezpieczeństwa i prywatności w Androidzie Bezpieczeństwo za pomocą HTTPS i SSL. Do dyskusji na temat przypinania certyfikatów i przypinania kluczy publicznych na Androidzie przydatne może być post Matthew Dolana na blogu Android Security: SSL Pinning (Android Security: Pinning SSL).

Więcej informacji o zarządzaniu dodatkowymi zaufanymi certyfikatami na Androidzie znajdziesz w dokumencie szkoleniowym na temat konfiguracji zabezpieczeń i prywatności w Androidzie dotyczącym konfiguracji bezpieczeństwa sieci oraz poście na blogu JeroenHD Android 7 Nougat i urzędy certyfikacji.

Pełną listę głównych urzędów certyfikacji zaufanych przez AOSP znajdziesz w repozytorium Git ca-certificates. Informacje o wersjach opartych na nieoficjalnych rozwiązaniach na Androida (np. LineageOS) można znaleźć w odpowiednich repozytoriach udostępnionych przez dostawcę systemu operacyjnego.