Google poinformował klientów Google Cloud o planowanych zmianach w infrastrukturze TLS, które będą wdrażane w Q2 2026. Zmiana dotyczy wielu endpointów Google, w tym usług opartych o googleapis.com, i obejmuje przejście z klasycznych łańcuchów RSA na certyfikaty ECDSA oraz nowe intermediate CA Google Trust Services. Dla większości użytkowników zmiana będzie całkowicie transparentna. Jednak organizacje korzystające z własnych trust store’ów, certificate pinning lub starszych środowisk mogą po wdrożeniu napotkać realne problemy z połączeniami TLS.
To kolejny sygnał, że współczesne środowiska PKI stają się coraz bardziej dynamiczne – a infrastruktura, która nie jest przygotowana na regularne zmiany certyfikatów i CA, zaczyna stanowić ryzyko operacyjne.
Spis Treści
Co dokładnie zmienia Google?
Google zapowiedział migrację części usług do nowego modelu opartego o:
- intermediate CA Google Trust Services WE1,
- certyfikaty ECDSA zamiast klasycznych RSA,
- nowy łańcuch certyfikacji w wybranych usługach TLS.
Zmiany będą wdrażane stopniowo w drugiej połowie Q2 2026. W praktyce oznacza to, że aplikacje komunikujące się z usługami Google mogą zacząć otrzymywać inne łańcuchy certyfikatów niż dotychczas – mimo że same domeny i usługi pozostaną bez zmian.
RSA vs ECDSA – dlaczego rynek zmienia kierunek?
Przejście na ECDSA nie jest przypadkowe. Cały rynek TLS od kilku lat stopniowo odchodzi od wyłącznego wykorzystania RSA. ECDSA oferuje między innymi:
- mniejsze klucze kryptograficzne,
- szybsze handshake TLS,
- niższe zużycie CPU,
- lepszą wydajność przy dużej liczbie połączeń,
- nowocześniejszy model kryptograficzny.
Dla dużych dostawców cloud i CDN, takich jak Google, Cloudflare czy Amazon Web Services, ma to bezpośrednie przełożenie na wydajność globalnej infrastruktury. Problem polega jednak na tym, że część aplikacji enterprise nadal zakłada, że:
- certyfikat będzie oparty o RSA,
- intermediate CA pozostanie niezmienny przez wiele lat,
- łańcuch certyfikacji będzie statyczny.
W nowoczesnym ekosystemie PKI takie założenia przestają być bezpieczne.
Największe ryzyko: certificate pinning.
Google wprost wskazuje, że jedną z głównych przyczyn potencjalnych problemów będzie certificate pinning. Szczególnie niebezpieczne jest:
- pinning intermediate CA,
- pinning konkretnych leaf certificates,
- sztywne przypisanie pojedynczego łańcucha certyfikacji.
W teorii pinning miał zwiększać bezpieczeństwo aplikacji. W praktyce bardzo często prowadzi dziś do awarii podczas rutynowych rotacji certyfikatów. To ważna zmiana podejścia w całej branży. Jeszcze kilka lat temu wiele organizacji wdrażało pinning jako „best practice”. Obecnie duzi dostawcy infrastruktury coraz częściej odradzają takie podejście właśnie ze względu na problemy operacyjne i brak odporności na zmiany PKI. W środowiskach cloud certyfikaty, intermediate CA i algorytmy kryptograficzne mogą zmieniać się regularnie – a aplikacje muszą być na to przygotowane.
Custom trust stores nadal są dużym problemem.
Drugim obszarem ryzyka są własne trust store’y. Dotyczy to szczególnie:
- starszych aplikacji Java,
- urządzeń embedded i IoT,
- appliance’y bezpieczeństwa,
- środowisk offline,
- kontenerów ze starymi CA bundle,
- własnych trust store’ów utrzymywanych ręcznie,
- rozwiązań enterprise z ograniczonym zestawem trusted roots.
Google zaznacza, że organizacje powinny upewnić się, że wszystkie Google Trust Services Root CA znajdują się w ich trust store. Brak aktualnych root CA może spowodować:
- błędy TLS,
- odrzucanie połączeń HTTPS,
- problemy z API,
- awarie integracji,
- niedostępność usług produkcyjnych.
W praktyce wiele organizacji dowiaduje się o problemie dopiero po wystąpieniu outage’u.
To część większej transformacji rynku PKI.
Zmiana ogłoszona przez Google wpisuje się w szerszy trend transformacji infrastruktury zaufania w internecie. W ostatnich latach obserwujemy:
- coraz częstsze rotacje intermediate CA,
- rozwój własnych root programów,
- migracje do nowoczesnych algorytmów kryptograficznych,
- skracanie okresów ważności certyfikatów,
- większy nacisk na automatyzację lifecycle management,
- odchodzenie od ręcznego zarządzania certyfikatami.
Podobne zmiany widać również u DigiCert, w programach zaufania przeglądarek oraz w wymaganiach dotyczących zarządzania certyfikatami TLS. Środowiska, które nadal opierają się na ręcznie utrzymywanych konfiguracjach, statycznych trust store’ach i braku automatyzacji, będą coraz bardziej podatne na problemy operacyjne.
Co organizacje powinny zrobić już teraz?
Przed wdrożeniem zmian warto:
- przeanalizować aplikacje wykorzystujące certificate pinning,
- sprawdzić kompatybilność środowisk z certyfikatami ECDSA,
- zweryfikować własne trust store’y,
- zaktualizować CA bundle w systemach i kontenerach,
- sprawdzić urządzenia TLS inspection i proxy,
- przeprowadzić testy integracji z usługami Google,
- wdrożyć monitoring certyfikatów i zmian TLS,
- ograniczyć ręczne zarządzanie certyfikatami.
W praktyce organizacje powinny zakładać, że infrastruktura PKI będzie zmieniać się regularnie – a nie pozostawać statyczna przez lata.
Problemem nie jest zmiana certyfikatu.
Najważniejszy wniosek z komunikatu Google jest jednak szerszy. Problemem nie jest sama migracja do ECDSA. Problemem są środowiska, które zakładają, że:
- certyfikaty nigdy się nie zmieniają,
- intermediate CA pozostają stałe,
- infrastruktura TLS jest statyczna,
- ręczne zarządzanie trust store będzie wystarczające.
Współczesny ekosystem PKI coraz mocniej wymusza automatyzację, monitoring i odporność operacyjną na zmiany certyfikatów. Organizacje, które nie przygotują się na tę rzeczywistość, będą coraz częściej doświadczać problemów nie z powodu ataków – lecz przez własne ograniczenia operacyjne.
Źródła i dokumentacja: