Zmiany w publicznym PKI zazwyczaj są dla większości organizacji niemal niewidoczne. Certyfikaty root rotują się powoli, certyfikaty pośrednie pojawiają się i znikają, a infrastruktura TLS po prostu działa. Tym razem sytuacja wygląda inaczej. Komunikat opublikowany przez DigiCert nie dotyczy wyłącznie nowych hierarchii CA ani standardowej migracji infrastruktury. Dotyczy samego modelu zaufania, na którym przez lata opierało się WebPKI.

To ważne rozróżnienie.

Przez ostatnią dekadę publiczny ekosystem certyfikatów funkcjonował w modelu, który można określić jako „adaptacyjny”. Klient TLS nie oczekiwał jednej, sztywno określonej ścieżki walidacji. Wystarczyło, że był w stanie odnaleźć dowolną poprawną drogę prowadzącą do zaufanego root CA. Cross-signing, współdzielone certyfikaty pośrednie oraz szerokie EKU sprawiały, że infrastruktura była niezwykle tolerancyjna na różnice pomiędzy środowiskami.

Dla operatorów oznaczało to jedną rzecz: nawet jeśli konfiguracja nie była idealna, TLS zazwyczaj nadal działał. DigiCert właśnie zamyka ten etap.

Co dokładnie ogłosił DigiCert?

DigiCert poinformował o przejściu z multipurpose PKI do dedykowanych hierarchii TLS zgodnych z wymaganiami programu Google Chrome Root Program. W praktyce oznacza to odejście od modelu, w którym ten sam element infrastruktury zaufania mógł obsługiwać jednocześnie TLS, S/MIME oraz Code Signing. Nowe hierarchie TLS mają być:

• jednoznaczne,
• ograniczone wyłącznie do server authentication,
• pozbawione mechanizmów typu cross-signing,
• interpretowane identycznie niezależnie od środowiska klienta.

To fundamentalna zmiana filozofii działania WebPKI.

Jak działało WebPKI przez lata?

Żeby zrozumieć znaczenie tej zmiany, trzeba spojrzeć na to, jak naprawdę działała walidacja certyfikatów. Formalnie klient TLS otrzymuje chain od serwera i próbuje zbudować ścieżkę prowadzącą do zaufanego roota. W praktyce oznaczało to jednak coś znacznie bardziej elastycznego: klient nie był ograniczony do jednej ścieżki.

Jeżeli serwer prezentował chain:

Leaf → DigiCert TLS RSA SHA256 2020 CA1 → DigiCert Global Root CA

ale klient posiadał w trust store inny wariant certyfikatu pośredniego lub cross-signed root, nadal był w stanie zakończyć walidację sukcesem.

W wielu środowiskach dokładnie ten sam certyfikat był interpretowany alternatywnie:

Leaf → DigiCert SHA2 Secure Server CA → DigiCert Global Root CA (cross-signed)

To nie był wyjątek ani obejście. To był świadomie zaprojektowany mechanizm kompatybilności. Cross-signing rozwiązywał bardzo konkretny problem: fragmentację trust store pomiędzy systemami operacyjnymi, przeglądarkami, appliance’ami oraz bibliotekami TLS. Dzięki temu:

• starsze systemy nadal ufały nowym certyfikatom,
• organizacje mogły wolniej aktualizować infrastrukturę,
• operatorzy rzadziej odczuwali skutki zmian po stronie CA.

Z perspektywy użytkownika WebPKI wydawało się stabilne. W rzeczywistości było po prostu bardzo tolerancyjne.

Dlaczego ten model przestał być akceptowalny?

Problem multipurpose PKI nie polegał na tym, że nie działało. Problem polegał na tym, że współdzielone hierarchie rozszerzały zakres zaufania w sposób trudny do kontrolowania. Jeżeli jeden certyfikat pośredni CA może obsługiwać jednocześnie:

• certyfikaty TLS,
• podpisywanie kodu,
• uwierzytelnianie klienta,
• certyfikaty e-mailowe,

to jego kompromitacja wpływa na wiele różnych obszarów infrastruktury jednocześnie. To właśnie ten model zaczęły eliminować programy root store. Najlepiej pokazuje to zestawienie starego i nowego podejścia:

W praktyce WebPKI przechodzi z modelu elastycznego do modelu restrykcyjnego.

Koniec „dopasowywania” chaina.

To właśnie tutaj pojawia się najważniejsza zmiana operacyjna. W starym modelu klient TLS próbował znaleźć poprawną ścieżkę walidacji. W nowym modelu klient oczekuje jednej, konkretnej ścieżki.

Nowy chain DigiCert wygląda znacznie bardziej jednoznacznie:

Leaf → DigiCert TLS RSA4096 SHA256 2026 CA1 → DigiCert TLS Root G5

Nie ma alternatywnych ścieżek. Nie ma fallbacków. Nie ma cross-signed rootów, które „uratowałyby” starsze środowisko. Jeżeli klient nie posiada odpowiedniego roota albo oczekuje innej ścieżki walidacji, proces kończy się błędem. I właśnie dlatego organizacje zaczną obserwować sytuacje, które na pierwszy rzut oka wydają się nielogiczne:

• certyfikat jest ważny,
• podpis jest poprawny,
• chain wygląda prawidłowo,
• a mimo to klient odrzuca połączenie.

Źródłem problemu nie jest sam certyfikat. Źródłem problemu jest niezgodność pomiędzy oczekiwanym a rzeczywistym modelem zaufania.

Dlaczego najbardziej ucierpią starsze środowiska?

Nowe wdrożenia zazwyczaj nie będą miały problemu z nowymi hierarchiami. Problemy pojawią się w istniejących środowiskach, które przez lata polegały na kompatybilności zapewnianej przez cross-signing. Wyobraźmy sobie appliance bezpieczeństwa lub load balancer wykorzystujący własny CA bundle aktualizowany raz na kilka lat. Do tej pory takie środowisko nadal było w stanie zweryfikować certyfikat DigiCert, ponieważ klient potrafił odnaleźć alternatywną ścieżkę prowadzącą do starszego roota. Po przejściu na nowe hierarchie TLS ten mechanizm przestaje istnieć.

Efekt może wyglądać następująco:

verify error:num=20:unable to get local issuer certificate

To jeden z bardziej mylących błędów TLS, bo certyfikat jest poprawny, chain jest poprawny, CA jest zaufane. Problem polega wyłącznie na tym, że klient nie posiada dokładnie tego elementu infrastruktury zaufania, którego oczekuje nowy model.

EKU zmienia rolę publicznego TLS.

Jednym z najbardziej niedocenianych aspektów tej zmiany jest ograniczenie Extended Key Usage. W starszych hierarchiach certyfikatów pośrednich CA bardzo często zawierały zarówno:

TLS Web Server Authentication
TLS Web Client Authentication

To umożliwiało wykorzystanie publicznych certyfikatów TLS w scenariuszach mTLS oraz client authentication.

W nowych hierarchiach DigiCert pozostawia wyłącznie:

TLS Web Server Authentication

Ta zmiana wygląda niepozornie, ale w praktyce redefiniuje rolę publicznego WebPKI.

Publiczny TLS przestaje być uniwersalnym mechanizmem zaufania. Staje się wyspecjalizowanym systemem służącym wyłącznie do uwierzytelniania serwera.

Dlaczego to zmienia sposób zarządzania certyfikatami?

Przez lata wiele organizacji traktowało chain jako coś relatywnie statycznego. Rooty zmieniały się bardzo wolno, certyfikaty pośrednie żyły latami, trust store aktualizowano sporadycznie. Nowy model działa inaczej. Hierarchie TLS stają się:

• bardziej wyspecjalizowane,
• krócej żyjące,
• bardziej restrykcyjne,
• mniej tolerancyjne na błędy.

W połączeniu ze skracaniem ważności certyfikatów prowadzi to do bardzo istotnej zmiany operacyjnej: TLS przestaje być konfiguracją, TLS staje się procesem.

To oznacza konieczność:

To właśnie dlatego zmiana DigiCert ma znaczenie znacznie wykraczające poza same certyfikaty. Dotyczy sposobu utrzymania całej infrastruktury TLS.

WebPKI przestaje być systemem „kompatybilnym”.

Najważniejszą konsekwencją tej zmiany jest odejście od modelu WebPKI, którego głównym celem przez lata było utrzymywanie możliwie szerokiej kompatybilności pomiędzy różnymi środowiskami i implementacjami TLS, nawet kosztem niejednoznaczności w interpretacji łańcucha zaufania. Nowe podejście działa odwrotnie: priorytetem staje się jednoznaczność i przewidywalność walidacji. Mechanizmy takie jak cross-signing są eliminowane, multipurpose hierarchie znikają, a zakres EKU zostaje ograniczony wyłącznie do jasno określonych zastosowań. W praktyce klient TLS przestaje „interpretować” chain i wybierać jedną z możliwych ścieżek walidacji, a zaczyna sprawdzać zgodność z precyzyjnie zdefiniowanym modelem zaufania. Dla operatorów oznacza to koniec sytuacji, w której infrastruktura działa poprawnie mimo częściowych niezgodności lub nieaktualnych komponentów trust store.
W nowym modelu:

• chain musi być poprawny,
• trust store musi być aktualny,
• ścieżka walidacji musi być jednoznaczna,
• środowisko klienta musi rozumieć nową hierarchię.

To subtelna zmiana semantyczna. Ale właśnie ona definiuje nową generację WebPKI.

Źródło: DigiCert Knowledge Base – Transitioning Multipurpose PKI Hierarchies to Dedicated TLS Root Hierarchies