200-dniowy limit ważności dla publicznie zaufanych certyfikatów TLS wszedł w życie 15 marca 2026 roku. Najwcześniej wydane certyfikaty o tym maksymalnym okresie wygasną na przełomie września i października 2026 roku. Dla wielu zespołów będzie to pierwszy praktyczny sprawdzian, czy proces odnawiania certyfikatów obejmuje cały cykl - aż do punktu końcowego (endpointu). Kolejne skrócenie okresu ważności, tym razem do 100 dni, nastąpi niespełna sześć miesięcy później, 15 marca 2027 r.
Wiele zespołów zautomatyzowało już przynajmniej etap odnawiania certyfikatów, jednak jest to tylko jeden z etapów znacznie dłuższego procesu. O pełnej automatyzacji można mówić dopiero wtedy, gdy odnowiony certyfikat zostanie wdrożony na punkt końcowy, przypisany do właściwej usługi, aktywowany oraz zweryfikowany jako certyfikat faktycznie prezentowany lub wykorzystywany przez dany endpoint. W środowiskach hybrydowych to właśnie na tym etapie automatyzacja najczęściej zawodzi.
Harmonogram zmian wynika z decyzji CA/Browser Forum z 2025 roku, przyjętej w ramach głosowania SC-081v3, która przewiduje skrócenie maksymalnego okresu ważności publicznie zaufanych certyfikatów TLS w czterech etapach:
• 398 dni - dotychczasowy maksymalny okres ważności
• 200 dni - od 15 marca 2026 r.
• 100 dni - od 15 marca 2027 r.
• 47 dni - od 15 marca 2029 r.
Każdy kolejny etap oznacza wzrost obciążenia operacyjnego. Środowisko liczące 100 publicznie zaufanych certyfikatów przechodzi z około 100 cykli wymiany rocznie (przy poprzednim limicie) do około 180 cykli przy limicie 200 dni. Liczba ta wzrasta do około 365 przy 100 dniach i do blisko 780 przy 47 dniach. Są to wartości przybliżone, ponieważ w praktyce certyfikaty są zazwyczaj odnawiane przed upływem maksymalnego okresu ważności.
Egzekwowanie tych zmian odbywa się w ramach systemu publicznego zaufania. Urzędy certyfikacji (CA) muszą wydawać certyfikaty zgodnie z nowymi limitami, a programy zaufanych głównych urzędów certyfikacji (root programs) przeglądarek internetowych i systemów operacyjnych traktują zgodność z tymi wymaganiami jako warunek utrzymania statusu zaufanego urzędu. Organizacje korzystające z publicznie zaufanych certyfikatów nie mają możliwości zachowania dotychczasowych, dłuższych okresów ważności. Zmiany te nie obejmują bezpośrednio prywatnej infrastruktury klucza publicznego (Private PKI), jednak te same problemy związane z automatyzacją pojawiają się również tam, gdzie skracany jest okres ważności certyfikatów wewnętrznych.
Choć łatwo wskazać proces automatycznego odnawiania certyfikatów wykonywany według ustalonego harmonogramu, znacznie ważniejsze jest to, co dzieje się pomiędzy wydaniem nowego certyfikatu a jego rzeczywistym wykorzystaniem przez docelową usługę. Aby to zweryfikować, warto przeprowadzić krótki audyt tego procesu:
• Czy wszystkie certyfikaty zostały wykryte i przypisane do właścicieli?
• Czy proces odnowienia uruchamia się automatycznie, bez konieczności tworzenia zgłoszenia (ticketu)?
• Czy nowy certyfikat jest wdrażany na wszystkich endpointach, które go wymagają?
• Czy aktualizowane są właściwe elementy konfiguracji, takie jak listener, powiązanie (binding), magazyn kluczy (keystore), sekret (secret) lub konfiguracja aplikacji?
• Czy usługa lub obciążenie robocze (workload) jest przeładowywane albo restartowane tam, gdzie jest to wymagane?
• Czy po wdrożeniu wykonywana jest weryfikacja endpointu w celu potwierdzenia, że zmiana została zastosowana?
• Czy awarie i nieobsługiwane systemy są kierowane do odpowiedniego właściciela i monitorowane aż do rozwiązania problemu?
Pomyślne odnowienie certyfikatu potwierdza jedynie, że nowy certyfikat został wydany. Nie oznacza natomiast, że aplikacja, urządzenie, usługa chmurowa lub klaster rzeczywiście z niego korzystają. Automatyzacja pozostaje niekompletna wszędzie tam, gdzie proces kończy się na etapie wydania lub odnowienia certyfikatu, a w środowisku hybrydowym może zatrzymać się w kilku miejscach.
W praktyce problem rzadko sprowadza się do pominięcia jednego etapu tego procesu. Certyfikaty funkcjonują w wielu różnych miejscach, z których każde ma własny sposób przyjmowania i aktywowania nowego certyfikatu. W jednej organizacji certyfikaty mogą być wykorzystywane na:
• Serwerach z systemami Windows i Linux,
• Serwerach aplikacyjnych oraz w magazynach kluczy Java (Java Keystore),
• Modułach równoważenia obciążenia (load balancerach) i serwerach proxy typu reverse proxy,
• Strefach DMZ oraz na zdalnych hostach,
• Magazynach certyfikatów w usługach AWS i Azure,
• Sekretach TLS w środowiskach Kubernetes.
Za poszczególne środowiska często odpowiadają różne zespoły, korzystające z różnych urzędów certyfikacji (CA), prowadzące odrębne inwentaryzacje zasobów oraz wykorzystujące różne narzędzia lub skrypty do wdrażania certyfikatów. Automatyczne odnawianie może działać wyłącznie w warstwie serwerów WWW, podczas gdy w pozostałych środowiskach proces nadal jest wykonywany ręcznie. W efekcie organizacjom często brakuje jednego, spójnego widoku pokazującego, który certyfikat jest faktycznie używany przez każdy endpoint.
Organizacje nauczyły się już centralizować widoczność zasobów w środowiskach hybrydowych. Operacje związane z zarządzaniem certyfikatami wymagają dziś takiego samego podejścia: jednej inwentaryzacji, jednego procesu oraz mechanizmu pozwalającego zweryfikować, jaki certyfikat jest rzeczywiście wykorzystywany przez każdy endpoint.
Awarie mają bardzo konkretny charakter i zazwyczaj powtarzają się według podobnego schematu. Oto trzy przykłady pokazujące, gdzie najczęściej dochodzi do awarii na etapie tzw. „ostatniej mili” w środowiskach hybrydowych.
Windows i IIS: Certyfikat zostaje odnowiony i trafia do magazynu certyfikatów systemu Windows, jednak powiązanie (binding) w usłudze IIS nadal wskazuje na poprzedni certyfikat. W rezultacie strona w dalszym ciągu wskazuje na wygasający certyfikat.
Kubernetes: Sekret TLS zostaje zaktualizowany w klastrze, ale kontroler Ingress lub uruchomione obciążenie (workload) nie wychwytuje tej zmiany. W efekcie endpoint nadal korzysta z poprzedniego certyfikatu do momentu ponownego przeładowania konfiguracji.
Środowiska chmurowe i lokalne: Certyfikat zostaje odnowiony w magazynie certyfikatów w chmurze, podczas gdy moduł równoważenia obciążenia lub aplikacja nadal korzystają z oddzielnie zaimportowanej kopii, której nie objął żaden proces automatyzacji.
W każdym z tych przypadków proces odnowienia zakończył się sukcesem, a panel administracyjny może wskazywać, że wszystko jest aktualne. Mimo to endpoint nieuchronnie zmierza w kierunku awarii związanej z wygaśnięciem certyfikatu. Kilka wskaźników pozwala uwidocznić te luki, zanim doprowadzą do przestojów:
• Stopień pokrycia inwentaryzacji - odsetek wykrytych i monitorowanych certyfikatów,
• Poziom automatyzacji odnowień oraz automatycznych wdrożeń certyfikatów,
• Czas od wydania certyfikatu do jego aktywacji na endpointcie,
• Niezgodności synchronizacji między repozytorium a tym, co jest rzeczywiście wdrożone,
• Wyjątki wymagające ręcznej obsługi, których termin wygaśnięcia zbliża się do końca.
Pełna automatyzacja obejmuje cały cykl życia certyfikatu i składa się z sześciu etapów:
1. Wykrywanie i klasyfikacja wszystkich certyfikatów wraz z przypisaniem właściciela oraz informacją o miejscu ich wykorzystania.
2. Odnowienie lub wydanie nowego certyfikatu za pośrednictwem odpowiedniego urzędu certyfikacji (CA) albo integracji z protokołem ACME.
3. Wdrożenie certyfikatu do wszystkich zdefiniowanych lokalizacji docelowych.
4. Aktywacja certyfikatu poprzez aktualizację powiązania (binding), ponowne wczytanie konfiguracji (reload), restart usługi lub odświeżenie sekretu (secret refresh) - zależnie od wymagań danego środowiska.
5. Weryfikacja czy certyfikat jest rzeczywiście prezentowany przez endpoint lub wykorzystywany przez niego.
6. Monitorowanie terminów wygaśnięcia, synchronizacji, niepowodzeń oraz wyjątków wymagających interwencji.
Samo umieszczenie pliku z certyfikatem na serwerze nie oznacza jeszcze, że usługa zaczęła z niego korzystać. To właśnie na etapie pomiędzy wdrożeniem a aktywacją najczęściej dochodzi do sytuacji, w których certyfikaty wygasają, mimo że panel monitorowania nadal pokazuje je jako pomyślnie odnowione. Z tego powodu wdrożenie i aktywacja zostały celowo potraktowane jako dwa odrębne etapy procesu.
Pełna automatyzacja nie oznacza również zakładania, że wszystkie systemy obsługują identyczny proces. Oznacza natomiast identyfikowanie wyjątków, przypisywanie ich odpowiedzialnym osobom oraz eliminowanie nieformalnych, ręcznych działań, które nie są w żaden sposób nadzorowane.
Na rynku dostępnych jest kilka platform do zarządzania cyklem życia certyfikatów, które wspierają taki model pracy. ManageEngine Key Manager Plus wspiera zarządzanie certyfikatami w środowiskach hybrydowych i wpisuje się we wszystkie sześć etapów, oferując:
• Wykrywanie (Discovery) certyfikatów w całej sieci oraz cykliczne skanowanie środowiska, w tym z wykorzystaniem agentów dla zdalnych hostów i systemów znajdujących się w strefach DMZ,
• Odnawianie (Renewal) certyfikatów poprzez integrację z obsługiwanymi publicznymi i prywatnymi urzędami certyfikacji (CA) oraz z protokołem ACME,
• Wdrażanie (Deployment) certyfikatów do obsługiwanych środowisk, w tym modułów równoważenia obciążenia (load balancerów), powiązań (bindings) w IIS, serwerów z systemami Linux i Windows, usługi AWS Certificate Manager oraz Azure Key Vault,
• Działania powdrożeniowe (Post-deployment actions) dla obsługiwanych procesów, takich jak uruchamianie skryptów lub restart usług wymaganych do aktywacji certyfikatu,
• Zarządzanie oraz rotacja obiektów TLS Secret w Kubernetes, z obsługą przeładowywania obciążeń (workloads) dostosowaną do danego środowiska Kubernetes,
• Okresowe kontrole synchronizacji w celu wykrywania rozbieżności pomiędzy certyfikatami znajdującymi się w repozytorium a certyfikatami wdrożonymi w przypisanych lokalizacjach,
• Panele monitorowania terminów wygaśnięcia certyfikatów, powiadomienia wysyłane pocztą elektroniczną i poprzez syslog oraz raporty na potrzeby przeglądów i audytów.
Pierwsze certyfikaty wydane z 200-dniowym okresem ważności wkrótce będą wymagały odnowienia, a skrócenie maksymalnego okresu ważności do 100 dni nastąpi już niedługo później. Zanim to nastąpi, warto zweryfikować nie tylko to, czy certyfikaty odnawiają się automatycznie. Należy również upewnić się, że każdy odnowiony certyfikat trafia do wszystkich wymaganych endpointów, zostaje poprawnie aktywowany oraz zweryfikowany jako certyfikat faktycznie używany przez daną usługę. Każde ręczne przekazanie zadania pomiędzy etapami procesu lub każde nieweryfikowane wdrożenie stanowi lukę, którą krótszy okres ważności certyfikatów będzie ujawniał coraz częściej.
Wypróbuj Key Manager Plus, aby zintegrować wykrywanie certyfikatów, obsługiwane procesy odnawiania i wdrażania, weryfikację synchronizacji oraz monitorowanie terminów wygaśnięcia w jednym spójnym procesie obejmującym zarówno środowiska lokalne (on-premises), jak i chmurowe. Niezależnie od stopnia zaawansowania obecnej automatyzacji, takie podejście pozwoli lepiej przygotować organizację na nadchodzące zmiany.
Artykuł Partnera
