Skrócenie ważności do 200 dni - mechanika, terminy, konsekwencje

Od 2026 roku branża CA/Browser Forum (reguły dla publicznie zaufanych certyfikatów TLS) wprowadza krótszy maksymalny okres ważności certyfikatów SSL/TLS: 200 dni (a potem kolejne redukcje). Zmiana dotyczy nowo wystawianych certyfikatów i ma wymusić bardziej „ciągły” model zarządzania cyklem życia (automation-first), zamiast corocznych, ręcznych odnowień.

Ważne (daty): W wymaganiach CA/Browser Forum jako punkt graniczny najczęściej wskazywany jest 15 marca 2026 dla limitu 200 dni.
Jednocześnie część CA / dostawców API może zacząć „przycinać” ważność wcześniej (np. do 199 dni) z powodów operacyjnych.

1) Co dokładnie się zmienia?

1.1 Maksymalna ważność certyfikatu.

• Do czasu wejścia w życie zmian: 398 dni (praktycznie „1 rok”).

• Od etapu 200-dniowego: maks. 200 dni ważności certyfikatu (w praktyce wielu dostawców będzie wydawać 199 dni jako bezpieczny bufor).

1.2 Skraca się też „okno reuse” walidacji domeny (DCV).

To druga, często pomijana zmiana: maksymalny okres ponownego wykorzystania danych walidacyjnych (DCV)również spada do 200 dni (a później jeszcze niżej).
W praktyce oznacza to, że jeśli jedziesz „ręcznie” na e-mailach/HTTP-file i odkładasz walidacje, to częściej wpadniesz w sytuację „muszę zrobić walidację od nowa”.

1.3 Zmiana jest etapowa (roadmap).

Najczęściej komunikowany harmonogram (public TLS):

• 15 marca 2026 → max 200 dni

• 15 marca 2027 → max 100 dni

• 15 marca 2029 → max 47 dni
  To oznacza, że „200 dni” to nie meta – to pierwszy krok w stronę bardzo krótkich cykli.

2) Mechanika: jak CA liczy ważność i co to oznacza w praktyce?

2.1 Liczy się data wystawienia (issuance), nie data zakupu.

To kluczowe operacyjnie: nawet jeśli kupisz wcześniej, limit maksymalnej ważności dotyczy tego, kiedy certyfikat zostanie wystawiony. Wokół dat granicznych część CA wprowadza dodatkowe cut-offy w systemach/API, żeby uniknąć błędów.

2.2 „Wieloletni certyfikat” nie znika – zmienia się forma dostarczenia.

Wiele ofert zostaje jako subskrypcja wieloletnia, ale technicznie dostajesz kolejne krótkie certyfikaty w ramach opłaconego okresu (re-issue / renew w trakcie). Czyli: biznesowo „płacisz raz”, operacyjnie „wdrażasz częściej”.

2.3 Odnowienie vs reissue (praktyka).

W zależności od CA i panelu:

• Renewal – nowy cykl na kolejny okres (w subskrypcji: kolejna „porcja” certu),

• Reissue – ponowne wystawienie „w ramach” tego samego okresu/subskrypcji (np. przy zmianie serwera, dodaniu SAN, utracie klucza).

W krótkim cyklu to rozróżnienie mniej obchodzi adminów niż jedno: czy masz proces i automaty, które robią to bezpiecznie i powtarzalnie.

3) Czy naprawdę „trzeba wygenerować nowe CSR”?

3.1 Wymogi vs najlepsze praktyki.

Same reguły skracające ważność nie zawsze mówią „CSR musi być nowe”, ale w praktyce:

• wiele CA / paneli wymusza nowe CSR przy odnowieniu,

• a nawet jeśli nie wymusza: rotacja klucza przy każdym cyklu jest rozsądną praktyką bezpieczeństwa (ogranicza skutki ewentualnego wycieku klucza prywatnego).

Dlatego bezpieczne i skalowalne założenie procesowe brzmi:

Każdy nowy certyfikat = nowa para kluczy + nowe CSR (automatyzowalne).

3.2 Konsekwencje dla infrastruktury.

Jeśli rotujesz klucze:

• musisz mieć kontrolę nad miejscami, gdzie klucz „żyje” (LB/WAF, serwery WWW, K8s secrets, appliances),

• musisz umieć przeprowadzić atomową podmianę cert+key bez downtime,

• musisz ogarnąć rollback.

4) Konsekwencje biznesowe i techniczne.

4.1 Podwajasz liczbę operacji rocznie.

Przy 398 dniach – ~1 wdrożenie/rok.
Przy 200 dniach – ~2 wdrożenia/rok.
Przy 100 dniach – ~4/rok.
Przy 47 dniach – ~8/rok.

W dużej organizacji to natychmiast ujawnia:

• brak inwentaryzacji certyfikatów,

• „ręczne wyjątki”,

• brak automatyzacji DCV,

• brak standardu wdrożenia.

4.2 Ryzyko incydentów rośnie, jeśli zostajesz przy ręcznym zarządzaniu.

Typowe scenariusze awarii:

• cert wygasł, bo ktoś był na urlopie,

• zmienił się DNS/WAF i walidacja nie przechodzi,

• brak uprawnień do strefy DNS (DNS-01), a e-mail DCV trafia na martwy alias,

• cert jest na „niewidzialnym” endpointcie (stary LB, zapomniany hostname, środowisko testowe wystawione do internetu).

4.3 Compliance / audyt.

Krótszy cykl będzie coraz częściej wymagany „pośrednio”:

• audyty pytają o certificate lifecycle management,

• rośnie znaczenie monitoringu i alertów,

• w środowiskach regulowanych liczy się udokumentowana procedura odnowień.

5) Jak się przygotować – plan wdrożeniowy (praktyczny).

Poniżej proces, który skaluje się od 1 domeny do tysięcy:

Krok 1 — Inwentaryzacja (najważniejsze).

Zbierz listę:

• wszystkie FQDN/SAN, wildcardy,

• gdzie jest terminacja TLS (LB, reverse proxy, app server, CDN),

• kto jest właścicielem (owner) i jaki jest kanał alertów,

• metoda walidacji (DNS/HTTP/email),

• czy endpoint jest publiczny czy wewnętrzny.

Cel: żadnych „ukrytych” certów.

Krok 2 — Standaryzacja metody DCV.

Jeśli możesz, dąż do:

• DNS-01 (najbardziej automatyzowalne, dobre także dla wildcard),

• ewentualnie HTTP-01 (gdy masz jednolity reverse proxy / well-known).

Unikaj w długim terminie e-mail DCV jako podstawy procesu (zbyt zależne od ludzi i skrzynek).

Krok 3 — Automatyzacja odnowień i wdrożeń.

Minimalny standard:

• odnowienie co 60–90 dni (nie „na styk”),

• health-check po wdrożeniu (czy nowy cert „wisi” na zewnątrz),

• rollback (powrót do poprzedniego certu).

Dla środowisk:

• Kubernetes: cert-manager + ACME + DNS-01,

• Reverse proxy: automatyczny reload i walidacja,

• LB/ADC: integracja API lub pipeline.

Krok 4 — Monitoring i alerty (twarde SLA operacyjne).

Ustal progi alarmów, np.:

• 45 dni do wygaśnięcia → alert informacyjny,

• 21 dni → alert wysoki,

• 7 dni → alert krytyczny + eskalacja.

I koniecznie: alerty o braku możliwości walidacji DCV (to często wybucha przed samym odnowieniem).

Krok 5 — Procedury zmian (Change Management).

Wpisz do standardu:

• kiedy robisz odnowienie (okno serwisowe vs zero-downtime),

• kto akceptuje zmianę (jeśli wymagane),

• jak dokumentujesz i jak testujesz po zmianie (SNI/cipher/chain).

6) Co to oznacza dla klientów i sprzedaży (model komunikacyjny)?

Jeśli oferujesz certyfikaty komercyjnie (tak jak HEXSSL):

• Komunikuj jasno, że „ważność produktu” może być wieloletnia, ale wydania certyfikatu będą krótsze (200/100/47). 

• Podkreśl: „to nie podwyżka, tylko zmiana reżimu branżowego”.

• Dodaj CTA do automatyzacji i monitoringu (narzędzia, instrukcje, checklisty).

FAQ (10 najczęstszych pytań).

1) Od kiedy obowiązuje limit 200 dni?

W wymaganiach branżowych (CA/Browser Forum) etap 200 dni jest wiązany z 15 marca 2026. Niektóre CA mogą ograniczać ważność wcześniej operacyjnie (np. 199 dni).

2) Czy dotyczy to wszystkich certyfikatów?

Dotyczy publicznie zaufanych certyfikatów TLS/SSL dla serwerów (web/endpointy w przeglądarkach). Nie myl tego automatycznie z certyfikatami wewnętrznymi (private PKI) – tam politykę ustalasz sam, ale i tak warto iść w automatyzację.

3) Czy mój certyfikat, który już mam, zostanie skrócony?

Zwykle nie: certyfikaty już wystawione zachowują swój okres ważności. Zmiana dotyczy nowo wystawianych po wejściu limitów.

4) Czy „roczny certyfikat” zniknie z oferty?

Najczęściej zostaje model handlowy „rok” lub „multi-year”, ale każde wystawienie będzie krótsze (np. 199 dni), a reszta realizowana jako kolejne wystawienia w ramach subskrypcji.

5) Czy naprawdę muszę generować nowe CSR przy każdym odnowieniu?

Procesowo warto założyć: tak (nowe CSR + rotacja klucza). To ułatwia standaryzację i ogranicza ryzyko przy ewentualnym wycieku klucza. Część CA/paneli i tak to wymusi.

6) Co z walidacją domeny (DCV) – czy też muszę ją robić częściej?

Tak. Maksymalny okres ponownego wykorzystania danych walidacyjnych (DCV reuse) również spada do 200 dni w tym samym etapie.

7) Jaką metodę walidacji wybrać, żeby to nie bolało?

Najbardziej skalowalna jest DNS-01, bo da się ją automatyzować i działa też dla wildcardów.
HTTP-01 bywa ok, jeśli masz jednolity reverse proxy i kontrolę nad /.well-known/.

8) Ile wcześniej odnawiać certyfikat przy 200 dniach?

Praktycznie celuj w odnowienia „w połowie cyklu” albo wcześniej, np. 60–90 dni przed wygaśnięciem, żeby mieć bufor na problemy z DCV i wdrożeniem.

9) Co jest największym ryzykiem po skróceniu ważności?

Nie samo „częstsze klikanie”, tylko:

• brak inwentaryzacji,

• brak automatyzacji DCV,

• brak monitoringu i eskalacji,

• endpointy „shadow IT”.

10) Czy to ostatnia taka zmiana?

Nie. Harmonogram branżowy przewiduje dalsze skracanie (100 dni w 2027 i 47 dni w 2029). Dlatego wdrażanie automatyzacji „na 200 dni” najlepiej zrobić tak, żeby później bez bólu zejść do 100/47.

Szybka checklista „minimum na 200 dni”.

• Mam pełną listę certyfikatów i endpointów.

• Dla każdej domeny wiem: owner, metoda DCV, miejsce terminacji TLS.

• Odnowienie jest zautomatyzowane lub przynajmniej ustandaryzowane i testowalne.

• Mam alerty na 45/21/7 dni oraz eskalację.

• Mam procedurę wymiany cert+key oraz rollback.

• DCV robię metodą, którą da się automatyzować (preferowane DNS-01).