Skracanie ważności certyfikatów Code Signing od 1 marca 2026

Każdy, kto kiedykolwiek zarządzał certyfikatami code signing, zna ten błogi spokój: kupujesz certyfikat na trzy lata, tworzysz przypomnienie gdzieś na końcu kalendarza i — o ile nic dramatycznego się nie wydarzy — zapominasz o całej sprawie. Ten komfort kończy się 1 marca 2026.

Od tej daty nowe certyfikaty podpisu kodu mogą być wydawane maksymalnie na 1 rok (398 dni). Żaden CA nie wyda dłuższego. Bez wyjątków. To nie chwilowa zmiana polityki — to branżowy kierunek, który wpisuje się w szerszy trend skracania cyklu życia certyfikatów. Jeśli wolisz być gotowy przed deadline’em niż gasić pożary po nim, czas zacząć działać już teraz.

Co się zmienia?

Stan obecny (co zostawiamy za sobą)

• Maksymalna ważność: 3 lata (około 1 095 dni)
• Powszechna praktyka: Kup certyfikat, zapomnij o nim na 2–3 lata
• Częstotliwość odnowień: Ta jedna panikująca noc, gdy certyfikat wygasł niespodziewanie podczas wydania

Nowa rzeczywistość (od 1 marca 2026)

• Maksymalna ważność: 1 rok (398 dni)
• Wszystkie nowe certyfikaty: Muszą spełniać nowy limit — bez wyjątków
• Istniejące certyfikaty: Pozostają ważne do daty wygaśnięcia (ten 3-letni kupiony w 2025 jest bezpieczny)
• Termin: Obowiązujący od 1 marca 2026
• Praktyczny skutek: Trzykrotnie częstsze odnowienia, trzykrotnie więcej okazji do zapomnienia, trzykrotnie więcej problemów procurement i deployment

Kogo to dotyczy?

Jeśli jesteś zaangażowany w dostarczanie oprogramowania, ta zmiana Cię dotyczy:

• Deweloperzy oprogramowania podpisujący aplikacje, pliki wykonywalne, instalatory i wszystko, co musi przekonać Windows lub macOS, że nie jest złośliwym oprogramowaniem
• Zespoły DevOps zarządzające pipeline’ami CI/CD — zaktualizujcie procedury rotacji certyfikatów, zanim deadline was zaskoczy
• Inżynierowie ds. wydań, którzy i tak już nienawidzą odnowień certyfikatów przypadających na środek krytycznego okna wydawniczego
• Zespoły IT i Security odpowiedzialne za zarządzanie cyklem życia certyfikatów i interwencje po incydentach o 3 w nocy
• Organizacje dystrybuujące podpisane oprogramowanie: aplikacje Windows, macOS, mobilne, rozszerzenia przeglądarek
• Producenci sprzętu podpisujący firmware i sterowniki — jeden wygasły certyfikat może zatrzymać całą linię produktów

Dobra wiadomość? Nie jesteś w tym sam — cała branża przechodzi przez to razem.
Zła wiadomość? Od teraz będziesz przez to przechodzić co roku.

Dlaczego to się dzieje?

CA/Browser Forum nie robi tego złośliwie — choć można mieć takie wrażenie. Za tą decyzją stoją konkretne argumenty bezpieczeństwa.

1. Wzmocnione bezpieczeństwo (teoria)

• Mniejsze okno ekspozycji: Skradziony klucz prywatny można nadużywać przez rok, a nie przez trzy
• Szybsza rotacja kluczy: Częstsze odnowienia oznaczają nowocześniejsze klucze kryptograficzne
• Nowsze standardy kryptograficzne: Organizacje są zmuszane do porzucenia starych certyfikatów z przestarzałą kryptografią na rzecz silniejszych algorytmów

2. Lepsza reakcja na incydenty (zderzenie z rzeczywistością)

• Szybsze odzyskiwanie: Gdy CA zostanie skompromitowane lub wycieknie klucz prywatny, krótszy period ważności ogranicza długoterminowe skutki
• Mniejszy problem z odwołaniem: Czy próbowałeś kiedyś odwołać 3-letni certyfikat osadzony w milionach zainstalowanych aplikacji? To koszmar
• Praktyczny skutek: Mniej czasu na wyjaśnianie zarządowi, dlaczego kompromitacja sprzed dwóch lat wciąż jest aktywnym problemem

3. Zgodność i trend branżowy

• Kontynuacja kierunku: Certyfikaty SSL/TLS już przez to przeszły — teraz kolej na code signing
• Presja regulacyjna: Frameworki bezpieczeństwa i wymagania zgodności coraz częściej wymagają krótszych okresów ważności
• Ścieżki audytu: Częstsze odnowienia to więcej dokumentacji dla audytora ISO 27001 (nie ma za co)

Szerszy kontekst: skracanie ważności certyfikatów SSL/TLS

Certyfikaty code signing nie są wyjątkiem — to część szerszego trendu. CA/Browser Forum konsekwentnie skraca okresy ważności certyfikatów SSL/TLS, a kierunek zmian jest jednoznaczny. Jeśli chcesz zobaczyć pełny obraz tego, dokąd zmierza branża — włącznie z proponowanym przejściem na 47-dniową ważność — przeczytaj nasz szczegółowy artykuł o skracaniu ważności certyfikatów SSL/TLS: 200, 100 i 47 dni.

Harmonogram dla SSL/TLS

• Przed 2015: Certyfikaty ważne do 5 lat
• 2015–2018: Maksimum zredukowane do 3 lat (1 095 dni)
• 2018–2020: Dalsze skrócenie do 2 lat (825 dni)
• Wrzesień 2020: Obecne maksimum 398 dni (13 miesięcy)
• Proponowane zmiany:
  • Redukcja do 200 dni
  • Dalsza redukcja do 100 dni
  • Docelowo do 47 dni
  • Skrócenie okresu ponownego użycia DCV (Domain Control Validation) do 10 dni

Dlaczego to ma znaczenie

To nie jest biurokratyczna zmiana dla zmiany — krótsze okresy ważności oznaczają:

• Lepsze bezpieczeństwo: Skompromitowane certyfikaty mają mniejsze okno nadużycia
• Szybsza elastyczność kryptograficzna: Organizacje częściej wdrażają nowe algorytmy i rozmiary kluczy
• Większy narzut operacyjny: Częstsze odnowienia to więcej okazji do błędu ludzkiego, zapomnianych certyfikatów i awarii usług

Redukcja ważności certyfikatów code signing do 1 roku (398 dni) jest elementem tego ogólnobranżowego trendu w kierunku krótszych cykli życia certyfikatów.

Co musisz zrobić

Oto plan działania. Wdróż go teraz — zanim będziesz gasić pożary wygasłego certyfikatu w trakcie krytycznego wydania.

1. Przeprowadź audyt certyfikatów (zacznij tutaj)

Znajdź wszystkie certyfikaty podpisu kodu, zanim one znajdą Ciebie:

# Check certificate expiration dates
# Windows (PowerShell)
Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object {$_.EnhancedKeyUsageList -match "Code Signing"}

# macOS/Linux (check keychain/keystore)
security find-identity -v -p codesigning

Do zrobienia:

• Stwórz inwentarz wszystkich certyfikatów code signing (tak, łącznie z tym, który kupił zewnętrzny wykonawca dwa lata temu i nikt go nie udokumentował)
• Udokumentuj, które aplikacje i produkty korzystają z każdego certyfikatu — przyszły ty będzie wdzięczny
• Zidentyfikuj certyfikaty wygasające po 1 marca 2026
• Ustal, kto faktycznie ma dostęp do ich odnowienia (spoiler: prawdopodobnie ktoś, kto już odszedł z firmy)

2. Zaktualizuj proces odnowień (zanim Cię zaskoczy)

Zbuduj kalendarz odnowień, który faktycznie działa:

• Ustaw przypomnienia 60 dni przed wygaśnięciem (i 30, i 7 — bo pierwsze dwa zignorujesz)
• Przejdź z modelu „kup i zapomnij na 3 lata" na roczny cykl odnowień
• Zaplanuj budżet na częstsze opłaty CA — dział finansów nie będzie zachwycony
• Wyznacz zastępców do obsługi odnowień (bo podstawowa osoba będzie na urlopie, gdy certyfikat wygaśnie)

Automatyzuj, gdzie to możliwe:

• Zintegruj monitoring certyfikatów z pipeline’em DevOps
• Skonfiguruj alerty, które trafiają do właściwych osób — nie do współdzielonej skrzynki, której nikt nie sprawdza
• Rozważ scentralizowane narzędzia do zarządzania certyfikatami, takie jak CrtMgr — gdy zarządzasz dziesiątkami certyfikatów z rocznymi expiracjami, arkusz kalkulacyjny po prostu nie wystarczy
• Przetestuj system alertów, zanim zaczniesz na nim polegać

3. Przejrzyj pipeline CI/CD (to krytyczne)

Zaktualizuj procesy build i podpisywania:

• Upewnij się, że narzędzia CI/CD obsługują rotację certyfikatów bez zrywania całego procesu build
• Udokumentuj procedury wymiany certyfikatów krok po kroku, jakbyś tłumaczył komuś, kto robi to po raz pierwszy
• Testuj aktualizacje certyfikatów na środowiskach staging — nigdy na produkcji
• Dodaj weryfikację wygaśnięcia certyfikatów do pre-build validation
• Zaplanuj procedury rollbacku na wypadek, gdy coś pójdzie nie tak

Jeśli szukasz wzorca do automatycznego zarządzania certyfikatami w Kubernetes, nasz artykuł o automatyzacji SSL z cert-manager w Kubernetes pokazuje, jak zbudować solidny pipeline, który eliminuje ręczne interwencje.

Przykładowy krok w GitHub Actions workflow:

- name: Check Code Signing Certificate Expiry
  run: |
    CERT_EXPIRY=$(security find-certificate -c "Your Code Signing Cert" -p | openssl x509 -noout -enddate)
    echo "Certificate expires: $CERT_EXPIRY"
    # Add logic to warn if expiring within 60 days
    # Better yet, fail the build if expiring within 30 days

Praktyczne wskazówki:

• Aktualizacje certyfikatów podczas aktywnego development mogą blokować wydania
• Planuj okna odnowień w okresach niskiej aktywności
• Miej plan komunikacji na wypadek problemów przy rotacji certyfikatów
• Zachowaj dostęp do starych certyfikatów do weryfikacji historycznych podpisów

4. Wdróż timestamping (absolutnie obowiązkowe)

Krytyczne: Zawsze używaj timestampingu RFC 3161 przy podpisywaniu kodu. To nie jest opcja.

Timestamping dowodzi, że kod był podpisany, gdy certyfikat był ważny. Bez niego podpis wygasa razem z certyfikatem. Konsekwencje:

• Oprogramowanie blokowane przez Windows SmartScreen
• macOS Gatekeeper odmawia uruchomienia
• Użytkownicy widzą alarmujące komunikaty ostrzegawcze
• Zespół wsparcia zalany zgłoszeniami „aplikacja nie działa"
• Konieczność ponownego podpisania i redystrybucji wszystkiego

Z timestampingiem podpisany kod pozostaje ważny bezterminowo, nawet po wygaśnięciu certyfikatu. To różnica między „podpisz raz, działa zawsze" a „podpisuj wszystko co roku".

Przykłady użycia timestampingu:

# Windows (signtool)
signtool sign /f certificate.pfx /p password /t http://timestamp.digicert.com /fd sha256 application.exe

# macOS (codesign with timestamp)
codesign -s "Developer ID Application" --timestamp application.app

# Java (jarsigner)
jarsigner -tsa http://timestamp.digicert.com -keystore keystore.jks application.jar

Zalecane urzędy timestampingu:

• DigiCert: http://timestamp.digicert.com
• Sectigo: http://timestamp.sectigo.com
• GlobalSign: http://timestamp.globalsign.com

Porady praktyczne:

• Zawsze weryfikuj, czy timestamping zadziałał po podpisaniu
• Używaj kilku serwerów timestamp jako fallback (zdarzają się przestoje)
• Monitoruj dostępność serwerów timestamp w pipeline build — jeśli timestamping się nie powiedzie, build też powinien zakończyć się błędem
• Nie wysyłaj binarek bez znacznika czasu

Jeśli chcesz zbudować kompleksowy monitoring dostępności serwerów timestamp oraz stanu certyfikatów, artykuł o monitorowaniu SSL z Prometheus i Grafana pokazuje, jak skonfigurować alerty działające zanim cokolwiek wygaśnie.

5. Zaplanuj użycie Hardware Security Modules (HSM)

Dla zwiększonego bezpieczeństwa — i żeby dział security był spokojniejszy — rozważ HSM lub usługi podpisywania w chmurze:

• Korzyści: Klucze prywatne nigdy nie opuszczają HSM, scentralizowane podpisywanie, logi audytu, kontrola dostępu oparta na rolach
• Opcje chmurowe: Azure Key Vault, AWS CloudHSM, DigiCert ONE, Google Cloud HSM
• On-premise: Tokeny USB (YubiKey i podobne), sieciowe HSM (Thales, nCipher)
• Kwestia kosztów: Droższe na wejściu, ale lepsza ochrona i prostsza rotacja kluczy

Zderzenie z rzeczywistością: Jeśli podpisujesz oprogramowanie, na którym polegają tysiące użytkowników, przechowywanie klucza prywatnego w pliku .pfx chronionym hasłem ustawionym jako zmienna środowiskowa w Jenkinsie to nie jest godna pozazdroszczenia postawa bezpieczeństwa.

6. Zaktualizuj dokumentację i przeprowadź szkolenia (nie pomijaj tego)

• Zaktualizuj dokumentację wewnętrzną uwzględniając nowe okresy ważności i procedury odnowień
• Przeszkol deweloperów w zakresie rocznych cykli odnowień — nie zakładaj, że sami o tym wiedzą
• Zakomunikuj zmiany osobom zatwierdzającym zakupy certyfikatów: procurement, finanse, security
• Udokumentuj skutki wygaśnięcia: Co się psuje? Kogo powiadomić? Jaka jest procedura awaryjna?
• Stwórz runbooki: Instrukcje krok po kroku zarówno dla planowanych odnowień, jak i scenariuszy awaryjnych „certyfikat wygasł, trzeba działać natychmiast"

Harmonogram przejścia

Najczęściej zadawane pytania

P: Czy muszę wymienić istniejący 3-letni certyfikat?
O: Nie. Istniejące certyfikaty pozostają ważne do daty wygaśnięcia. Nowy limit dotyczy wyłącznie certyfikatów wydanych od 1 marca 2026. Jeśli kupiłeś 3-letni certyfikat w lutym 2026 — gratulacje, masz spokój do 2029.

P: Czy to wpłynie na już podpisane oprogramowanie?
O: Jeśli używałeś timestampingu (używałeś, prawda?), Twoje podpisane oprogramowanie działa dalej bez zmian. Bez timestampingu podpisy wygasają razem z certyfikatem i trzeba będzie podpisać wszystko od nowa. Właśnie dlatego timestamping jest absolutnie kluczowy.

P: Czy mogę uzyskać dłuższy okres ważności od swojego CA?
O: Nie. To branżowy standard egzekwowany przez wszystkie zaufane urzędy certyfikacji. Dosłownie nie mogą wystawić dłuższego certyfikatu bez utraty statusu zaufanego CA. Pytanie nie zmieni tej odpowiedzi.

P: Czy zmiana dotyczy certyfikatów Extended Validation (EV) code signing?
O: Tak, ten sam limit 1 roku obowiązuje zarówno dla standardowych, jak i EV certyfikatów. Certyfikaty EV nadal wymagają rozszerzonej walidacji i zazwyczaj korzystają z tokenów sprzętowych, ale są również ograniczone do 398 dni.

P: Czy ceny certyfikatów wzrosną przez częstsze odnowienia?
O: Modele cenowe CA są różne. Niektóre dostosują ceny do rocznego cyklu, inne mogą oferować pakiety wieloletnie (kilka rocznych certyfikatów w cenie). Generalnie należy spodziewać się wyższych kosztów łącznych — to cena „poprawy bezpieczeństwa".

P: Co się stanie, jeśli zapomnę odnowić i certyfikat wygaśnie?
O: Jeśli używałeś timestampingu (naprawdę, używaj timestampingu), istniejące podpisane oprogramowanie działa nadal. Ale nie podpiszesz nowych wydań, dopóki nie uzyskasz nowego certyfikatu — co oznacza przestój produkcyjny, niezadowolonych użytkowników i trudne rozmowy z managementem.

Jak CrtMgr może pomóc

Kiedy żonglujesz certyfikatami SSL/TLS wygasającymi co 13 miesięcy i certyfikatami code signing wygasającymi co roku, scentralizowane zarządzanie certyfikatami przestaje być „miłym dodatkiem" — staje się koniecznością.

CrtMgr skupia się przede wszystkim na zarządzaniu certyfikatami SSL/TLS, ale wyzwania operacyjne są analogiczne: więcej certyfikatów, krótszy cykl życia, częstsze odnowienia i więcej okazji do przegapienia czegoś ważnego.

Dlaczego scentralizowane zarządzanie jest kluczowe przy krótszych ważnościach:

• Jedno źródło prawdy: Koniec z arkuszami kalkulacyjnymi, które są nieaktualne w momencie zapisania
• Automatyczne alerty: Powiadomienia 60, 30 i 7 dni przed wygaśnięciem — trafiające do właściwych osób, nie do współdzielonej skrzynki bez właściciela
• Ścieżki audytu: Dokumentacja każdego odnowienia, wygaśnięcia i incydentu do przeglądów zgodności
• Integracje: Połączenie z systemami monitoringu, alertów i ticketowania, aby zarządzanie certyfikatami stało się częścią normalnego workflow

Rzeczywistość jest prosta: im więcej certyfikatów zarządzasz i im częściej wygasają, tym bardziej potrzebujesz systemu, który śledzi je automatycznie. Ręczne śledzenie działało przy 3-letniej ważności. Przy rocznej — po prostu nie zadziała.

Zasoby i dalsza lektura

CA/Browser Forum Code Signing Working Group utrzymuje oficjalne standardy. Microsoft i Apple dostarczają kompletne przewodniki po dobrych praktykach code signing. NIST oferuje szczegółowe wytyczne dotyczące zarządzania kluczami, które mają bezpośrednie zastosowanie w scenariuszach code signing.

Zmiana z 3-letniej na 1-roczną ważność certyfikatów code signing to zmiana operacyjna, która przynosi przy okazji korzyści bezpieczeństwa. Argument bezpieczeństwa jest prawdziwy — krótsze okresy zmniejszają okno ekspozycji i wymuszają częstszą rotację kluczy. Ale dla większości zespołów praktyczny skutek to po prostu: więcej pracy, więcej koordynacji i więcej okazji do błędu, jeśli nie zautomatyzujesz procesu.

Organizacje, które przejdą przez tę zmianę bez zakłóceń, będą miały kilka wspólnych cech: zaczęły audyt certyfikatów z wyprzedzeniem, zautomatyzowały odnowienia przed deadline’em, wdrożyły właściwy timestamping (bez negocjacji) i zbudowały monitoring, który wychwytuje wygasające certyfikaty zanim staną się kryzysem.

Zacznij od audytu. Znajdź każdy certyfikat code signing w organizacji — włącznie z tymi, których nikt nie udokumentował. Następnie zbuduj kalendarz, zautomatyzuj co możliwe i udokumentuj kroki manualne dla reszty. Deadline marcowy jest stały. Poziom Twojego przygotowania — już nie.

Potrzebujesz pomocy przy zarządzaniu certyfikatami SSL/TLS? Sprawdź CrtMgr — automatyczne monitorowanie i zarządzanie cyklem życia certyfikatów.