# 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).