Przez lata Client Authentication (mTLS) było realizowane w oparciu o publiczne certyfikaty SSL/TLS, wystawiane przez powszechnie zaufane urzędy certyfikacji. Model ten działał, ponieważ certyfikaty serwerowe mogły zawierać jednocześnie Server Authentication oraz Client Authentication (EKU), a przeglądarki i systemy operacyjne akceptowały taki dualny scenariusz.

Ten model właśnie dobiega końca.

Zgodnie z nowymi zasadami programów root (w szczególności Chrome Root Program), publiczne TLS ma służyć wyłącznie do uwierzytelniania serwerów, a nie klientów. W efekcie najwięksi dostawcy certyfikatów publicznych rozpoczęli proces wygaszania obsługi Client Authentication w certyfikatach publicznych.

Dla wielu organizacji oznacza to realne ryzyko cichego zerwania mTLS podczas automatycznych odnowień certyfikatów.

Co dokładnie się zmienia?

Harmonogram zmian u głównych dostawców.

DigiCert

• Client Authentication EKU nie jest już domyślnie dodawany do nowych certyfikatów publicznych.
• Opcja jego włączenia zostanie całkowicie usunięta 1 maja 2026 r.
• Po tej dacie certyfikaty DigiCert Public TLS będą obsługiwać wyłącznie Server Authentication.

Sectigo

• Sectigo wygasza Client Authentication w publicznych certyfikatach TLS.
• Ostateczny termin: 15 maja 2026 r.
• Po tej dacie reissuance lub nowe wydania nie będą mogły zawierać Client EKU.

Zmiany te nie są inicjatywą pojedynczych CA, lecz bezpośrednią konsekwencją polityk programów root, w tym wymagań przeglądarek.

Dlaczego to jest problem operacyjny, a nie tylko formalny?

W wielu środowiskach mTLS oparty o publiczne certyfikaty działa „od lat” i nie był nigdy ponownie projektowany. Typowe przykłady:

• VPN-y B2B i site-to-site.
• API Gateways i integracje partnerskie.
• SIP, VoIP, Unified Communications.
• Edge security, reverse proxy, ingress controllers.
• Starsze integracje M2M, gdzie certyfikat = tożsamość.

W takich scenariuszach odnowienie certyfikatu bez Client EKU powoduje:

• brak możliwości zestawienia połączenia,
• błędy uwierzytelniania po stronie klienta,
• trudne do zdiagnozowania incydenty po wygaśnięciu starego certyfikatu.

Co istotne, zmiana może nastąpić „po cichu”, jeżeli proces odnowień jest w pełni zautomatyzowany.

Krótkoterminowe opcje ratunkowe (do 2026).

Reissuance przed datą graniczną.

Jeżeli obecnie korzystasz z publicznego TLS do Client Authentication, masz ograniczone okno czasowe.

DigiCert

• Podczas zamówienia lub ponownego wydania certyfikatu można jeszcze jawnie włączyć Client Authentication EKU.
• Certyfikat zachowa funkcjonalność nawet do roku po wystawieniu.
• Jest to rozwiązanie tymczasowe, nie strategiczne.

Sectigo

• Certyfikaty wystawione przez Sectigo zawierają Client Authentication (dla zamówień od listopada 2025).
• Jeśli certyfikat został wydany bez EKU, należy wykonać reissuance przed 15 maja 2026 r.

Należy jednak jasno podkreślić: to jedynie odroczenie problemu, a nie jego rozwiązanie.

Rozwiązania długoterminowe (future-proof).

Ruch między organizacjami: X9 PKI.

Dla środowisk B2B, finansowych i regulowanych właściwym kierunkiem jest PKI poza programami przeglądarek.

DigiCert X9 PKI for TLS

• Opiera się na ASC X9 Certificate Policy, a nie na politykach browser root.
• Obsługuje zarówno Server Authentication, jak i Client Authentication.
• Zaprojektowany do scenariuszy:
  • cross-organization,
  • mTLS,
  • integracji systemów krytycznych.

Systemy wewnętrzne: Private CA / Managed PKI.

Dla środowisk wewnętrznych i hybrydowych:

• własne CA,
• Managed Private CA (PKI as a Service),
• pełna kontrola nad EKU, politykami i cyklem życia certyfikatów.

To obecnie rekomendowany model dla:

• Kubernetes,
• microservices,
• Zero Trust,
• service-to-service authentication.

Widoczność i automatyzacja: klucz do bezpieczeństwa.

Niezależnie od wybranego modelu, krytyczne znaczenie ma widoczność certyfikatów. Narzędzia takie jak DigiCert Trust Lifecycle Manager pozwalają:

• wykryć wszystkie certyfikaty używane do Client Auth,
• zidentyfikować zależności,
• zaplanować migrację,
• zautomatyzować odnowienia i rotację kluczy.

Brak inwentaryzacji certyfikatów jest dziś jednym z najczęstszych źródeł incydentów operacyjnych.

Zalecany plan działania (checklista).

1. Zidentyfikuj wszystkie miejsca użycia Client Authentication:
   • VPN, API, SIP, UC, reverse proxy, edge.
2. Zabezpiecz ciągłość krótkoterminową:
   • reissuance certyfikatów przed datami granicznymi.
3. Wybierz model docelowy:
   • X9 PKI dla ruchu między organizacjami.
   • Private CA dla systemów wewnętrznych.
4. Zaktualizuj trust store:
   • nowe root i intermediate CA.
5. Uruchom discovery i automatyzację:
   • monitoring, alerting, lifecycle management.

Wygaszenie Client Authentication w publicznych certyfikatach SSL/TLS nie jest chwilową zmianą polityki, lecz trwałą transformacją modelu zaufania w Internecie. Organizacje, które nadal opierają mTLS o publiczne SSL, muszą podjąć decyzje architektoniczne w 2026, aby uniknąć przestojów i incydentów bezpieczeństwa.

Ze swojej strony rekomendujemy traktować ten moment jako okazję do uporządkowania PKI, poprawy widoczności i wdrożenia nowoczesnego modelu zaufania, zamiast kolejnego tymczasowego obejścia.

Jeżeli potrzebujesz wsparcia w audycie, migracji lub wyborze właściwego modelu PKI – nasz zespół pozostaje do dyspozycji.