15 kwietnia 2026 to istotna data dla organizacji, które nadal korzystają z części starszych hierarchii DigiCert. Tego dnia Mozilla i Google Chrome usuwają rooty DigiCert G1 z magazynów zaufania, co oznacza, że certyfikaty TLS łańcuchujące się wyłącznie do tych korzeni przestaną być zaufane w środowiskach opartych o te programy zaufania. Z perspektywy wielu organizacji nie jest to zmiana spektakularna, bo zdecydowana większość wdrożeń została już wcześniej przeniesiona do nowszych hierarchii G2 i G3. Dla części środowisk, szczególnie tych z komponentami legacy, własnymi trust store, pinningiem lub niestandardową logiką walidacji, może to jednak oznaczać realne ryzyko przerw w dostępności usług, błędów walidacji i nieoczekiwanych incydentów po stronie klientów, aplikacji oraz urządzeń.

W praktyce nie chodzi więc tylko o samą zmianę po stronie przeglądarek. Chodzi o szerszy trend porządkowania publicznego WebPKI, w którym starsze hierarchie root i intermediate są stopniowo wygaszane, a zaufanie przesuwa się w stronę nowszych, bardziej uporządkowanych i zgodnych z aktualnymi wymaganiami modeli issuance. DigiCert rozpoczął przejście na domyślne issuance z hierarchii G2 już 8 marca 2023 roku właśnie po to, aby ograniczyć wpływ późniejszego wycofania G1. To oznacza, że problem nie dotyczy każdego certyfikatu DigiCert, GeoTrust, RapidSSL czy Thawte, lecz tylko tej części aktywnych wdrożeń, które nadal pozostają w starszej ścieżce łańcuchowania.

Co dokładnie zostaje wycofane?

Najważniejszy komunikat jest prosty: od 15 kwietnia 2026 Mozilla i Google Chrome przestają ufać rootom DigiCert G1 używanym dla publicznego TLS. W materiałach DigiCert wskazane są w szczególności trzy główne korzenie tej generacji: DigiCert Assured ID Root CA, DigiCert Global Root CA oraz DigiCert High Assurance EV Root CA. Dla aktywnych certyfikatów TLS oznacza to utratę zaufania po tej dacie, jeśli ich ścieżka zaufania kończy się wyłącznie w tych rootach.

To bardzo ważne rozróżnienie. Sam fakt, że certyfikat został wystawiony przez markę należącą do DigiCert, nie oznacza jeszcze problemu. DigiCert od dawna wystawia publiczne certyfikaty z nowszych hierarchii G2, a część produktów wykorzystuje także nowsze ścieżki G3. Cloudflare, opisując tę zmianę z punktu widzenia własnych klientów, podkreśla, że podstawowym obszarem ryzyka są certyfikaty custom, które nadal łańcuchują się do legacy G1. Certyfikaty kończące się w G2 pozostają zaufane i nie są objęte tym konkretnym wycofaniem.

Dlaczego ta zmiana ma znaczenie właśnie teraz?

W wielu organizacjach temat rootów i intermediate’ów wraca dopiero wtedy, gdy coś przestaje działać. To błąd. Łańcuch zaufania jest elementem infrastruktury krytycznej, ale jednocześnie często pozostaje poza codziennym monitoringiem. W praktyce oznacza to, że organizacja może mieć poprawnie zainstalowany certyfikat końcowy, aktualną datę ważności i mimo to wejść w problem po stronie klientów, bo ścieżka walidacji kończy się w korzeniu, który właśnie wypadł z trust store.

Ryzyko jest szczególnie wysokie tam, gdzie występują środowiska mieszane: nowoczesne przeglądarki po jednej stronie, a po drugiej starsze aplikacje, urządzenia, biblioteki kryptograficzne, appliance’y sieciowe, integracje B2B, klienci pocztowi, serwery aplikacyjne lub własne agentowe komponenty, które nie korzystają z identycznego modelu walidacji. Część takich systemów działa poprawnie przez lata i dlatego ich właściciele zakładają, że nic nie wymaga zmian. Tymczasem to właśnie w tych środowiskach najczęściej dochodzi do hard-coded trust, certificate pinning albo zależności od dawnych łańcuchów cross-signed. DigiCert wprost wskazuje, że dodatkowej uwagi wymagają środowiska, które pinują lub hard-code’ują akceptację rootów i intermediate’ów albo utrzymują własne magazyny zaufania.

Kogo ta zmiana może dotknąć najbardziej?

Najmniej zagrożone są typowe wdrożenia webowe, które były odnawiane w ostatnich latach zgodnie ze standardowym procesem i nie opierały się na niestandardowych wyjątkach. Jeżeli certyfikat był odnawiany lub reissue’owany w normalnym cyklu po przejściu DigiCert na G2, duża część takich środowisk już dziś pracuje na wspieranych hierarchiach. DigiCert podaje, że większość klientów została już przeniesiona i nie musi wykonywać dodatkowych działań.

Znacznie większą ostrożność powinny zachować organizacje, które spełniają przynajmniej jeden z poniższych warunków:

• posiadają aktywne certyfikaty TLS wydane z hierarchii G1,
• wymagają zaufania w środowiskach opartych o Chrome lub Mozilla Firefox,
• utrzymują niestandardowe trust store albo własne paczki CA,
• pinują rooty lub intermediate’y,
• korzystają ze starszych urządzeń, agentów, bibliotek lub serwerów, które były przygotowywane pod dawną ścieżkę certyfikacji,
• wdrażają certyfikaty poza klasycznym webem, na przykład w appliance’ach, integracjach B2B, urządzeniach, usługach pośredniczących lub komponentach, które nie są często aktualizowane.

Szczególny przypadek stanowią też środowiska, w których historycznie stosowano obejścia kompatybilnościowe, na przykład cross-signing pozwalający zachować zaufanie w starszych trust store. To rozwiązania, które często działały poprawnie w okresie przejściowym, ale nie powinny być traktowane jako docelowa strategia długoterminowa. DigiCert już w 2023 roku zaznaczał, że cross-signed root miał charakter pomostowy, a pełne utrzymanie zaufania po dacie distrust wymaga przejścia do nowszej hierarchii.

Jakie mogą być skutki operacyjne po 15 kwietnia 2026?

Najbardziej oczywistym skutkiem będą komunikaty o niezaufanym certyfikacie w przeglądarkach i aplikacjach korzystających z trust store opartych o programy Chrome i Mozilla. Dla użytkownika końcowego oznacza to ostrzeżenie bezpieczeństwa, dla organizacji oznacza to spadek wiarygodności, przerwanie ścieżki logowania, blokadę dostępu do paneli, formularzy, API lub procesów zakupowych.

W praktyce skutki mogą jednak być szersze niż sam browser warning. Jeżeli certyfikat wykorzystywany jest w integracjach maszynowych, reverse proxy, load balancerach, usługach wspólnych, agentach telemetrycznych lub pośrednich warstwach bezpieczeństwa, to problem może ujawnić się jako błąd połączenia TLS, niemożność zestawienia sesji, odrzucenie zaufania przez klienta, brak możliwości odnowienia komunikacji lub niejasne błędy aplikacyjne. Część z tych problemów nie będzie od razu identyfikowana jako kwestia root CA, bo w logach pojawi się jedynie ogólna informacja o błędzie walidacji certyfikatu. To właśnie dlatego temat wymaga wcześniejszej inwentaryzacji, a nie reakcji dopiero po wystąpieniu incydentu.

Jak sprawdzić, czy organizacja jest narażona?

Pierwszym krokiem nie powinno być od razu zamawianie nowych certyfikatów, tylko ustalenie, gdzie w ogóle występują aktywne łańcuchy G1. To zadanie z obszaru certificate inventory, a nie pojedynczego support case.

W praktyce warto podejść do tego w czterech warstwach.

1. Inwentaryzacja aktywnych certyfikatów publicznych.

Trzeba zebrać nie tylko domeny publiczne, ale również certyfikaty używane w portalach administracyjnych, interfejsach B2B, usługach integracyjnych, urządzeniach brzegowych, WAF-ach, appliance’ach, VPN-ach, gatewayach pocztowych i wszędzie tam, gdzie publiczny certyfikat jest wykorzystywany poza klasycznym serwisem WWW. Najwięcej problemów zwykle znajduje się właśnie w tych mniej widocznych punktach.

2. Identyfikacja ścieżki łańcuchowania.

Dla każdego aktywnego wdrożenia trzeba ustalić, do jakiego intermediate i root realnie prowadzi ścieżka zaufania. Sam certyfikat końcowy nie wystarczy. To, że marka handlowa certyfikatu to RapidSSL, GeoTrust czy Thawte, nie przesądza jeszcze o tym, czy mamy do czynienia z G1 czy z nowszą hierarchią. DigiCert publikuje mapowanie dawnych G1 intermediate’ów i ich następców w G2, co ułatwia takie porównanie. Na przykład dla RapidSSL przejście dotyczyło ścieżki z RapidSSL Global TLS RSA4096 SHA256 2022 CA1 pod DigiCert Global Root CA do RapidSSL TLS RSA CA G1 pod DigiCert Global Root G2. Podobne mapowania istnieją dla GeoTrust, Thawte i produktów DigiCert.

3. Weryfikacja zależności po stronie klientów i urządzeń.

Nawet jeżeli serwer po reissue będzie wysyłał poprawny chain, problem może pozostać po stronie klientów, agentów lub urządzeń, które oczekują starego rootu, pinują określoną ścieżkę albo korzystają z własnego bundle CA. To właśnie ten obszar często decyduje o tym, czy migracja będzie trywialna, czy zamieni się w serię incydentów rozproszonych po różnych zespołach.

4. Przegląd wyjątków historycznych.

Warto zidentyfikować, czy w przeszłości wprowadzano obejścia kompatybilnościowe związane z cross-signed root, niestandardowym chain file, ręcznie budowanym bundle lub wyjątkami w appliance’ach. Takie decyzje często nie są dobrze udokumentowane, ale wracają właśnie przy tego typu zmianach.

Jakie działania zaleca DigiCert?

Podstawowa rekomendacja DigiCert jest jednoznaczna: dotknięte certyfikaty należy odnowić lub reissue’ować do hierarchii G2 lub G3 przed datą wycofania, tak aby uniknąć ostrzeżeń „untrusted” po 15 kwietnia 2026. Jednocześnie DigiCert podkreśla, że większość standardowych renewali automatycznie przenosi już certyfikaty do wspieranych hierarchii, a wystawianie nowych certyfikatów w G1 nie jest już standardową ścieżką.

Warto zwrócić uwagę na jeszcze jeden istotny aspekt. Cloudflare zwraca uwagę, że w przypadku affected certificates standardowy reissue do G2 jest zwykle wystarczający i w większości przypadków nie wymaga generowania nowego klucza prywatnego. To ważne operacyjnie, ponieważ część zespołów obawia się, że taka migracja będzie równoznaczna z pełną przebudową wdrożenia. W wielu scenariuszach nie jest. Najpierw trzeba jednak potwierdzić politykę konkretnego produktu, procesu issuance oraz własne wymagania bezpieczeństwa dotyczące rotacji klucza.

Czego nie należy zakładać?

Największym błędem byłoby założenie, że temat rozwiąże się sam, bo „przecież certyfikat jeszcze nie wygasł”. Tu problemem nie jest sama data expiry certyfikatu końcowego, lecz data utraty zaufania dla rootu, do którego ten certyfikat się łańcuchuje. Można więc mieć certyfikat formalnie ważny, a mimo to niezaufany w praktyce. DigiCert wprost zaznacza, że po dacie 15 kwietnia 2026 aktywne certyfikaty TLS łańcuchujące się do G1 utracą zaufanie w Chrome i Mozilla.

Drugim błędem jest zakładanie, że skoro główna strona firmowa działa, to temat został zamknięty. W rzeczywistości najbardziej problematyczne bywają systemy poboczne: starsze subdomeny administracyjne, urządzenia, panele serwisowe, integracje partnerów, środowiska testowe z dostępem zewnętrznym oraz usługi, które rzadko pojawiają się w standardowych przeglądach bezpieczeństwa.

Trzecim błędem jest traktowanie cross-signingu jako docelowego rozwiązania strategicznego. Tego typu mechanizmy były przydatne jako pomost kompatybilnościowy, ale długofalowo rynek wyraźnie zmierza w stronę uproszczenia, wygaszania starych hierarchii i większej przewidywalności ścieżek zaufania.

Dlaczego ten temat wpisuje się w szerszy kierunek zmian w WebPKI?

Wycofanie DigiCert G1 nie jest oderwanym incydentem. To kolejny element większego procesu porządkowania publicznego PKI. W 2026 branża równolegle wdraża krótszą maksymalną ważność certyfikatów TLS, ostrzejsze zasady walidacji, MPIC oraz dalsze ograniczenia dotyczące użycia publicznego WebPKI do innych zastosowań niż klasyczne server authentication. DigiCert i Chrome Root Program sygnalizują też kolejne działania dotyczące uproszczenia hierarchii i eliminacji struktur wielofunkcyjnych na rzecz bardziej jednoznacznych, dedykowanych ścieżek TLS.

Dla właścicieli infrastruktury oznacza to jedną rzecz: certyfikat przestaje być jednorazowym zakupem, a staje się elementem procesu ciągłego zarządzania. Trzeba wiedzieć, kto jest właścicielem certyfikatu, gdzie jest wdrożony, jaki ma chain, jaki ma sposób odnowienia, kto odpowiada za walidację domeny, jak działa monitoring i czy środowisko potrafi bezpiecznie przejść na nową hierarchię bez ręcznych wyjątków.

Rekomendowany plan działania dla organizacji.

Najrozsądniejszym podejściem nie jest paniczna wymiana wszystkiego, tylko uporządkowany przegląd wpływu i kontrolowana migracja.

Najpierw warto stworzyć listę wszystkich publicznych certyfikatów i przypisać im właścicieli biznesowych oraz technicznych. Następnie trzeba ustalić, które z nich rzeczywiście kończą się w G1 i które systemy klienckie zależą od historycznej ścieżki zaufania. Kolejny etap to reissue lub renewal do G2 albo G3 tam, gdzie jest to wymagane, a potem testy kompatybilności po stronie klientów, urządzeń i integracji. Na końcu powinien pojawić się monitoring, który nie sprawdza wyłącznie daty ważności, ale także zmiany chainu, intermediate’a i ryzyka operacyjnego przy kolejnych migracjach.

Z biznesowego punktu widzenia to dobry moment, by potraktować temat szerzej niż tylko „zamówienie nowego certyfikatu”. Organizacje, które uporządkują dziś inventory, monitoring i proces odnowień, będą znacznie lepiej przygotowane nie tylko na wycofanie DigiCert G1, ale też na kolejne etapy zmian w WebPKI, w tym dalsze skracanie cyklu życia certyfikatów i zaostrzanie zasad issuance.

Wnioski.

Zmiana obowiązująca od 15 kwietnia 2026 nie oznacza powszechnego kryzysu dla wszystkich klientów DigiCert. Oznacza jednak bardzo konkretny punkt ryzyka dla tych organizacji, które nadal korzystają z aktywnych certyfikatów łańcuchujących się do rootów G1 albo utrzymują środowiska zależne od dawnych modeli zaufania. W takich przypadkach problem nie będzie teoretyczny. Będzie oznaczał utratę zaufania w przeglądarkach i potencjalne błędy w usługach opartych na TLS.

Najważniejsze jest więc nie to, by zapamiętać samą datę, ale by odpowiedzieć sobie na trzy pytania: czy wiemy, gdzie w organizacji nadal występują łańcuchy G1, czy rozumiemy zależności po stronie klientów i urządzeń oraz czy mamy proces, który pozwala bezpiecznie przenieść takie wdrożenia do wspieranej hierarchii bez chaosu i przestojów. Organizacje, które zrobią to teraz, potraktują 15 kwietnia 2026 jako rutynową zmianę operacyjną. Te, które zignorują temat, mogą odkryć problem dopiero wtedy, gdy użytkownik zobaczy komunikat o niezaufanym certyfikacie.

Źródło:
– https://knowledge.digicert.com/alerts/digicert-tls-root-strategy-aligning-with-industry-standards
– https://www.digicert.com/blog/tls-certificate-rule-changes
– https://knowledge.digicert.com/general-information/digicert-root-and-intermediate-ca-certificate-updates-2023
– https://developers.cloudflare.com/ssl/reference/migration-guides/digicert-g1-distrust/