Zmniejszona ważność certyfikatów Code Signing od 1 marca 2026

Od 1 marca 2026 czeka nas kolejny kamień milowy w zarządzaniu certyfikatami, który zmieni sposób, w jaki obsługujemy certyfikaty podpisu kodu. Jeśli odnawiałeś swoje certyfikaty co 2-3 lata, te czasy się kończą. Nowe maksimum? 1 rok (398 dni).

Tak, to oznacza więcej odnowień, więcej możliwości, że coś się zepsuje, i więcej przypomnień w kalendarzu, które prawdopodobnie zignorujesz, dopóki nie będzie za późno. Witaj w 2026 roku.

Co się zmienia?

Stan obecny (co zostawiamy za sobą)

• Maksymalna ważność: 3 lata (około 1095 dni)
• Powszechna praktyka: Kupujesz certyfikat i zapominasz o nim na 2-3 lata
• Częstotliwość odnowienia: Ten jeden raz, kiedy musiałeś panikować, gdy Twój certyfikat nieoczekiwanie wygasł

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, żaden CA nie wyda dłuższego
• Istniejące certyfikaty: Mogą pozostać ważne do wygaśnięcia (więc ten 3-letni certyfikat kupiony w 2025 jest bezpieczny)
• Termin: Obowiązkowe od 1 marca 2026
• Rzeczywisty wpływ: Będziesz odnawiać certyfikaty 3x częściej, co oznacza 3x więcej szans na zapomnienie, 3x więcej problemów z zamówieniami, 3x więcej bólów głowy przy wdrożeniu

Kogo to dotyczy?

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

• Deweloperzy oprogramowania podpisujący aplikacje, pliki wykonywalne, instalatory i wszystko, co musi przekonać Windows/macOS, że nie jest malware
• Zespoły DevOps zarządzające pipeline’ami CI/CD—przygotujcie się na aktualizację instrukcji rotacji certyfikatów
• Inżynierowie wydań którzy i tak już boją się odnowień certyfikatów podczas krytycznych okien wydawniczych
• Zespoły IT/Security odpowiedzialne za zarządzanie cyklem życia certyfikatów i radzenie sobie z incydentami wygasłych certyfikatów o 3 nad ranem
• Organizacje dystrybuujące podpisane oprogramowanie (aplikacje Windows, macOS, aplikacje mobilne, rozszerzenia przeglądarek)
• Producenci sprzętu podpisujący firmware i sterowniki—jeden wygasły certyfikat i cała linia produktów przestaje działać

Dobra wiadomość? Nie jesteś sam. Wszyscy przez to przechodzą.
Zła wiadomość? Będziesz przez to przechodzić co roku.

Dlaczego to się dzieje?

CA/Browser Forum (ludzie, którzy o tym decydują) nie robi tego, żeby Cię zdenerwować—chociaż na pewno tak to wygląda. Są uzasadnione powody bezpieczeństwa:

1. Wzmocnione bezpieczeństwo (teoria)

• Zmniejszone okno ekspozycji: Jeśli ktoś ukradnie Twój klucz prywatny, może go nadużywać tylko przez rok zamiast trzech
• Szybsza rotacja kluczy: Częstsze odnowienia = nowsze klucze kryptograficzne częściej
• Nowoczesne standardy kryptograficzne: Zmusza organizacje do przyjmowania silniejszych algorytmów zamiast trzymania się starych certyfikatów z przestarzałą kryptografią

2. Lepsza reakcja na incydenty (weryfikacja rzeczywistości)

• Szybsze odzyskiwanie: Gdy CA zostanie skompromitowany lub Twój klucz prywatny wycieknie, krótsza ważność oznacza mniejsze długoterminowe szkody
• Mniejsze wyzwania z odwołaniem: Czy kiedykolwiek próbowałeś odwołać 3-letni certyfikat, który jest osadzony w milionach zainstalowanych aplikacji? To koszmar
• Praktyczny wpływ: Spędzisz mniej czasu na wyjaśnianiu zarządowi, dlaczego ten skompromitowany certyfikat sprzed 2 lat wciąż jest problemem

3. Zgodność i dostosowanie do branży

• Dostosowanie do trendu: Certyfikaty SSL/TLS już przeszły przez ten ból—teraz kolej na podpis kodu
• Presja regulacyjna: Ramy bezpieczeństwa i wymagania zgodności coraz częściej wymagają krótszych okresów ważności certyfikatów
• Ścieżki audytu: Częstsze odnowienia = więcej dokumentacji dla auditora ISO 27001 do przejrzenia (nie ma za co)

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

Podpis kodu to nie jedyna dziedzina, w której obserwujemy skracanie okresu ważności certyfikatów. CA/Browser Forum stopniowo ogranicza okresy ważności certyfikatów SSL/TLS:

Harmonogram dla SSL/TLS

• Przed 2015: Certyfikaty ważne do 5 lat
• 2015-2018: Maksimum zredukowane do 3 lat (1095 dni)
• 2018-2020: Dalsze skrócenie do 2 lat (825 dni)
• Wrzesień 2020: Obecne maksimum 398 dni (13 miesięcy)
• Proponowane przyszłe 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 tylko biurokracja—krótsze okresy ważności oznaczają:

• Lepsze bezpieczeństwo: Skompromitowane certyfikaty mają mniejsze okno nadużycia
• Szybsza elastyczność kryptograficzna: Organizacje częściej przyjmują nowe algorytmy i rozmiary kluczy
• Większy narzut operacyjny: Częstsze odnowienia oznaczają więcej szans na błąd ludzki, zapomniane certyfikaty i awarie usług

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

Co musisz zrobić

Oto plan działania. Wykonaj go teraz, zanim będziesz gasić pożar wygasłego certyfikatu podczas krytycznego wydania.

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

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

# Sprawdź daty wygaśnięcia certyfikatów
# Windows (PowerShell)
Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object {$_.EnhancedKeyUsageList -match "Code Signing"}

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

Zadania do wykonania:

• Stwórz inwentaryzację wszystkich certyfikatów podpisu kodu (tak, łącznie z tym, który kupił zleceniobiorca 2 lata temu i nikt go nie udokumentował)
• Udokumentuj, które aplikacje/produkty używają każdego certyfikatu—uwierz mi, przyszły ty będzie wdzięczny
• Zidentyfikuj certyfikaty wygasające po 1 marca 2026
• Dowiedz się, kto faktycznie ma dostęp do odnowienia tych rzeczy (spoiler: to prawdopodobnie ktoś, kto odszedł z firmy)

2. Zaktualizuj proces odnowienia (zanim Cię ugryzie)

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

• Ustaw przypomnienia 60 dni przed wygaśnięciem (i 30 dni, i 7 dni, bo zignoru jesz pierwsze dwa)
• Zaplanuj roczny proces odnowienia zamiast „ustaw i zapomnij na 3 lata"
• Zaplanuj budżet na częstsze opłaty CA—finanse nie będą zadowolone
• Wyznacz osoby zastępcze do odnowień (bo główna osoba będzie na urlopie, gdy certyfikat wygaśnie)

Automatyzuj, gdzie to możliwe (albo zmierz się z konsekwencjami):

• Zintegruj monitorowanie certyfikatów z pipeline’em DevOps
• Ustaw alerty, które faktycznie powiadamiają właściwe osoby (a nie tylko współdzieloną skrzynkę, której nikt nie sprawdza)
• Rozważ użycie scentralizowanych narzędzi do zarządzania certyfikatami, takich jak CrtMgr, do śledzenia wszystkich certyfikatów w jednym miejscu—gdy zarządzasz dziesiątkami certyfikatów z rocznymi wygaśnięciami, arkusz kalkulacyjny nie wystarczy
• Przetestuj swój system powiadomień, zanim na nim polegasz

3. Przejrzyj swój pipeline CI/CD (to krytyczne)

Zaktualizuj procesy budowania i podpisywania:

• Upewnij się, że narzędzia CI/CD potrafią obsłużyć rotację certyfikatów bez zepsucia całego procesu budowania
• Udokumentuj procedury wymiany certyfikatów (krok po kroku, jakby wyjaśniał komuś, kto nigdy tego nie robił)
• Przetestuj aktualizacje certyfikatów w środowiskach testowych—nigdy nie testuj na produkcji
• Dodaj sprawdzanie wygaśnięcia certyfikatów do walidacji przed build’em
• Zaplanuj procedury wycofania, gdy coś pójdzie nie tak

Przykład aktualizacji workflow GitHub Actions:

- name: Sprawdź wygaśnięcie certyfikatu Code Signing
  run: |
    CERT_EXPIRY=$(security find-certificate -c "Twój Certyfikat Code Signing" -p | openssl x509 -noout -enddate)
    echo "Certyfikat wygasa: $CERT_EXPIRY"
    # Dodaj logikę ostrzegania jeśli wygasa w ciągu 60 dni
    # Jeszcze lepiej, przerwij build jeśli wygasa w ciągu 30 dni

Rzeczywiste względy:

• Aktualizacje certyfikatów podczas aktywnego development mogą blokować wydania
• Planuj okna odnowień podczas okresów niskiej aktywności
• Miej plan komunikacji na wypadek, gdy rotacja certyfikatów powoduje problemy
• Zachowaj dostęp do starych certyfikatów do weryfikacji historycznych podpisów

4. Wdróż timestamping (niezbywalne)

Krytyczne: Zawsze używaj timestampingu RFC 3161 podczas podpisywania kodu! To nie jest opcjonalne.

Oto dlaczego: Timestamping dowodzi, że Twój kod został podpisany, gdy certyfikat był ważny. Bez niego Twój podpis wygasa, gdy certyfikat wygasa. To oznacza:

• Twoje oprogramowanie zostaje zablokowane przez Windows SmartScreen
• macOS Gatekeeper odmawia jego uruchomienia
• Użytkownicy widzą przerażające komunikaty ostrzegawcze
• Twój zespół wsparcia zostaje zalany zgłoszeniami „ta aplikacja nie działa"
• Musisz ponownie podpisać i ponownie dystrybuować wszystko

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

Przykład użycia timestampingu:

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

# macOS (codesign z timestampem)
codesign -s "Developer ID Application" --timestamp aplikacja.app

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

Zalecane urzędy timestampingu:

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

Porady profesjonalistów:

• Zawsze weryfikuj, czy timestamping zadziałał po podpisaniu
• Używaj wielu serwerów timestamp jako backup (niektóre mają okazjonalne przestoje)
• Monitoruj dostępność serwera timestamp w swojej pipeline’ie build
• Jeśli timestamping się nie powiedzie, Twój build powinien się nie powieść—nie wysyłaj nieopieczętowanych czasowo binarek

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

Dla zwiększonego bezpieczeństwa (i żeby uszczęśliwić zespół security), rozważ użycie HSM lub usług podpisywania w chmurze:

• Korzyści: Klucze prywatne nigdy nie opuszczają HSM, scentralizowane podpisywanie, logowanie audytu, dostęp oparty na rolach
• Opcje chmurowe: Azure Key Vault, AWS CloudHSM, DigiCert ONE, Google Cloud HSM
• On-premise: Tokeny USB (jak YubiKey), sieciowe HSM (Thales, nCipher)
• Względy kosztowe: Droższe na początku, ale lepsze bezpieczeństwo i potencjalnie łatwiejsza rotacja kluczy

Weryfikacja rzeczywistości: Jeśli podpisujesz oprogramowanie, od którego zależy tysiące użytkowników, przechowywanie klucza prywatnego w pliku .pfx chronionym hasłem w zmiennej środowiskowej Jenkinsa to nie jest najlepsza postawa bezpieczeństwa.

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

• Zaktualizuj dokumentację wewnętrzną z nowymi okresami ważności certyfikatów i procedurami odnowienia
• Przeszkol deweloperów w zakresie nowych harmonogramów odnowień—upewnij się, że wiedzą, że to teraz roczne
• Zakomunikuj zmiany zainteresowanym stronom, które zatwierdzają zakupy certyfikatów (zamówienia, finanse, zespół bezpieczeństwa)
• Udokumentuj promień rażenia: Co się psuje, gdy certyfikat wygasa? Kogo trzeba powiadomić? Jaka jest procedura awaryjna?
• Stwórz runbook’i: Przewodniki krok po kroku zarówno dla planowanych odnowień, jak i awaryjnych scenariuszy „o cholera, certyfikat wygasł"

Harmonogram przejścia

Najczęściej zadawane pytania

P: Czy muszę wymienić mój obecny 3-letni certyfikat?
O: Nie, istniejące certyfikaty mogą pozostać ważne do daty wygaśnięcia. Nowy limit dotyczy tylko certyfikatów wydanych w dniu 1 marca 2026 lub później. Więc jeśli kupiłeś 3-letni certyfikat w lutym 2026, gratulacje—masz czas do 2029.

P: Czy to wpłynie na moje już podpisane oprogramowanie?
O: Jeśli użyłeś timestampingu (użyłeś, prawda?), twoje już podpisane oprogramowanie będzie działać w nieskończoność. Jeśli nie użyłeś timestampingu, podpisy wygasają wraz z certyfikatem i będziesz musiał wszystko ponownie podpisać. Dlatego timestamping jest krytyczny.

P: Czy mogę uzyskać dłuższy okres ważności od mojego CA?
O: Nie, to jest standard branżowy egzekwowany przez wszystkie zaufane urzędy certyfikacji. Dosłownie nie mogą wydać dłuższych certyfikatów bez utraty zaufanego statusu. Pytanie nie pomoże.

P: Jak to wpływa na certyfikaty Extended Validation (EV) code signing?
O: Ten sam limit 1 roku dotyczy zarówno standardowych, jak i EV certyfikatów podpisu kodu. Certyfikaty EV nadal wymagają dodatkowej walidacji i zazwyczaj używają tokenów sprzętowych, ale również są ograniczone do 398 dni.

P: Czy ceny certyfikatów wzrosną z powodu częstszych odnowień?
O: Modele cenowe CA są różne. Niektóre mogą dostosować ceny, aby odzwierciedlić roczne zakupy, podczas gdy inne mogą oferować pakiety wieloletnie, w których kupujesz wiele rocznych certyfikatów ze zniżką. Spodziewaj się, że zapłacisz więcej ogółem—to koszt „zwiększonego bezpieczeństwa".

P: Co się stanie, jeśli zapomnę odnowić i mój certyfikat wygaśnie?
O: Jeśli używałeś timestampingu (serio, używaj timestampingu), twoje istniejące podpisane oprogramowanie nadal działa. Ale nie możesz podpisywać nowych wydań, dopóki nie otrzymasz nowego certyfikatu. To oznacza zakłócenia w produkcji, wściekłych użytkowników i niezręczne rozmowy z menedżerem o tym, dlaczego wydanie jest zablokowane.

Jak CrtMgr może pomóc

Gdy żonglujesz certyfikatami SSL/TLS, które wygasają co 13 miesięcy, i certyfikatami podpisu kodu, które również wygasają co roku, scentralizowane zarządzanie certyfikatami przestaje być „miłą rzeczą" i staje się niezbędne.

Chociaż CrtMgr koncentruje się głównie na zarządzaniu certyfikatami SSL/TLS, wyzwania operacyjne są podobne: więcej certyfikatów, krótsze okresy życia, częstsze odnowienia i więcej możliwości, że coś prześlizgnie się przez pęknięcia.

Dlaczego scentralizowane zarządzanie ma znaczenie przy krótszych okresach ważności:

• Pojedyncze źródło prawdy: Przestań utrzymywać arkusze kalkulacyjne, które są nieaktualne w momencie, gdy je zapisujesz
• Automatyczne alerty: Otrzymuj powiadomienia 60, 30 i 7 dni przed wygaśnięciem—wysyłane do właściwych osób, a nie zakopane we współdzielonej skrzynce
• Ścieżki audytu: Dokumentuj każde odnowienie, każde wygaśnięcie, każdy incydent dla przeglądów zgodności
• Integracja: Połącz się ze swoimi systemami monitorowania, powiadamiania i ticketowania, aby zarządzanie certyfikatami stało się częścią normalnego przepływu pracy

Rzeczywistość jest prosta: im więcej certyfikatów zarządzasz i im częściej wygasają, tym bardziej krytyczne staje się posiadanie systemu, który śledzi je automatycznie. Ręczne śledzenie działało, gdy certyfikaty trwały 3 lata. Nie będzie działać, gdy trwają 1 rok.

Zasoby i dalsze czytanie

• CA/Browser Forum Code Signing Working Group
• Microsoft Code Signing Best Practices
• Apple Code Signing Guide
• NIST Guidelines on Key Management

Redukcja okresu ważności certyfikatów podpisu kodu z 3 lat do 1 roku to znacząca zmiana operacyjna przebrana za ulepszenie bezpieczeństwa. Krótsze okresy życia poprawiają bezpieczeństwo, ale oznaczają więcej pracy, koordynacji, szans na błąd ludzki i potencjalnych zakłóceń.

Organizacje, które odniosą sukces:

• Zaczynają przygotowania teraz zamiast czekać do marca 2026
• Automatyzują wszystko co możliwe aby zmniejszyć błędy
• Dokumentują procedury aby każdy w zespole mógł obsłużyć odnowienia
• Wdrażają właściwy monitoring aby wychwycić wygasające certyfikaty przed awarią
• Zawsze używają timestampingu aby uniknąć ponownego podpisywania

Lista działań: przeprowadź audyt obecnych certyfikatów, zaktualizuj procesy i kalendarze na roczne odnowienia, wdróż lub zweryfikuj timestamping (krytyczne!), przejrzyj pipeline’y CI/CD dla rotacji certyfikatów, udokumentuj nowe procedury i przeszkol zespół, rozważ narzędzia jak CrtMgr do śledzenia wszystkiego.

Kluczem do sukcesu jest przygotowanie i automatyzacja. Organizacje które proaktywnie dostosują praktyki zarządzania, doświadczą minimalnych zakłóceń. Te które tego nie zrobią? Będą ponownie uczyć się znaczenia timestampingu o 2 nad ranem podczas krytycznego wydania.

Potrzebujesz pomocy w zarządzaniu certyfikatów SSL/TLS? Sprawdź CrtMgr dla automatycznego monitorowania i zarządzania cyklem życia.