W 2025 roku Sectigo rozpoczął jeden z najważniejszych procesów infrastrukturalnych w swoim ekosystemie PKI – migrację wydawania certyfikatów do nowych, własnych Public Root Certification Authorities. Zmiana ta dotyczy wszystkich głównych linii produktowych, w tym certyfikatów SSL/TLS (DV, OV, EV) oraz S/MIME, i ma bezpośredni wpływ na sposób budowania łańcucha zaufania w przeglądarkach, systemach operacyjnych i środowiskach serwerowych.

Choć z perspektywy większości użytkowników końcowych migracja będzie w dużej mierze niewidoczna, z punktu widzenia administratorów, zespołów DevOps, architektów bezpieczeństwa oraz dostawców usług hostingowych jest to zmiana, którą należy świadomie uwzględnić w planowaniu kompatybilności i ciągłości usług.

Kontekst: dlaczego root CA ma znaczenie operacyjne?

Public Root CA to najwyższy punkt zaufania w modelu PKI. Każda przeglądarka i system operacyjny utrzymuje własny root trust store, który determinuje, czy dany certyfikat zostanie uznany za wiarygodny. Zmiana root CA nie jest więc kosmetyczna – wpływa bezpośrednio na:

• proces walidacji certyfikatu po stronie klienta,
• kompatybilność z urządzeniami legacy,
• zachowanie aplikacji korzystających z własnych bibliotek TLS,
• stabilność integracji w środowiskach zamkniętych (IoT, embedded, OT).

Migracja Sectigo wpisuje się w szerszy trend porządkowania i upraszczania hierarchii CA, zgodnie z aktualnymi wymaganiami programów zaufania (Mozilla, Apple, Microsoft, Google) oraz rekomendacjami CA/B Forum.

Co dokładnie zmienia Sectigo?

Do tej pory Sectigo wykorzystywało historyczne, szeroko rozpowszechnione rooty (m.in. USERTrust), często w połączeniu z rozbudowanym cross-signingiem. Nowa strategia zakłada:

• przejście na nowe, dedykowane Sectigo Public Root CAs,
• pełną obecność tych rootów w głównych trust store’ach,
• uproszczenie ścieżek certyfikacji,
• ograniczenie długoterminowej zależności od starszych, „legacy” rootów.

W praktyce oznacza to bardziej przewidywalne i kontrolowane środowisko zaufania, ale jednocześnie wymusza weryfikację kompatybilności po stronie odbiorców certyfikatów.

Harmonogram migracji – kluczowe daty.

Sectigo wdraża zmiany etapami, w zależności od typu certyfikatu:

• S/MIME – od 1 marca 2025.
• EV TLS – od 15 kwietnia 2025.
• OV TLS – od 15 maja 2025.
• DV TLS – od 2 czerwca 2025.

Po tych datach nowo wydawane certyfikaty będą domyślnie opierały się o nowe rooty. Istniejące certyfikaty zachowują ważność do końca okresu ich obowiązywania.

Wpływ migracji na środowiska produkcyjne.

W nowoczesnych systemach (aktualne wersje Windows, macOS, Linux, Android, iOS oraz współczesne przeglądarki) zmiana jest w większości przypadków transparentna. Problemy mogą pojawić się natomiast w środowiskach, które:

• korzystają z ręcznie zarządzanych trust store’ów,
• implementują certificate pinning na poziomie root lub intermediate,
• używają starszych obrazów systemowych, kontenerów lub appliance’ów,
• opierają się na bibliotekach TLS, które nie synchronizują się automatycznie z systemowym store’em.

W takich przypadkach migracja root CA może ujawnić się w postaci błędów TLS, problemów z walidacją certyfikatu lub zerwanych połączeń API.

Cross-signing jako mechanizm przejściowy.

Aby ograniczyć ryzyko niekompatybilności, Sectigo stosuje cross-signing nowych rootów przez starsze, powszechnie rozpoznawane CA. Mechanizm ten pozwala na akceptację certyfikatu zarówno przez nowe, jak i starsze środowiska.

Warto jednak traktować cross-signing jako rozwiązanie tymczasowe, a nie długofalową strategię. Docelowo organizacje powinny dążyć do aktualizacji systemów i uproszczenia łańcucha zaufania.

Znaczenie migracji w szerszym kontekście PKI.

Zmiany wprowadzone przez Sectigo są spójne z kierunkiem rozwoju całego ekosystemu PKI:

• skracanie i upraszczanie łańcuchów certyfikacji,
• eliminacja historycznych kompromisów kompatybilnościowych,
• przygotowanie pod przyszłe zmiany w TLS, w tym m.in. post-quantum readiness,
• rosnące znaczenie automatyzacji i poprawnej obsługi trust store’ów.

Dla organizacji zarządzających większą liczbą certyfikatów jest to dobry moment, aby przeanalizować własne procesy związane z instalacją, monitorowaniem i odnawianiem certyfikatów.

FAQ – najczęściej zadawane pytania dotyczące migracji Sectigo Root CA.

Czy muszę wymieniać już zainstalowane certyfikaty?

Nie. Certyfikaty wydane przed datami migracji pozostają ważne do momentu ich wygaśnięcia. Migracja dotyczy wyłącznie nowo wydawanych certyfikatów oraz ponownych wydań.

Czy migracja wpłynie na SEO lub ranking w Google?

Nie bezpośrednio. O ile certyfikat jest poprawnie zainstalowany, a przeglądarka ufa nowemu root CA, migracja nie ma wpływu na SEO. Problemy mogą pojawić się jedynie w przypadku błędnej konfiguracji TLS skutkującej ostrzeżeniami bezpieczeństwa.

Czy starsze urządzenia mogą przestać ufać certyfikatom Sectigo?

Tak, w skrajnych przypadkach. Dotyczy to głównie bardzo starych systemów, urządzeń embedded oraz aplikacji z własnym, nieaktualizowanym trust store’em. W takich środowiskach konieczna może być aktualizacja lub ręczne zarządzanie łańcuchem certyfikacji.

Czy certificate pinning może powodować problemy?

Tak. Pinowanie na poziomie root lub konkretnego intermediate CA może doprowadzić do błędów po migracji. Sectigo jednoznacznie odradza takie podejście i rekomenduje oparcie się na standardowej walidacji PKI.

Co z certyfikatami multi-year?

W przypadku subskrypcji wieloletnich certyfikaty będą ponownie wydawane zgodnie z nową hierarchią root CA po osiągnięciu dat migracyjnych.

Czy muszę coś zmieniać na serwerze?

W większości przypadków nie. Warto jednak zweryfikować, czy serwer dostarcza pełny i poprawny łańcuch certyfikacji oraz czy nie używa ręcznie zdefiniowanych, przestarzałych plików CA bundle.

Jak przełożyć migrację Sectigo Root CA na realne działania z HEXSSL?

Migracja Sectigo Public Root CAs to dobry moment, aby nie tylko „upewnić się, że certyfikat działa”, lecz zweryfikować całe środowisko TLS w sposób systemowy. W praktyce oznacza to połączenie analizy, monitoringu oraz automatycznej diagnostyki. Właśnie w tym obszarze HEXSSL pełni rolę warstwy kontrolnej pomiędzy urzędem certyfikacji a środowiskiem produkcyjnym.

Sprawdź realny łańcuch certyfikacji swojej domeny.

Pierwszym krokiem powinno być sprawdzenie, jaki łańcuch certyfikatów faktycznie dostarcza serwer po stronie klienta TLS, a nie tylko jaki certyfikat został zainstalowany.

➡ Skorzystaj z narzędzia SSL Checker, aby:

• zobaczyć pełny łańcuch certyfikacji (leaf, intermediate, root),
• sprawdzić, czy domena korzysta już z nowej hierarchii Sectigo,
• wykryć błędy, które mogą ujawnić się dopiero po migracji Root CA.

To podstawowy punkt odniesienia przed jakimikolwiek zmianami.

Monitoruj zmiany issuerów i ponowne wydania certyfikatów.

W trakcie migracji Sectigo część certyfikatów może zostać ponownie wydana w nowej hierarchii, zwłaszcza w ramach subskrypcji wieloletnich lub automatycznych odnowień. Bez monitoringu takie zmiany często pozostają niezauważone aż do momentu wystąpienia problemu.

➡ Włącz ciągły nadzór z SSL Monitor, aby:

• otrzymywać alerty o zmianach w issuerze certyfikatu,
• kontrolować spójność konfiguracji TLS w wielu domenach,
• szybko reagować na nieoczekiwane zmiany w łańcuchu zaufania.

Monitoring jest kluczowy zwłaszcza w środowiskach produkcyjnych i multi-domenowych.

Zautomatyzuj diagnostykę w środowiskach technicznych.

Jeżeli zarządzasz większą liczbą domen, API lub środowisk testowych, ręczna weryfikacja nie skaluje się. Migracja Root CA powinna być traktowana jak zmiana infrastrukturalna, a nie incydent jednorazowy.

➡ Wykorzystaj HEXSSL-CLI do:

• automatycznych testów HTTPS i HSTS,
• audytu wielu domen w jednym przebiegu,
• integracji kontroli TLS z pipeline’ami CI/CD,
• wykrywania różnic pomiędzy środowiskami testowymi i produkcyjnymi.

To podejście minimalizuje ryzyko błędów po wdrożeniu nowych certyfikatów.

Uporządkuj zarządzanie certyfikatami w jednym miejscu.

Migracja Sectigo Public Root CAs bardzo często ujawnia brak centralnej widoczności: certyfikaty są rozproszone, dokumentacja nieaktualna, a odpowiedzialność niejednoznaczna.

HEXSSL pozwala:

• centralnie zarządzać portfelem certyfikatów,
• analizować historię zmian hierarchii CA,
• przygotować się na audyty bezpieczeństwa i compliance,
• budować spójną strategię TLS zamiast reagować na incydenty.

To szczególnie istotne w organizacjach, które traktują certyfikaty jako element krytycznej infrastruktury, a nie jednorazowy zakup.

Migracja Sectigo Public Root CAs to zmiana fundamentalna, ale przewidywalna i dobrze zaplanowana. Dla nowoczesnych środowisk będzie niemal niewidoczna, natomiast dla systemów legacy może stanowić impuls do koniecznych aktualizacji. Z perspektywy bezpieczeństwa i długoterminowej stabilności ekosystemu PKI jest to krok w dobrym kierunku. Migracja Sectigo Public Root CAs sama w sobie nie stanowi zagrożenia. Jest jednak momentem, w którym niedoskonałości w konfiguracji TLS i zarządzaniu PKI przestają być niewidoczne. Zamiast reagować dopiero po wystąpieniu problemu, warto wykorzystać ten etap do wzmocnienia kontroli nad certyfikatami.

➡ Sprawdź swoją domenę już teraz w SSL Checker.
➡ Włącz monitoring w SSL Monitor.
➡ Zautomatyzuj audyty dzięki HEXSSL-CLI.

Takie podejście pozwala przejść przez migrację Sectigo Root CA w sposób przewidywalny, kontrolowany i zgodny z aktualnymi standardami bezpieczeństwa. Masz pytania związane z migracją? Zapraszamy do kontaktu z nami.

Dodatkowo więcej informacji na temat planowanej migracji: Sectigo Public Root CAs Migration.