Najczęstsze pytania o migrację urzędu certyfikacji w Google Maps Platform

Niniejszy dokument obejmuje następujące sekcje:

Bardziej szczegółowe informacje na temat trwającej migracji głównego urzędu certyfikacji Google znajdziesz w artykule Co się dzieje?.

Terminologia

Poniżej zebraliśmy listę najważniejszych terminów, które warto znać w tym dokumencie. Bardziej wyczerpujące omówienie powiązanej terminologii znajdziesz w odpowiedziach na najczęstsze pytania dotyczące usług zaufania Google.

Certyfikat SSL/TLS
Certyfikat wiąże klucz kryptograficzny z tożsamością.
Certyfikaty SSL/TLS służą do uwierzytelniania i nawiązywania bezpiecznych połączeń ze stronami internetowymi. Certyfikaty są wystawiane i podpisywane kryptograficznie przez podmioty nazywane urzędami certyfikacji.
Przeglądarki wykorzystują certyfikaty wystawione przez zaufane urzędy certyfikacji, aby wiedzieć, że przesyłane informacje są wysyłane do właściwego serwera i szyfrowane podczas przesyłania.
SSL (Secure Sockets Layer)
Protokół Secure Sockets Layer był najpopularniejszym protokołem wykorzystywanym do szyfrowania komunikacji internetowej. Protokół SSL nie jest już uważany za bezpieczny i nie należy go używać.
TLS (Transport Layer Security)
Transport Layer Security to następca protokołu SSL.
Urząd certyfikacji
Urząd certyfikacji jest jak cyfrowy urząd paszportowy dla urządzeń i osób. Wysyła chronione kryptograficznie dokumenty (certyfikaty), aby potwierdzić, że dany podmiot (np. strona internetowa) jest tym, za kogo się podaje.
Przed wystawieniem certyfikatu urzędy certyfikacji muszą sprawdzić, czy imię i nazwisko w certyfikacie są powiązane z osobą lub podmiotem, który z niego wnioskuje.
Termin „Urząd certyfikacji” może odnosić się zarówno do organizacji, takich jak Google Trust Services, jak i do systemów wystawiających certyfikaty.
Magazyn certyfikatów głównych
Magazyn certyfikatów głównych zawiera zestaw urzędów certyfikacji zaufanych przez dostawcę oprogramowania do aplikacji. Większość przeglądarek i systemów operacyjnych ma własny magazyn certyfikatów głównych.
Aby urząd certyfikacji mógł znaleźć się w magazynie certyfikatów głównych, musi spełniać rygorystyczne wymagania określone przez dostawcę oprogramowania do aplikacji.
Zwykle obejmuje to zgodność ze standardami branżowymi, takimi jak wymagania forum CA/przeglądarki.
Główny urząd certyfikacji
Główny urząd certyfikacji (lub jego certyfikat) to najwyższy certyfikat w łańcuchu certyfikatów.
Główne certyfikaty CA są zwykle podpisane samodzielnie. Powiązane z nimi klucze prywatne są przechowywane w bardzo bezpiecznych miejscach i przechowywane w stanie offline, aby chronić je przed nieuprawnionym dostępem.
Pośredni urząd certyfikacji
Pośredni urząd certyfikacji (lub jego certyfikat) to certyfikat używany do podpisywania innych certyfikatów w łańcuchu certyfikatów.
Pośrednie urzędy certyfikacji służą głównie do wystawiania certyfikatów online, a jednocześnie pozwalają certyfikatowi głównego CA pozostawać w trybie offline.
Pośrednie urzędy certyfikacji są też nazywane podrzędnymi urzędami certyfikacji.
Urząd certyfikacji wydający
Wystawca certyfikatu (lub, bardziej dokładny) to certyfikat używany do podpisywania certyfikatu znajdującego się najniżej w łańcuchu certyfikatów.
Ten certyfikat, który znajduje się na samym dole, jest nazywany certyfikatem subskrybenta, certyfikatem jednostki końcowej lub certyfikatem jednostki końcowej. W tym dokumencie używamy również terminu certyfikat serwera.
Łańcuch certyfikatów
Certyfikaty są powiązane (podpisywane kryptograficznie przez) ich wystawcy. Łańcuch certyfikatów składa się z certyfikatu liścia, wszystkich certyfikatów wystawcy i certyfikatu głównego.
Podpisywanie krzyżowe
Klienci dostawcy oprogramowania aplikacji muszą zaktualizować magazyn certyfikatów głównych, dodając nowe certyfikaty CA, aby ich produkty były zaufane. Może minąć trochę czasu, zanim produkty zawierające nowe certyfikaty CA będą powszechnie używane.
Aby zwiększyć zgodność ze starszymi klientami, certyfikaty CA mogą być podpisywane krzyżowo przez inny starszy urząd certyfikacji. W ten sposób powstanie drugi certyfikat CA dla tej samej tożsamości (nazwa i para kluczy).
W zależności od tego, jakie urzędy certyfikacji znajdują się w magazynie certyfikatów głównych, klienci utworzą inny łańcuch certyfikatów aż do poziomu głównego, którym ufają.

Informacje ogólne

Co się dzieje?

Koncepcja

W 2017 roku firma Google rozpoczęła wieloletni projekt polegający na wystawianiu i wykorzystywaniu własnych certyfikatów głównych – podpisów kryptograficznych, które stanowią podstawę zabezpieczeń internetowych TLS używanych przez HTTPS.

Po zakończeniu pierwszej fazy bezpieczeństwo TLS usług Google Maps Platform jest gwarantowane przez GS Root R2 – bardzo znany i powszechnie zaufany główny urząd certyfikacji (CA), który przejęto od GMO GlobalSign, aby ułatwić przejście na własne, samodzielnie przyznawane główne urzędy certyfikacji Google Trust Services (GTS).

Praktycznie wszystkie klienty TLS (np. przeglądarki, smartfony i serwery aplikacji) ufają temu certyfikatowi głównemu i dlatego mogą nawiązać bezpieczne połączenie z serwerami Google Maps Platform podczas pierwszej fazy migracji.

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

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

Dlatego większość klientów Google Maps Platform będzie już rozpoznawać te dobrze zaufane główne urzędy certyfikacji (lub oba te typy urzędów certyfikacji), więc druga faza migracji nie będzie mieć na nie żadnego wpływu.

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

Sprawdź swoje systemy w następujących przypadkach:

  • Twoje usługi używają platform niestandardowych lub starszych bądź masz własny magazyn certyfikatów głównych
  • w latach 2017–2018 nie zostały przez Ciebie podjęte żadne działania podczas pierwszej fazy migracji głównego urzędu certyfikacji Google lub nie zainstalowano pełnego zestawu certyfikatów z pakietu zaufanych certyfikatów głównych Google.

Jeśli występuje ta sytuacja, może być konieczne zaktualizowanie klientów przy użyciu zalecanych certyfikatów głównych, aby mieć pewność, że podczas tej fazy migracji Google Maps Platform będzie działać bez zakłóceń.

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

Zalecamy także dalsze synchronizowanie magazynów certyfikatów głównych z powyższem wyselekcjonowanym pakietem głównego urzędu certyfikacji, aby zabezpieczyć usługi przed przyszłymi zmianami głównego urzędu certyfikacji. Będą one jednak ogłaszane z wyprzedzeniem. Zapoznaj się z sekcjami Jak mogę uzyskać aktualne informacje na temat tej fazy migracji? i Jak mogę otrzymać powiadomienie o przyszłych migracji?, aby dowiedzieć się, jak być na bieżąco.

Podsumowanie techniczne

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

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

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

  • Twoje usługi działają na niestandardowych lub starszych platformach albo masz własny magazyn certyfikatów głównych
  • w latach 2017–2018 nie zostały przez Ciebie podjęte żadne działania podczas pierwszej fazy migracji głównego urzędu certyfikacji Google lub nie zainstalowano pełnego zestawu certyfikatów z pakietu zaufanych certyfikatów głównych Google.

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

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

Jak mogę uzyskać informacje na temat tego etapu migracji?

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

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

Zachęcamy do śledzenia bloga Google o bezpieczeństwie. Będziemy też starać się jak najszybciej aktualizować dokumentację dotyczącą poszczególnych usług zgodnie z ogłoszeniem opublikowanym na blogu.

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

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

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

Zapoznaj się z pytaniami: Dlaczego warto synchronizować magazyn certyfikatów głównych z zaufanym pakietem głównego urzędu certyfikacji Google? i Jakie rodzaje aplikacji są zagrożone awariami?, aby uzyskać więcej informacji.

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

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

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

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

  • Twoja usługa działa w utrzymywanym głównym systemie operacyjnym, a zarówno system operacyjny, jak i biblioteki, z których korzysta Twoja usługa, oraz nie utrzymujesz własnego magazynu certyfikatów głównych lub
  • postępujesz zgodnie z naszymi poprzednimi zaleceniami i zainstalowałeś wszystkie główne urzędy certyfikacji z zaufanego pakietu głównego urzędów certyfikacji Google
podczas pierwszej.

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

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

Czy istnieje proste narzędzie, za pomocą którego mogę sprawdzić nasz magazyn certyfikatów głównych?

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

Instrukcje dotyczące uzyskiwania curl znajdziesz w sekcji Tworzenie zwinięcia poniżej.

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

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

Szczegółowe 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

Pobierz pakiet zaufanego głównego urzędu certyfikacji Google, a następnie wykonaj te czynności:

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

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

  1. Pierwsza faza (przejście na GS Root R2), ogłoszona w styczniu 2017 r., rozpoczęła się pod koniec 2017 roku i zakończyła się w pierwszej połowie 2018 roku.
  2. Faza druga (przejście na GTS Root R1 Cross) została ogłoszona w marcu 2021 r.

Harmonogramy późniejszych faz migracji ogłosimy z dużym wyprzedzeniem, zanim wygasną certyfikaty.

Jeśli jednak będziesz utrzymywać zgodność magazynu certyfikatów głównych z wyselekcjonowaną listą głównych urzędów certyfikacji w pakiecie głównych urzędów certyfikacji Google, będziesz mieć możliwość dostosowania aplikacji do przyszłych wymagań.

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

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

  1. Wdrażanie etapowe rozpoczyna się w jednym centrum danych.
  2. Stopniowo rozszerzamy je na kolejne centra danych, aż do momentu, gdy staną się dostępne na całym świecie.
  3. Jeśli na którymkolwiek etapie zostaną wykryte poważne problemy, możesz tymczasowo wycofać testy i rozwiązać problemy.
  4. Na podstawie danych wejściowych z poprzednich iteracji kolejne usługi Google będą uwzględniane we wdrażaniu, aż do stopniowego przeniesienia wszystkich usług Google do nowych certyfikatów.

Kogo, kiedy i gdzie dotyczą zmiany?

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

Nie możemy z wyprzedzeniem określić, kogo i kiedy będzie to dotyczyć, dlatego zalecamy wszystkim naszym klientom sprawdzenie i zadbanie o swoje usługi na przyszłość, zanim rozpocznie się migracja głównego urzędu certyfikacji Google.

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

Na co zwrócić uwagę

Klienty, które nie mają wymaganego certyfikatu głównego, nie będą mogły zweryfikować swojego połączenia TLS z Google Maps Platform. W takiej sytuacji klient zwykle wyświetla ostrzeżenie o niepowodzeniu weryfikacji certyfikatu.

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

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

Certyfikaty Google Maps Platform wykorzystują alternatywne nazwy podmiotu DNS, dlatego obsługa certyfikatów klienta musi obsługiwać certyfikaty SAN, które mogą zawierać w nazwie pojedynczy symbol wieloznaczny znajdujący się jako skrajnie po lewej stronie, np. *.googleapis.com.

Inne wymagania znajdziesz w sekcji Jakie są zalecane wymagania dotyczące komunikacji klienta TLS z Google w Najczęstszych pytaniach dotyczących GTS.

Jakiego typu aplikacje są zagrożone awarią?

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

Aplikacje usług internetowych Google Maps Platform

Jeśli korzystasz z popularnego systemu operacyjnego, na przykład Ubuntu, Red Hat, Windows 10, Server 2019 czy OS X), który jest nadal aktualizowany 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óry nie jest już aktualizowany, być może nie masz certyfikatu GTS Root R1. Jednak magazyn certyfikatów głównych prawdopodobnie będzie zawierać 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ą przestać działać?.

Aplikacje Google Maps Platform po stronie klienta

Aplikacje JavaScript API Map Google korzystają zwykle z certyfikatów głównych przeglądarki, w której się ona uruchamia. Więcej informacji znajdziesz w sekcji Czy aplikacje JavaScript mogą przestać działać?.

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

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

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

Musisz samodzielnie zaktualizować pakiet certyfikatów. Zgodnie z tym, o co chodzi w pytaniu: Dlaczego warto synchronizować magazyn certyfikatów głównych z pakietem zaufanych certyfikatów głównych Google? Zalecamy zaimportowanie wszystkich certyfikatów z zaufanych pakietów głównych urzędów certyfikacji Google do własnego magazynu certyfikatów głównych.

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

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

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

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

Dlatego jeśli chcesz zabezpieczyć system na przyszłość, zdecydowanie zalecamy sprawdzenie, czy magazyn certyfikatów głównych zawiera wszystkie certyfikaty z pakietu, i wyrobienie nawyku synchronizacji obydwu.

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

Zapoznaj się z pytaniem Jak mogę otrzymać powiadomienie o przyszłych migracji?, aby dowiedzieć się, jak otrzymywać aktualizacje o przyszłych migracji głównego urzędu certyfikacji. Rutynowo synchronizowanie magazynu certyfikatów głównych z wyselekcjonowaną listą pozwoli chronić usługi przed kolejnymi przerwami w działaniu usługi spowodowanymi zmianami urzędów certyfikacji, a także nieprzerwanie działać po wygaśnięciu ważności zarówno GTS Root R1 Cross, jak i GlobalSign Root CA – R1.

Zadaj też pytanie Tworzę produkt, który łączy się z usługami Google. Jakimi certyfikatami CA muszę ufać? Więcej zaleceń znajdziesz w najczęstszych pytaniach dotyczących GTS.

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

Może to spowodować uszkodzenie aplikacji za każdym razem, gdy zarejestrujemy nowy certyfikat lub zmienimy pośrednie urzędy certyfikacji. Może się to zdarzyć w dowolnym momencie i bez wcześniejszego powiadomienia. Dotyczy to w równym stopniu poszczególnych certyfikatów serwera, takich jak maps.googleapis.com, a także dowolnych pośrednich urzędów certyfikacji, np. GTS Root R1 Cross.

Aby chronić swoje usługi przed tym ryzykiem, instaluj tylko certyfikaty główne z zaufanego pakietu głównego urzędu certyfikacji Google oraz polegaj tylko na certyfikacie głównym w celu weryfikacji wiarygodności całego zakotwiczonego łańcucha certyfikatów.

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ą przestać działać?

Certyfikaty główne GTS są już dobrze osadzone i cieszą się zaufaniem większości nowoczesnych przeglądarek, a podpisywanie krzyżowe z GMO GlobalSign powinno zapewnić płynną migrację nawet w przypadku większości użytkowników korzystających ze starszych przeglądarek. Dotyczy to wszystkich oficjalnie obsługiwanych przeglądarek korzystających z interfejsu Maps JavaScript API.

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

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

Urządzenia z Androidem i Apple iOS, które wciąż otrzymują regularne aktualizacje od ich producentów, powinny być gotowe na przyszłość. 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.

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

W przypadku urządzeń z iOS na stronach pomocy firmy Apple przechowuje listę zaufanych głównych urzędów certyfikacji dla każdej najnowszej wersji iOS. Jednak wszystkie wersje iOS w wersji 5 lub nowszej obsługują GlobalSign Root CA - R1.

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

Zobacz pytanie: Jak sprawdzić zaufane certyfikaty główne na telefonie komórkowym?, aby uzyskać więcej informacji.

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

W ciągu ostatnich lat firma Google intensywnie współpracowała z dużymi firmami zewnętrznymi w celu utrzymania powszechnie używanych i zaufanych pakietów certyfikatów głównych. Są to na przykład producenci systemów operacyjnych, tacy jak Apple i Microsoft, ale także zespoły Google zajmujące się Androidem i Chrome OS; deweloperzy przeglądarek, np. Mozilla, Apple, Microsoft, ale także zespół Google Chrome; producenci sprzętu, np. telefony, dekodery, telewizory, konsole do gier, drukarki.

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

Jednak ramy czasowe uwzględniania certyfikatów innych firm w dużej mierze pozostają poza kontrolą Google, dlatego najlepszą ogólną poradą jest to, aby regularnie wprowadzać dostępne aktualizacje systemu.

Wybrane firmy zewnętrzne, takie jak Mozilla’s CA Certificate Program, mogły udokumentować własne ramy czasowe uwzględniania certyfikatów.

Rozwiązywanie problemów

Gdzie znajdę potrzebne narzędzia?

Uruchamiam zwinięcie

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

Korzystanie z OpenSSL

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

Uzyskiwanie plików Wireshark, Tshark lub Tcpdump

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

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

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

Uzyskiwanie narzędzia Keytool Java

Narzędzie wiersza poleceń keytool powinno być dołączone do każdej wersji pakietu Java Development Kit (JDK) lub Java Runtime Environment (JRE). Zainstaluj je, aby uzyskać keytool.. Jednak używanie keytool raczej nie będzie konieczne do weryfikacji certyfikatu głównego, chyba że aplikacja została utworzona w Javie.

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

Podstawowym sposobem działania jest zainstalowanie wymaganych certyfikatów głównych z pakietu zaufanych certyfikatów głównych CA Google w magazynie certyfikatów głównych używanych przez Twoją aplikację.

  1. Skontaktuj się z administratorami systemu, aby uaktualnić lokalny magazyn certyfikatów głównych.
  2. W tym artykule znajdziesz najczęściej zadawane pytania dotyczące Twojego systemu.
  3. Jeśli potrzebujesz dalszej pomocy dotyczącej platformy lub systemu, skontaktuj się z zespołem pomocy technicznej oferowanym 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ą podajemy wskazówki wyłącznie w ramach najlepszych starań.
  5. Oznacz gwiazdką problem publiczny 186840968 w celu uzyskania dalszych aktualizacji związanych z migracją.

Kontakt z zespołem pomocy Google Maps Platform

Wstępne rozwiązywanie problemów

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

Sekcja Zarządzanie zaufanymi certyfikatami też może zawierać cenne informacje, jeśli musisz zaimportować lub wyeksportować certyfikaty główne.

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

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

  5. Dane wyjściowe następujących poleceń:

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

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

Przesyłanie zgłoszenia do pomocy technicznej

Postępuj zgodnie z instrukcjami 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 Wstępne rozwiązywanie problemów podaj też:

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

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

Publikowanie w sprawie publicznego 186840968

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

Jak mogę ustalić adres publiczny mojego serwera DNS?

W Linuksie możesz uruchomić to polecenie:

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

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

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

Jak interpretować dane wyjściowe curl

Użycie kodu curl z flagami -vvI dostarcza wielu przydatnych informacji. Oto kilka instrukcji, które pomogą Ci interpretować dane wyjściowe:

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

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

Uruchomienie polecenia curl z flagami -vvI powoduje też wydrukowanie magazynu używanych certyfikatów głównych, ale dokładny wynik może się różnić w zależności od systemu, jak pokazano tutaj.

Dane wyjściowe komputera z systemem Red Hat z systemem Linux, w którym połączenie curl jest połączone z NSS, może zawierać te wiersze:

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

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

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

Dane wyjściowe komputera z systemem Ubuntu lub Debian z systemem Linux przy użyciu pliku PEM certyfikatu głównego Google podanego przy użyciu 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 klienta użytkownika, który może zawierać przydatne informacje o curl i Twoim systemie.

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

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

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

Udane uzgadnianie połączenia TLS

Pomyślne uzgadnianie połączenia TLS jest sygnalizowane obecnością wierszy podobnych do tych w tym przykładowym kodzie. Powinny się tam znajdować informacje o zestawie szyfrów używanym do szyfrowanego połączenia oraz o akceptowanym certyfikacie serwera. Ponadto obecność wierszy zaczynających się od > lub < oznacza, że ruch HTTP ładunku jest prawidłowo przesyłany przez szyfrowane połączenie TLS:

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

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

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

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

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

  • Następnie wykonaj te czynności:

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

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

  • Naciśnij klawisz Return.

Przykłady danych wejściowych i wynikowych znajdziesz w sekcji Jak drukować certyfikaty PEM w postaci czytelnej dla człowieka.

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

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.pki.goog

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

---
…

Zarządzanie zaufanymi certyfikatami

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

Zaufane certyfikaty Androida

Jak już wspomnieliśmy w pytaniu Czy aplikacje mobilne mogą przestać działać?, Android od wersji 4.0 zezwala użytkownikom telefonów na sprawdzanie listy zaufanych certyfikatów w Ustawieniach. Ta tabela zawiera dokładną ścieżkę menu Ustawienia:

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

Ta tabela pokazuje prawdopodobne dostępność najbardziej krytycznych certyfikatów głównych w poszczególnych wersjach Androida na podstawie weryfikacji ręcznej z użyciem aktualnie dostępnych obrazów systemu urządzenia wirtualnego z Androidem (AVD). Dane pochodzą z historii wersji repozytoriów Git w repozytorium AOSP, gdzie obrazy systemu nie były już dostępne:

Wersja Androida GTS główny R1 Główny urząd certyfikacji GlobalSign – R1 GlobalSign Root R2 (ważny do 15 grudnia 2021 r.)
2,3, 3,2, 4,x, 5,x, 6,x, 7,x, 8,x, 9
10+

Aktualizacja magazynu certyfikatów głównych systemu Android jest zwykle niemożliwa bez aktualizacji oprogramowania układowego lub uzyskania dostępu do roota na urządzeniu. Jednak w większości wersji Androida, które są wciąż w użyciu, obecny zestaw zaufanych certyfikatów głównych prawdopodobnie zapewni nieprzerwaną obsługę przez wiele lat, wykraczając poza efektywny okres użytkowania większości obecnie używanych urządzeń.

Od wersji 7.0 Android zapewnia deweloperom aplikacji bezpieczną metodę dodawania zaufanych certyfikatów, które są zaufane tylko dla ich aplikacji. W tym celu należy połączyć certyfikaty z aplikacją i utworzyć niestandardową konfigurację zabezpieczeń sieci zgodnie z opisem w dokumencie szkoleniowym na temat sprawdzonych metod zapewniania bezpieczeństwa i prywatności na Androidzie konfiguracji zabezpieczeń sieciowych.

Deweloperzy aplikacji innych firm nie będą jednak mogli wpływać na konfigurację zabezpieczeń sieci ruchu pochodzącego z pliku APK Usług Google Play, więc takie działania prawdopodobnie stanowią tylko częściowe obejście problemu.

W przypadku starszych starszych urządzeń jedyną dostępną opcją jest korzystanie z urzędów certyfikacji dodanych przez użytkowników, które są zainstalowane przy użyciu firmowych zasad grupy stosowanych na urządzeniach użytkowników lub przez użytkowników.

iOS Trust Store

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

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

W tabeli poniżej znajdziesz informacje o dostępności najważniejszych certyfikatów głównych w poszczególnych wersjach iOS, na podstawie podanych wyżej źródeł:

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

Gdzie są moje systemowe certyfikaty główne i jak mogę je aktualizować?

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

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

Inne ścieżki certyfikatów mogą obejmować:

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

Niektóre certyfikaty w tych katalogach są prawdopodobnie symbolowymi dowiązaniami 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ślny magazyn certyfikatów głównych, korzystając z tego polecenia:

openssl version -d

Polecenie wyświetla tekst OPENSSLDIR, który odpowiada katalogowi najwyższego poziomu, w którym znajduje się biblioteka, a jej konfiguracja jest dostępna:

OPENSSLDIR: "/usr/lib/ssl"

Magazyn certyfikatów głównych znajduje się w podkatalogu certs.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

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

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

Magazyn certyfikatów głównych Java

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

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

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

Po prostu zastąp cert.pem plikiem certyfikatu odpowiadającym każdemu rekomendowanemu certyfikatowi głównemu, alias unikalnym, ale zrozumiałym aliasem certyfikatu, a certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku.

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

Magazyn certyfikatów głównych Mozilla NSS

Aplikacje korzystające z Mozilla NSS mogą też domyślnie korzystać z systemowej bazy danych certyfikatów, która zwykle znajduje się w katalogu /etc/pki/nssdb lub z indywidualnego magazynu domyślnego w ${HOME}/.pki/nssdb.

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

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

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

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

Więcej informacji znajdziesz w oficjalnej instrukcji obsługi NSS Tools certutil, a także w dokumentacji systemu operacyjnego.

Magazyn certyfikatów głównych Microsoft .NET

Dla deweloperów oprogramowania w systemie Windows .NET przydatne do aktualizowania magazynu certyfikatów głównych mogą być poniższe artykuły firmy Microsoft:

Formaty plików certyfikatów

Co to jest plik PEM?

Poczta z rozszerzoną ochroną prywatności to standardowy format pliku tekstowego służącego do przechowywania i wysyłania certyfikatów kryptograficznych, kluczy itp., sformalizowanego jako standard odpornościowy w RFC 7468.

Sam format pliku jest czytelny dla człowieka, ale dane certyfikatów binarnych zakodowanych w formacie Base64 już nie. Specyfikacja PEM pozwala jednak na umieszczenie tekstu objaśniającego przed lub za treścią certyfikatu zakodowanego w formie tekstowej. Wiele narzędzi korzysta z tej funkcji, aby wyświetlać również podsumowanie w formie zwykłego tekstu o najważniejszych elementach danych zawartych w certyfikacie.

Za pomocą narzędzi takich jak openssl można też dekodować cały certyfikat do postaci czytelnej dla człowieka. Więcej informacji znajdziesz w sekcji Jak drukować certyfikaty PEM w postaci czytelnej dla człowieka.

Co to jest plik „.crt”?

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

Co to jest plik DER?

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

Co to jest plik „.cer”?

Wyeksportowany plik z sufiksem „.cer” może zawierać certyfikat zakodowany w formacie PEM, ale zwykle jest to plik binarny, zazwyczaj z certyfikatem zakodowanym w formacie DER. Według konwencji pliki „.cer” zawierają zwykle tylko jeden certyfikat.

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

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

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

roots.pem możesz podzielić na certyfikaty komponentu, korzystając z tego prostego skryptu bash:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Powinno to spowodować utworzenie kilku plików PEM podobnych do 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

Za pomocą narzędzia wiersza poleceń openssl w pakiecie narzędzi OpenSSL można konwertować pliki ze wszystkimi powszechnie używanymi formatami plików certyfikatów. Poniżej znajdziesz instrukcje konwertowania pliku PEM na najczęściej używane formaty plików certyfikatów.

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

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

Jak przekonwertować plik PEM na format DER?

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

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

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

Za pomocą openssl możesz 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 do pliku. Pamiętaj, by przechowywać hasło w bezpiecznym miejscu. Jeśli nie zaimportujesz pliku PKCS #12 od razu do systemu.

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 uruchomić to polecenie, aby wyświetlić listę wszystkich certyfikatów w magazynie certyfikatów wraz z aliasami, których możesz użyć do ich wyeksportowania:

keytool -v -list -keystore certs.jks

Po prostu zastąp certs.jks plikiem bazy danych certyfikatów używanym w Twoim środowisku. Polecenie to pokazuje też alias każdego certyfikatu, który będzie potrzebny do wyeksportowania go.

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

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

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

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

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

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

certutil -L -d certdir

Po prostu zastąp certdir ścieżką bazy danych certyfikatów używaną w Twoim środowisku. Polecenie to pokazuje też pseudonim każdego certyfikatu, który będzie Ci potrzebny do wyeksportowania.

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

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

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

Więcej informacji znajdziesz w oficjalnej instrukcji obsługi NSS Tools certutil, a także w dokumentacji systemu operacyjnego.

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

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

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

Wydaję polecenie

openssl x509 -in GTS_Root_R1.pem -text

powinien wyświetlić wynik podobny do tego:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

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

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

Uruchamiam to polecenie

keytool -printcert -file GTS_Root_R1.pem

powinien wyświetlić wynik podobny do tego:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Instrukcje dotyczące uzyskiwania keytool znajdują się w sekcji Pobieranie klucza Java keytool.

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

Zależy to od systemu operacyjnego i biblioteki SSL/TLS. Narzędzia umożliwiające importowanie i eksportowanie certyfikatów do i z magazynu certyfikatów głównych zazwyczaj udostępniają też opcję wyświetlania listy zainstalowanych certyfikatów.

Jeśli udało Ci się wyeksportować zaufane certyfikaty główne do plików PEM lub Twój magazyn certyfikatów głównych zawiera już zapisane pliki PEM, możesz spróbować je otworzyć w dowolnym edytorze tekstu, ponieważ ma on format zwykłego tekstu.

Plik PEM może być odpowiednio oznaczony etykietami i zawierać czytelne dla człowieka informacje o powiązanym urzędzie certyfikacji (przykład z zaufanego pakietu głównego urzędów certyfikacji Google):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

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

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

Przeglądarki mogą korzystać z własnego magazynu certyfikatów głównych lub od domyślnego magazynu certyfikatów udostępnianych przez system operacyjny. Jednak wszystkie nowoczesne przeglądarki powinny umożliwiać zarządzanie lub przynajmniej wyświetlanie zestawu głównych urzędów certyfikacji, którym ufają. Więcej informacji znajdziesz w pytaniu Czy aplikacje JavaScript mogą przestać działać?.

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

Dodatek

Potrzebujesz więcej informacji?

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

Wszystkie inne źródła informacji, w tym te najczęstsze pytania, mogą być nieaktualne lub nieprawidłowe z innego powodu, i nie powinny być traktowane jako wiarygodne. Przydatne informacje mogą być jednak nadal dostępne w wielu społecznościach pytań i odpowiedzi w Stack Exchange oraz w witrynach takich jak AdamW w Linuksie i innych oraz na blogu potwierdzenia.

Przeczytaj też najczęstsze pytania dotyczące Google Trust Services.

Więcej informacji o zaawansowanych tematach, takich jak przypinanie certyfikatów, znajdziesz w artykułach na temat przypinania certyfikatów i kluczy publicznych (Open Web Application Security Project, OWASP) oraz ściągawki z przypinania. Instrukcje dotyczące urządzeń z Androidem znajdziesz w oficjalnym dokumencie szkoleniowym na temat sprawdzonych metod dotyczących bezpieczeństwa i prywatności w Androidzie Ochrona za pomocą protokołów HTTPS i SSL. Aby dowiedzieć się więcej na temat przypinania certyfikatów i kluczy publicznych na urządzeniach z Androidem, przydatne mogą być informacje w poście na blogu Matthew Dolana poświęconym zabezpieczeniom w Androidzie: przypinanie SSL.

Materiały szkoleniowe Sprawdzone metody ochrony prywatności i zabezpieczeń na Androidzie Konfiguracja zabezpieczeń sieci oraz post na blogu JeroenHD Android 7 Nougat i urzędy certyfikacji na temat zarządzania zaufanymi certyfikatami zawierają dodatkowe informacje na temat zarządzania zaufanymi certyfikatami Androida.

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