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 urzędu certyfikacji 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. Pełniejszy przegląd powiązanej terminologii znajdziesz w artykule 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ń z witrynami. 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)
Secure Sockets Layer był najczęściej używanym protokołem do szyfrowania komunikacji w internecie. Protokół SSL nie jest już uważany za bezpieczny i nie jest już obsługiwany w usługach Google.
Transport Layer Security (TLS)
Transport Layer Security jest następcą protokołu SSL.
Urząd certyfikacji (CA)
Urząd certyfikacji to coś w rodzaju cyfrowego urzędu paszportowego dla urządzeń i osób. Wystawia ona dokumenty chronione kryptograficznie (certyfikaty), aby potwierdzić, że dana jednostka (np. witryna) jest tym, za kogo się podaje.
Przed wydaniem certyfikatu urzędy certyfikacji muszą sprawdzić, czy nazwy w certyfikacie są powiązane z osobą lub podmiotem, który go poprosił.
Termin urząd certyfikacji może odnosić się zarówno do organizacji takich jak Google Trust Services, jak i do systemów, które wydają 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 (lub, ściślej mówiąc, jego certyfikat) to najwyższy certyfikat w łańcuchu certyfikatów.
Główne certyfikaty CA są zwykle podpisane samodzielnie. Klucze prywatne powiązane z tymi kontami 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 (a dokładniej jego certyfikat) to certyfikat używany do podpisywania innych certyfikatów w łańcuchu certyfikatów.
Przejściowe urzędy certyfikacji istnieją głównie po to, aby umożliwić wystawianie certyfikatów online, jednocześnie pozwalając certyfikatowi głównego urzędu certyfikacji pozostać offline.
Pośrednie urzędy certyfikacji to także podrzędne urzędy certyfikacji.
Urząd certyfikacji wydający
Urząd certyfikacji wydający certyfikat, a dokładniej jego certyfikat, to certyfikat używany do podpisania ostatniego certyfikatu w łańcuchu certyfikatów.
Ten dolny certyfikat jest zwykle nazywany certyfikatem subskrybenta, certyfikatem jednostki końcowej lub certyfikatem liścia. W tym dokumencie używamy też terminu certyfikat serwera.
Łańcuch certyfikatów
Certyfikaty są powiązane z ich wystawcą (podpisane kryptograficznie). Ł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. Zanim produkty zawierające nowe certyfikaty urzędu certyfikacji zostaną powszechnie używane, minie trochę czasu.
Aby zwiększyć zgodność ze starszymi klientami, certyfikaty urzędu certyfikacji mogą być „podpisane krzyżowo” przez inny starszy urząd certyfikacji. Dzięki temu powstanie drugi certyfikat urzędu certyfikacji dla tej samej tożsamości (nazwy i pary 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

O czym jest ten film?

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 zakończeniu pierwszej fazy bezpieczeństwo TLS usług Google Maps Platform było gwarantowane przez GS Root R2, bardzo dobrze znany i szeroko zaufany główny urząd certyfikacji (CA), który Google nabył od GMO GlobalSign, aby ułatwić przejście na 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 z założenia urząd certyfikacji może 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. wygasł certyfikat GS Root R2, więc Google przeniosło 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 klienci korzystający z Google Maps Platform powinni już rozpoznawać co najmniej jedną z tych zaufanych głównych instytucji certyfikujących lub obie, a druga faza migracji nie powinna mieć na nich żadnego wpływu.

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

Jeśli masz problemy z połączeniem z usługami Google Maps Platform, sprawdź swoje systemy, jeśli występuje co najmniej 1 z tych warunków:

  • Twoje usługi działają na platformach niestandardowych lub starszych albo utrzymujesz własny magazyn certyfikatów głównych.
  • nie podjęto ż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 zaufanej paczki głównego urzędu certyfikacji Google.

Jeśli powyższe dotyczy Twoich klientów, może być konieczne zaktualizowanie ich certyfikatów głównych do zalecanych, aby zapewnić ciągłość korzystania z Google Maps Platform w trakcie 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 w zgodnym z powyższym zbiorem głównych urzędów certyfikacji, aby chronić usługi przed przyszłymi zmianami w głównych urzędach certyfikacji. Będziemy jednak o nich informować z wyprzedzeniem. Więcej informacji o tym, jak być na bieżąco, znajdziesz w sekcji Jak mogę otrzymywać informacje o tej fazie migracji? oraz Jak mogę otrzymywać powiadomienia o przyszłych migracjach?.

Podsumowanie techniczne

Zgodnie z informacją ogłoszoną 15 marca 2021 roku na blogu Google Security GS Root R2, czyli główny certyfikat CA Google Maps Platform używany od początku 2018 roku, wygasł 15 grudnia 2021 roku. Dlatego Google przejdzie na nowo wydany CA GTS Root R1 Cross.

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 zweryfikować systemy co najmniej w przypadku spełnienia obu tych warunków:

  • Twoje usługi działają na niestandardowych lub starszych platformach albo utrzymujesz własny magazyn certyfikatów głównych.
  • nie podjęto ż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 zaufanej paczki 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 mogę otrzymywać informacje o tej fazie migracji?

Oznacz publiczny problem 186840968, aby otrzymywać powiadomienia o aktualizacjach. Te odpowiedzi na najczęstsze pytania są też aktualizowane w trakcie procesu migracji, gdy tylko natrafimy na tematy, które mogą być interesujące dla szerszego grona użytkowników.

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

Zachęcamy do śledzenia bloga Google o bezpieczeństwie. Po ogłoszeniu zmian na blogu postaramy się jak najszybciej zaktualizować dokumentację poszczególnych usług.

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.

Używamy 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. Gdy jednak potwierdzisz, że magazyny certyfikatów głównych używane przez aplikacje klienckie Platformy Map Google zawierają wszystkie urzędy certyfikacji wymienione w zaufanym pakiecie urzędów certyfikacji głównych Google, migracja nie powinna mieć wpływu na Twoje usługi. Zachowanie zgodności tych magazynów z aktualnymi urzędami certyfikacji głównych zapewni Ci też ochronę przed przyszłymi zmianami urzędów certyfikacji głównych.

Aby dowiedzieć się więcej, zapoznaj się z odpowiedziami na pytania Dlaczego powinienem utrzymywać magazyn certyfikatów głównych w synchronizacji z zaufanym pakietem certyfikatów głównych Google? i Które aplikacje mogą przestać działać?.

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 na testowych punktach końcowych:

System będzie 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:
  • postępujesz zgodnie z naszą poprzednią rekomendacją i instalujesz wszystkie główne urzędy certyfikacji z zaufanego pakietu głównego urzędu certyfikacji Google.

Użytkownicy, których to dotyczy, powinni natychmiast zainstalować certyfikaty z zaufanego pakietu głównych certyfikatów urzędu certyfikacji Google, aby uniknąć przerw w działaniu usługi w przyszłości.

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?.

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

Podczas analizowania problemów możesz użyć 2 narzędzi wiersza poleceń: curl i openssl. Oba są dostępne na większości platform i zapewniają wiele opcji testowania konfiguracji.

Instrukcje dotyczące uzyskiwania wartości 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 ją lub zmień 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 też inne przydatne narzędzia.

Instrukcje dotyczące 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 zaufanego pakietu głównego certyfikatu CA Google

Pobierz zaufany pakiet głównych urzędów 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łoszony w styczniu 2017 r., rozpoczął się pod koniec 2017 r. i zakończył w pierwszej połowie 2018 r.
  2. Druga faza (przenoszenie na serwer root R1 Cross GTS) została ogłoszona w marcu 2021 r. i wdrażana w okresie poprzedzającym wygaśnięcie serwera root R2 GS 15 grudnia 2021 r.

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

W przyszłości będziesz jednak mieć możliwość zabezpieczenia swoich aplikacji, jeśli będziesz synchronizować magazyn certyfikatów głównych z wybraną listą głównych urzędów certyfikacji w pakiecie zaufanych głównych urzędów certyfikacji Google.

Aby dowiedzieć się więcej, zapoznaj się też z odpowiedzią na pytanie Dlaczego powinienem utrzymywać synchronizację między repozytorium certyfikatów głównych a zaufowanym pakietem certyfikatów głównych Google CA?.

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

  1. Wdrożenie etapowe rozpoczyna się w pojedynczym centrum danych.
  2. Wprowadzanie tej funkcji jest stopniowo rozszerzane na kolejne centra danych, aż do momentu, gdy będzie ona dostępna na całym świecie.
  3. Jeśli na którymkolwiek etapie zostaną wykryte poważne problemy, testy mogą zostać tymczasowo wycofane, dopóki nie zostaną one rozwiązane.
  4. Na podstawie informacji z poprzednich iteracji dodawane są kolejne usługi Google, aż wszystkie z nich zostaną przeniesione na nowe certyfikaty.

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

Wraz z przenoszeniem nowych centrów danych coraz więcej deweloperów platformy Mapy Google będzie otrzymywać nowe certyfikaty. 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ą przewidzieć, 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 możliwymi fazami 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ę

Klienci, którzy nie mają skonfigurowanego niezbędnego certyfikatu głównego, nie będą mogli zweryfikować połączenia TLS z Platformą Map Google. 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 dotyczące klienta TLS do komunikacji z Google Maps Platform?

Certyfikaty Platformy Map Google korzystają z alternatywnej nazwy podmiotu (SAN) w DNS, więc obsługa certyfikatów klienta musi umożliwiać obsługę SAN, które mogą zawierać pojedynczy symbol wieloznaczny jako etykietę najbardziej lewostronną w nazwie, np. *.googleapis.com.

Chociaż starsze wersje TLS 1.0 i 1.1 są nadal obsługiwane, zalecamy, aby ich nie używać, a w miarę możliwości korzystać z TLS 1.3.

Inne wymagania i zalecenia znajdziesz w sekcjach Jakie są zalecane wymagania dotyczące klienta TLS do komunikacji z Google? i Dlaczego wiele usług Google nadal zezwala na połączenia przy użyciu TLS 1.0 i TLS 1.1? w Najczęstszych pytaniach dotyczących GTS.

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

Aplikacja używa magazynu certyfikatów głównych systemu bez żadnych ograniczeń narzuconych przez dewelopera.

Aplikacje usług internetowych Google Maps Platform

Jeśli używasz popularnego systemu operacyjnego, który jest nadal aktualizowany 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 jest już aktualizowana, możesz mieć lub nie mieć certyfikatu GTS Root R1. Jednak Twój magazyn certyfikatów głównych najprawdopodobniej zawiera GlobalSign Root CA – R1, jeden z najstarszych i najbardziej zaufanych urzędów certyfikacji.

W przypadku aplikacji mobilnych wywołujących bezpośrednio usługi internetowe Google Maps Platform na urządzeniu użytkownika obowiązują wskazówki z pytania Czy aplikacje mobilne mogą przestać działać?.

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 odpowiedzi na pytanie Czy aplikacje mobilne mogą przestać działać?.

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

Musisz 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 lub publicznych kluczy znajdziesz w materiałach zewnętrznych wymienionych w odpowiedzi na pytanie Potrzebujesz więcej informacji?.

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

Wybrana lista certyfikatów głównych CA w zestawie zaufanych certyfikatów głównych CA Google zawiera wszystkie certyfikaty CA, które mogą być używane przez usługi Google w przewidywalnej przyszłości.

Jeśli chcesz, aby Twój system był w przyszłości chroniony, zalecamy, aby sprawdzić, czy magazyn certyfikatów głównych zawiera wszystkie certyfikaty z pakietu, i przyzwyczaić się do synchronizowania tych dwóch elementów.

Jest to szczególnie ważne, jeśli 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.

Aby dowiedzieć się, jak otrzymywać informacje o przyszłych migracjach głównych urzędów certyfikacji, zapoznaj się z odpowiedzią na pytanie Jak mogę otrzymywać powiadomienia o przyszłych migracjach?. Rutynowe zsynchronizowanie magazynu certyfikatów głównych z listą zweryfikowanych certyfikatów zabezpieczy Twoje usługi przed przyszłymi przerwami w ich działaniu spowodowanymi zmianami urzędów certyfikacji. Dzięki temu będą one działać również 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 urzędu certyfikacji mam zaufać? Aby uzyskać więcej zaleceń, zapoznaj się z artykułem Najczęstsze pytania dotyczące 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 zmian może nastąpić w dowolnym momencie i bez wcześniejszego powiadomienia. Dotyczy to również poszczególnych certyfikatów serwera, takich jak te dostarczane przez maps.googleapis.com, a także wszystkich naszych pośrednich urzędów certyfikacji, takich jak GTS Root R1 Cross.

Aby chronić swoje usługi przed takimi atakami, tylko instaluj certyfikaty główne z zaufanej paczki certyfikatów głównego urzędu certyfikacji Google i sprawdzaj wiarygodność całego łańcucha certyfikatów, korzystając z certyfikatu głównego.

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

Czy aplikacje w języku 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 obsługiwanych przeglądarek w przypadku interfejsu Maps JavaScript API.

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

Czy aplikacje mobilne mogą przestać działać?

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, modelu urządzenia i wersji Androida.

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

W przypadku urządzeń z iOS firma Apple prowadzi na swoich stronach pomocy listę zaufanych głównych urzędów certyfikacji dla każdej najnowszej wersji iOS. Wszystkie wersje iOS 5 i nowsze obsługują główny certyfikat CA GlobalSign – 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 odpowiedzi na pytanie Jak sprawdzić zaufane certyfikaty kwalifikujące się jako główne w telefonie?.

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

W ciągu ostatnich lat firma Google współpracowała z głównymi firmami zewnętrznymi, które zajmują się utrzymaniem 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 zaufania głównego GTS firmy Google, w tym GTS Root R1. Jest też bardzo prawdopodobne, że nawet starsze systemy obsługują urząd certyfikacji zaufania głównego GlobalSign Root CA – R1, który będzie używany do podpisywania krzyżowego certyfikatów wydanych przez Google w nadchodzących latach.

Jednak ze względu na to, że terminy włączania certyfikatów innych firm są w dużej mierze poza kontrolą Google, najlepszą ogólną radą, jaką możemy udzielić, jest regularne instalowanie dostępnych aktualizacji systemu.

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

Rozwiązywanie problemów

Gdzie mogę znaleźć potrzebne narzędzia?

Pobieranie skrętu

Jeśli dystrybucja Twojego 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.

Pobieranie OpenSSL

Jeśli dystrybucja systemu operacyjnego nie zawiera pakietu openssl, możesz pobrać źródło z 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 wersji nie jest obsługiwana ani w żaden sposób nie jest zalecana przez zespół OpenSSL.

Pobieranie Wireshark, Tshark lub Tcpdump

Większość dystrybucji Linuksa oferuje wireshark, narzędzie wiersza poleceń tshark i tcpdump. Kompilowane wersje tych programów na inne systemy operacyjne można znaleźć na stronie https://www.wireshark.org.

Kod źródłowy Tcpdump i LibPCAP można znaleźć na stronie 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 keytool, chyba że aplikacja została utworzona w języku Java.

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

Najważniejszym działaniem jest zainstalowanie wymaganych certyfikatów głównych z zaufanego pakietu głównych urzędów certyfikacji Google w magazynie certyfikatów głównych używanym przez Twoją aplikację.

znajdziesz jednak przydatne informacje.
  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 w sposób opisany w sekcji Kontakt z zespołem pomocy Google Maps Platform. Uwaga: w przypadku problemów związanych z konkretną platformą wskazówki są podawane tylko w ramach możliwości.
  5. Aby uzyskać więcej informacji o migracji, otwórz publiczny problem 186840968.

Kontakt z zespołem pomocy Google Maps Platform

Wstępne rozwiązywanie problemów

Aby uzyskać ogólne instrukcje rozwiązywania problemów, zapoznaj się z sekcją Jak sprawdzić, czy mój magazyn certyfikatów głównych wymaga aktualizacji.

Jeśli chcesz importować lub eksportować certyfikaty główne, możesz też znaleźć przydatne informacje w sekcji Zarządzanie zaufanymi certyfikatami.

Jeśli problem nie zostanie rozwiązany i zdecydujesz się skontaktować z zespołem pomocy Map Google, bądź gotów podać te informacje:

  1. Gdzie znajdują się serwery, których to dotyczy?
  2. Do jakich adresów IP Google dzwoni Twoja usługa?
  3. Które interfejsy API są objęte tym problemem?
  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 dotyczące niezbędnych narzędzi znajdziesz w pytaniu Gdzie mogę kupić 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ć pakiet tcpdump lub Wireshark z nieudaną negocjacją TLS w usłudze https://maps.googleapis.com/ w formacie PCAP, używając wystarczająco dużej długości zrzutu, aby przechwycić cały pakiet bez jego obcinania (np. używając -s0 w starszych wersjach tcpdump).
  • Jeśli to możliwe, wyciągi z dzienników usługi, które pokazują dokładny powód błędu połączenia TLS, najlepiej z pełnymi informacjami o łańcuchu certyfikatów serwera.

Instrukcje dotyczące niezbędnych narzędzi znajdziesz w pytaniu Gdzie mogę kupić potrzebne narzędzia?.

Publikowanie informacji o publicznym problemie 186840968

Dodając komentarz do publicznego zgłoszenia 186840968, podaj informacje wymienione w sekcji Początkowe rozwiązywanie problemów.

Jak mogę określić 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 interaktywności:

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

Interpretowanie danych wyjściowych curl

Uruchomienie curl z flagami -vvI zapewnia wiele przydatnych informacji. Oto kilka instrukcji dotyczących interpretacji danych wyjściowych:

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

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

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

Dane wyjściowe z komputera z systemem Red Hat Linux z 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 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

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

Przykład 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,

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 debugowania rozpoczynających się od > lub < również wskazuje na nieudaną próbę 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 ustanowienie połączenia TLS jest sygnalizowane przez obecność linii podobnych do tych w tym przykładowym kodzie. Należy podać zestaw szyfrowania używany do szyfrowania połączenia, a także szczegóły akceptowanego certyfikatu serwera. Ponadto obecność linii zaczynających się od > lub < wskazuje, że ładunek danych HTTP jest pomyślnie przesyłany przez połączenie szyfrowane 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ść schowka 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 z podpisem krzyżowym 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 sprawdzić zaufane certyfikaty kwalifikujące się na urządzeniu mobilnym?

Zaufane certyfikaty Androida

Jak już wspomnieliśmy w odpowiedzi na pytanie Czy aplikacje mobilne mogą przestać działać?, Od wersji 4.0 Android pozwala użytkownikom telefonów komórkowych weryfikować listę nieznanych 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 > Bezpieczeństwo > Zaufane dane logowania
8.x, 9 Ustawienia > Bezpieczeństwo i lokalizacja > Szyfrowanie i dane logowania > Zaufane dane logowania
10+ Ustawienia > Bezpieczeństwo > Zaawansowane > Szyfrowanie i dane logowania > Zaufane dane logowania

Ta tabela przedstawia prawdopodobne udostępnienie najważniejszych certyfikatów roota w przypadku poszczególnych wersji Androida na podstawie ręcznej weryfikacji za pomocą obecnie dostępnych obrazów systemu Android Virtual Device (AVD) z użyciem certyfikatów CA z AOSP w historii wersji repozytorium Git, w których obrazy systemu nie były już dostępne:

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

Aktualizacja magazynu certyfikatów głównego systemu Androida jest zazwyczaj niemożliwa bez aktualizacji oprogramowania lub zrootowania urządzenia. Jednak w przypadku większości wersji Androida, które są nadal szeroko używane, obecny zestaw zaufanych certyfikatów głównych prawdopodobnie zapewni nieprzerwaną obsługę przez wiele lat, nawet po upływie okresu użytkowania większości obecnie dostępnych urządzeń.

Od wersji 7.0 Android oferuje deweloperom aplikacji bezpieczną metodę dodawania zaufanych certyfikatów, które są zaufane tylko przez ich aplikację. 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 w przypadku ruchu pochodzącego z pliku APK Usług Google Play, więc takie działania prawdopodobnie przyniosą tylko częściowe rozwiązanie.

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 znajduje się magazyn certyfikatów głównych systemu i jak 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 Linuksa domyślne certyfikaty root znajdziesz w jednym z tych katalogów:

  • /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ę zainstalowanych komponentów, w tym domyślnego magazynu certyfikatów głównych, za pomocą tego polecenia:

openssl version -d

Polecenie zwraca wartość OPENSSLDIR, która odpowiada najwyższemu poziomowi katalogu biblioteki. Biblioteka i jej konfiguracje znajdują się w następujących miejscach:

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 dotyczące instalacji openssl znajdziesz w sekcji Instalowanie 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 w Oracle i na Stack Overflow:

magazyn certyfikatów głównych Mozilla NSS.

Aplikacje korzystające z Mozilla NSS mogą domyślnie używać również bazy danych certyfikatów w całym systemie, która znajduje się zwykle w folderze /etc/pki/nssdb, lub domyślnego magazynu 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

Wystarczy zastąpić cert.pem plikiem certyfikatu odpowiadającym każdemu zalecanemu certyfikatowi głównemu, cert-name – zwięzłym pseudonimem certyfikatu, a certdir – ścieżką do bazy danych certyfikatu używanej w środowisku.

Więcej informacji znajdziesz w oficjalnej dokumentacji narzędzi NSS certutil oraz w dokumentacji systemu operacyjnego.

Magazyn certyfikatów głównych Microsoft .NET

Deweloperzy aplikacji .NET w Windows mogą znaleźć przydatne informacje o aktualizowaniu magazynu certyfikatów głównych w tych artykułach firmy Microsoft:

Formaty plików certyfikatów

Co to jest plik PEM?

Privacy Enhanced Mail (PEM) to de facto standardowy format pliku tekstowego służący do przechowywania i wysyłania certyfikatów kryptograficznych, kluczy itp. Formalnie jest to standard de jure określony w specyfikacji RFC 7468.

Sam format pliku jest czytelny dla człowieka, ale informacje o danych certyfikatu zakodowane w binarnym formacie Base64 nie są. Specyfikacja PEM zezwala jednak na emitowanie treści wyjaśniającej przed lub po zakodowanym tekście treści certyfikatu. Wiele narzędzi wykorzystuje tę funkcję, aby wyświetlać w czystym tekście podsumowanie najważniejszych elementów danych w certyfikacie.

Do dekodowania całego certyfikatu w postaci zrozumiałej dla człowieka można też użyć narzędzi takich jak openssl. Więcej informacji znajdziesz w sekcji Jak wydrukować certyfikaty PEM w postaci czytelnej dla człowieka.

Co to jest plik „.crt”?

Narzędzia, które umożliwiają eksportowanie certyfikatów w formacie PEM, często 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 do kodowania certyfikatów. Certyfikaty w plikach PEM są zwykle certyfikatami DER zakodowanymi w formacie 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 importowania wszystkich certyfikatów z pliku 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 najpierw podzielić plik, zapoznaj się z odpowiedzią na pytanie Jak wyodrębnić poszczególne certyfikaty z pliku roots.pem?.

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

Możesz podzielić plik roots.pem na certyfikaty komponentów za pomocą 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

Powinieneś uzyskać kilka plików PEM podobnych do tych wymienionych poniżej:

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żna następnie importować osobno lub przekonwertować je na format pliku akceptowany przez 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 dotyczące instalacji openssl znajdziesz w sekcji Instalowanie OpenSSL.

Jak przekonwertować plik PEM na format DER?

Za pomocą openssl możesz użyć tego polecenia, aby przekonwertować plik z formatu PEM na DER:

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

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

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

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

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

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

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

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

Za pomocą 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

Wystarczy zastąpić 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 to polecenie:

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

Wystarczy zastąpić certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku i podać 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 wydać to polecenie, aby wyświetlić wszystkie certyfikaty w Twoim magazynie certyfikatów wraz z pseudonimami, których możesz użyć do wyeksportowania każdego z nich:

certutil -L -d certdir

Wystarczy zastąpić certdir ścieżką do bazy danych certyfikatów używanej w Twoim środowisku. To polecenie wyświetli też pseudonim każdego certyfikatu, którego będziesz potrzebować, jeśli chcesz go wyeksportować.

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

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

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

Więcej informacji znajdziesz w oficjalnej dokumentacji narzędzi NSS certutil oraz w dokumentacji systemu operacyjnego.

Jak wydrukować certyfikaty PEM w formie zrozumiałej dla człowieka

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

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

Wydawanie polecenia

openssl x509 -in GTS_Root_R1.pem -text

Powinny pojawić się dane wyjściowe podobne do tych:

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 instalacji openssl znajdziesz w sekcji Instalowanie OpenSSL.

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

Uruchom to polecenie:

keytool -printcert -file GTS_Root_R1.pem

Powinny pojawić się dane wyjściowe podobne do tych:

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 Instalowanie narzędzia keytool w języku Java.

Jak sprawdzić, które certyfikaty są zainstalowane w moim magazynie głównych urzędów certyfikacji?

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ż opcję wyświetlania zainstalowanych certyfikatów.

Jeśli zaufane główne urzędy certyfikacji zostały wyeksportowane do plików PEM lub jeśli w magazynie głównych urzędów certyfikacji są już zapisane pliki PEM, możesz spróbować otworzyć te pliki w dowolnym edytorze tekstu, ponieważ są one w formacie zwykłego tekstu.

Plik PEM może być odpowiednio oznaczony i zawierać informacje o powiązanym urzędzie certyfikacji (np. z zaufanego pakietu urzędu głównego CA 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 zawierać tylko część certyfikatu. W takich przypadkach nazwa pliku, np. GTS_Root_R1.pem, może wskazywać, do którego urzędu certyfikacji należy certyfikat. Ciąg certyfikatu między tokenami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE----- jest też gwarantowany jako unikalny dla każdego urzędu certyfikacji.

Jednak nawet jeśli nie masz tych narzędzi, ponieważ każdy certyfikat w pakiecie zaufanych głównych urzędów certyfikacji Google jest odpowiednio oznaczony, możesz niezawodnie dopasować główne urzędy certyfikacji z pakietu do tych z magazynu certyfikatów głównych, korzystając z Issuer lub porównując ciągi znaków certyfikatu 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 co najmniej wyświetlanie zestawu zaufanych głównych urzędów certyfikacji. Więcej informacji znajdziesz w odpowiedzi na pytanie Czy aplikacje JavaScript mogą przestać działać?.

Instrukcje dotyczące telefonów komórkowych znajdziesz w odrębnym pytaniu Jak sprawdzić zaufane certyfikaty kwalifikujące się na urządzeniu mobilnym?.

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 powinny być traktowane jako wiarygodne. Możesz jednak znaleźć przydatne informacje w wielu społecznościach Q&A na Stack Exchange, a także na takich stronach jak AdamW na Linuxie i inne oraz blog confirm.

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

Więcej informacji o zaawansowanych tematach, takich jak przypinanie certyfikatów, znajdziesz w artykule Certificate and Public Key Pinning organizacji Open Web Application Security Project (OWASP) oraz w ściągawce na temat przypinania. Instrukcje dotyczące Androida znajdziesz w oficjalnym dokumencie Android Best Practices for Security & Privacy (Sprawdzone metody dotyczące bezpieczeństwa i prywatności w Androidzie) oraz Security with HTTPS and SSL (Bezpieczeństwo z HTTPS i SSL). Aby dowiedzieć się więcej o tym, czy lepiej jest używać certyfikatu czy przypinania klucza publicznego na Androidzie, przeczytaj post Matthew Dolana na blogu Bezpieczeństwo na Androidzie: przypinanie certyfikatu SSL.

Więcej informacji o zarządzaniu dodatkowymi zaufanymi certyfikatami w Androidzie znajdziesz w dokumentach sprawdzonych metod zapewnienia bezpieczeństwa i prywatności w Androidzie Konfiguracja zabezpieczeń sieci oraz w poście na blogu JeroenHD Android 7 Nougat i certyfikaty CA.

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