Przejdź do głównej treści
Certyfikaty SSL klasy Premium od Platinum Partnera DigiCert
DigiCert Trust Lifecycle Manager od SSL24.pl - Platinum Partnera DigiCert

X9 PKI - czym są certyfikaty X9, do czego służą i kiedy warto je stosować?

     
Ocena: 5,00/5,00

Certyfikaty X9 PKI są przeznaczone przede wszystkim do uwierzytelniania systemów, aplikacji, usług i urządzeń w środowiskach, w których klasyczna publiczna Web PKI nie jest odpowiednim modelem zaufania. Szczególne znaczenie mają w komunikacji machine-to-machine (M2M), zabezpieczaniu API, komunikacji server-to-server oraz w modelu mutual TLS (mTLS), gdzie certyfikaty służą nie tylko do uwierzytelniania serwera, ale również klienta.

X9 PKI działa niezależnie od programów zaufania przeglądarek i CA/B Forum. Wykorzystuje własną politykę certyfikacyjną oraz wspólny root of trust, dzięki któremu może zapewnić interoperacyjność pomiędzy organizacjami korzystającymi z tej infrastruktury. Ma to coraz większe znaczenie w związku z wycofywaniem Client Authentication EKU z publicznie zaufanych certyfikatów TLS.

Od 1 października 2025 r. DigiCert domyślnie wydaje publiczne certyfikaty TLS wyłącznie z Server Authentication EKU. Client Authentication można jeszcze wybrać podczas zamawiania, jednak od 1 marca 2027 r. DigiCert całkowicie przestanie wydawać nowe publiczne certyfikaty TLS zawierające Client Authentication EKU. Dla organizacji wykorzystujących publiczne certyfikaty TLS do mTLS, komunikacji system-system lub uwierzytelniania urządzeń oznacza to konieczność wyboru innego modelu certyfikacji.

Jednym z takich rozwiązań jest X9 PKI for TLS.

W skrócie: X9 PKI to niezależna od przeglądarek infrastruktura PKI przeznaczona przede wszystkim do komunikacji system-system, mTLS, API i uwierzytelniania urządzeń. W przeciwieństwie do publicznej Web PKI X9 może wydawać certyfikaty z Client Authentication EKU. Ma to szczególne znaczenie w związku z wycofaniem Client Authentication z publicznych certyfikatów TLS DigiCert od 1 marca 2027 r.

Czym jest X9 PKI?

X9 Financial PKI to infrastruktura klucza publicznego opracowana z myślą o środowiskach wymagających interoperacyjnego modelu zaufania poza klasyczną Web PKI. Za jej politykę i zasady funkcjonowania odpowiada Accredited Standards Committee X9 (ASC X9), amerykańska organizacja akredytowana przez ANSI, od ponad 50 lat zajmująca się opracowywaniem standardów dla sektora finansowego.

Potrzeba utworzenia dedykowanej infrastruktury PKI została zgłoszona przez przedstawicieli amerykańskiego sektora finansowego w 2018 roku. Po kilkuletnich pracach ASC X9 opracował zasady X9 Financial PKI i wybrał DigiCert jako partnera technologicznego odpowiedzialnego za dostarczanie rozwiązań certyfikacyjnych działających w ramach tej infrastruktury. Chociaż X9 PKI powstało przede wszystkim w odpowiedzi na potrzeby sektora finansowego, DigiCert udostępnia je również organizacjom z innych branż.

Kluczowe jest nie to, do jakiej branży należy organizacja, lecz do czego certyfikat będzie wykorzystywany.

Dlaczego X9 PKI staje się szczególnie ważne?

Przez wiele lat publiczne certyfikaty SSL/TLS były wykorzystywane nie tylko do HTTPS, ale także do uwierzytelniania klientów. Typowy certyfikat mógł zawierać jednocześnie:

  • Server Authentication EKU – pozwalające uwierzytelniać serwer,
  • Client Authentication EKU – pozwalające uwierzytelniać klienta.

Takie certyfikaty były często stosowane w:

  • mutual TLS,
  • integracjach API,
  • komunikacji serwer-serwer,
  • systemach finansowych,
  • komunikacji M2M,
  • uwierzytelnianiu urządzeń.

Model publicznej Web PKI zmienia się jednak w kierunku jednoznacznego rozdzielenia zastosowań certyfikatów. Wymagania Chrome Root Program prowadzą do usunięcia Client Authentication EKU z nowo wydawanych publicznie zaufanych certyfikatów TLS.
DigiCert realizuje tę zmianę w dwóch etapach.

Od 1 października 2025 r.

Publiczne certyfikaty TLS DigiCert są domyślnie wydawane wyłącznie z:

  • Server Authentication EKU

Do 1 marca 2027 r. podczas zamawiania można jednak nadal jawnie wybrać certyfikat zawierający:

  • Server Authentication + Client Authentication

Od 1 marca 2027 r.

DigiCert zakończy możliwość umieszczania Client Authentication EKU w nowych publicznych certyfikatach TLS. Dotyczy to również odnowień, ponownych wystawień i duplikatów. Organizacje wykorzystujące Client Authentication muszą więc odpowiednio wcześniej przeanalizować swoją infrastrukturę.
DigiCert wskazuje dwa podstawowe kierunki migracji:

  • X9 PKI for TLS – szczególnie gdy komunikacja odbywa się pomiędzy wieloma organizacjami,
  • Private PKI – gdy certyfikaty są wykorzystywane wyłącznie wewnątrz jednej organizacji.

X9 PKI a Web PKI

X9 PKI i publiczna Web PKI wykorzystują certyfikaty X.509 oraz te same podstawowe mechanizmy kryptograficzne, ale działają w różnych modelach zaufania:

Web PKI X9 PKI
Przeznaczona przede wszystkim do publicznych stron i aplikacji WWW Przeznaczona głównie do komunikacji non-browser
Root CA znajduje się w publicznych programach zaufania przeglądarek i systemów Wykorzystuje odrębną hierarchię X9
Podlega wymaganiom programów root i CA/B Forum Podlega polityce X9 PKI
Publiczny TLS zmierza do Server Authentication only Możliwe Server Auth, Client Auth lub oba EKU
Typowy przypadek: HTTPS Typowe przypadki: mTLS, API, M2M, server-to-server

Nie oznacza to, że X9 jest „lepszym SSL”. Są to rozwiązania przeznaczone do innych modeli zastosowania.

Czym jest Extended Key Usage?

Extended Key Usage (EKU) jest rozszerzeniem certyfikatu X.509 określającym, do jakiego rodzaju uwierzytelniania może być wykorzystywany dany certyfikat.
W przypadku TLS szczególne znaczenie mają dwa EKU.

Server Authentication

Server Authentication pozwala wykorzystywać certyfikat do uwierzytelniania serwera.
Typowy model wygląda następująco:

Klient-Serwer (Server authentication)

Klient weryfikuje certyfikat serwera, jego łańcuch certyfikacji, nazwę, okres ważności i inne wymagane parametry. Tak działa m.in. klasyczne HTTPS.

Client Authentication

Client Authentication służy do uwierzytelniania klienta wobec serwera.

Klient-Serwer (Client authentication)

Klientem nie musi być człowiek. Może nim być:

  • aplikacja,
  • serwer,
  • mikroserwis,
  • urządzenie,
  • API gateway,
  • terminal,
  • system integracyjny.

Certyfikat stanowi wtedy kryptograficzny dowód tożsamości systemu próbującego nawiązać komunikację.

X9 PKI i mutual TLS

Jednym z najważniejszych zastosowań X9 PKI jest mutual TLS (mTLS). W klasycznym TLS zazwyczaj uwierzytelniany jest wyłącznie serwer:

Klient-Serwer (uwierzytelnienie serwera w klasycznym TLS)

W mutual TLS certyfikat przedstawiają obie strony:

Klient-Serwer (uwierzytelnienie klienta w mTLS)

Serwer-Klient (uwierzytelnienie serwera w mTLS)

Przykładowy proces wygląda następująco:

  1. System A nawiązuje połączenie TLS z systemem B.
  2. System B przedstawia certyfikat serwera.
  3. System A weryfikuje tożsamość systemu B.
  4. System B żąda przedstawienia certyfikatu klienta.
  5. System A przedstawia własny certyfikat.
  6. System B weryfikuje certyfikat systemu A.
  7. Komunikacja jest kontynuowana tylko wtedy, gdy obie strony spełnią wymagania polityki zaufania.

Pozwala to ograniczyć dostęp do usługi nie tylko na podstawie hasła, tokenu lub adresu IP, ale również na podstawie kryptograficznie potwierdzonej tożsamości klienta.

Do czego można wykorzystać X9 PKI?

Mutual TLS

X9 PKI może służyć do wzajemnego uwierzytelniania systemów należących do jednej lub wielu organizacji.

API

Certyfikat klienta może być wykorzystywany przez API gateway lub serwer aplikacyjny do identyfikowania systemu wywołującego API. mTLS nie musi zastępować OAuth, JWT czy innych mechanizmów autoryzacji.
Często stanowi dodatkową warstwę zabezpieczenia:

mTLS + OAuth / token + kontrola uprawnień
Każdy mechanizm odpowiada wtedy za inny element bezpieczeństwa.

Server-to-server

X9 może być wykorzystywane w komunikacji pomiędzy systemami należącymi do niezależnych organizacji.
Przykładowo:

Organizacja-Organizacja (uwierzytelnienie mTLS z certyfikatem X9)

Wspólny model zaufania eliminuje konieczność budowania osobnej relacji pomiędzy prywatnymi CA każdego uczestnika.

Uwierzytelnianie urządzeń

Certyfikat może identyfikować konkretne urządzenie lub grupę urządzeń.
Może być to np.:

  • terminal,
  • urządzenie przemysłowe,
  • element infrastruktury sieciowej,
  • urządzenie IoT,
  • system płatniczy.

Systemy finansowe

X9 PKI zostało zaprojektowane przede wszystkim z myślą o sektorze finansowym.
DigiCert wskazuje m.in.:

  • systemy płatnicze,
  • komunikację międzybankową,
  • ATM i POS,
  • API,
  • infrastrukturę partnerów,
  • komunikację host-to-host.

X9 nie jest jednak ograniczone wyłącznie do banków.

Jakie EKU może mieć certyfikat X9 PKI for TLS?

DigiCert umożliwia skonfigurowanie jednego z trzech profili.

Server Authentication

Certyfikat służy do uwierzytelniania serwera TLS.

Client Authentication

Certyfikat służy wyłącznie do uwierzytelniania klienta.
Może być zainstalowany np. na:

  • serwerze aplikacyjnym,
  • urządzeniu,
  • mikroserwisie,
  • API gateway,
  • systemie integracyjnym.

Server Authentication + Client Authentication

Jeden certyfikat może zawierać oba EKU. Jest to przydatne wtedy, gdy dany system występuje w zależności od połączenia zarówno jako serwer, jak i klient TLS. Nie oznacza to jednak, że używanie jednego certyfikatu w obu rolach zawsze jest najlepszym rozwiązaniem.
W wielu architekturach warto rozdzielić certyfikaty:

  • Certyfikat serwera - Server Authentication

Certyfikat serwera (Server authentication)

 

  • Certyfikat klienta - Client Authentication

Certyfikat klienta (Client authentication)

Takie podejście może ułatwić kontrolę uprawnień, rotację certyfikatów, audyt i stosowanie zasady najmniejszych uprawnień.

X9 PKI a publiczna strona WWW

X9 PKI for TLS może zawierać Server Authentication EKU i technicznie uwierzytelniać serwer TLS. Nie należy jednak traktować go jako zamiennika publicznie zaufanego certyfikatu SSL/TLS dla ogólnodostępnej strony internetowej. X9 wykorzystuje odrębną hierarchię zaufania, niezależną od publicznej Web PKI. Dla typowej witryny: https://www.twojadomena.pl należy więc nadal stosować publicznie zaufany certyfikat Web PKI.
X9 jest przeznaczone przede wszystkim do:

System-System (uwierzytelnienie mTLS z certyfikatem X9)

czyli komunikacji, w której obie strony mogą świadomie skonfigurować odpowiedni model zaufania.

Konfiguracja zaufania ma kluczowe znaczenie

Sam fakt posiadania certyfikatu X9 nie powoduje automatycznie, że dowolny system będzie mu ufał. Systemy uczestniczące w komunikacji muszą posiadać odpowiednią konfigurację zaufania do hierarchii X9.
Należy więc sprawdzić m.in.:

  • trust store systemu operacyjnego,
  • trust store aplikacji,
  • konfigurację serwera TLS,
  • wymagany łańcuch certyfikacji,
  • konfigurację pośrednich CA,
  • sposób sprawdzania unieważnienia certyfikatów.

Jest to jedna z istotnych różnic w stosunku do publicznej Web PKI, gdzie odpowiednie root CA są zazwyczaj już dostarczane przez system operacyjny lub przeglądarkę.

X9 PKI a Private PKI

Wybór pomiędzy X9 PKI a Private PKI zależy przede wszystkim od granic środowiska zaufania.

Private PKI

Prywatne PKI sprawdza się szczególnie dobrze wtedy, gdy wszystkie systemy znajdują się pod kontrolą jednej organizacji.

Private PKI wewnątrz organizacji

Organizacja sama decyduje wtedy o:

  • polityce wydawania,
  • cyklu życia certyfikatów,
  • okresach ważności,
  • zaufanych CA,
  • sposobie dystrybucji root CA.

X9 PKI

X9 staje się interesujące, gdy w komunikacji bierze udział wiele niezależnych podmiotów:

 Wspólny model zaufania między różnymi organizacjami

Zamiast tworzenia wielu bilateralnych relacji pomiędzy prywatnymi CA uczestnicy mogą korzystać ze wspólnej hierarchii X9.

Parametry techniczne X9 PKI for TLS

Aktualne X9 PKI for TLS DigiCert obsługuje:

Algorytmy RSA

  • RSA 2048
  • RSA 3072
  • RSA 4096

Algorytmy ECC

  • P-256
  • P-384

Extended Key Usage

  • Server Authentication,
  • Client Authentication,
  • Server Authentication + Client Authentication.

Key Usage

Digital Signature jest podstawowym Key Usage. Opcjonalnie możliwe jest również:

  • dla RSA – Key Encipherment,
  • dla ECC – Key Agreement.

Nazwy i adresy

Certyfikat może zabezpieczać:

  • FQDN,
  • publiczne lub obsługiwane przez politykę adresy IP,
  • wiele nazw SAN.

DigiCert pozwala umieścić w jednym certyfikacie X9 do 250 nazw domenowych i adresów IP.

Wildcard

Certyfikaty X9 PKI for TLS nie obsługują nazw wildcard, takich jak: *.twojadomena.pl.
Przy projektowaniu migracji z klasycznych certyfikatów TLS jest to istotne ograniczenie, które należy uwzględnić.

Czy X9 PKI jest bezpieczne?

X9 PKI zapewnia infrastrukturę zaufania i mechanizm wydawania certyfikatów, ale bezpieczeństwo całego systemu zależy również od sposobu wykorzystania kluczy prywatnych.
Należy zwrócić uwagę m.in. na:

  • sposób generowania kluczy,
  • ochronę kluczy prywatnych,
  • kontrolę dostępu,
  • konfigurację TLS,
  • sposób przechowywania certyfikatów,
  • proces odnowienia,
  • unieważnianie,
  • monitoring,
  • audyt.

W środowiskach o wysokich wymaganiach bezpieczeństwa klucz prywatny może być przechowywany np. w:

  • HSM,
  • TPM,
  • bezpiecznym magazynie kluczy,
  • dedykowanym module kryptograficznym.

Certyfikat może być informacją publiczną.

Klucz prywatny nigdy nie powinien być udostępniany podmiotom, które nie są uprawnione do posługiwania się daną tożsamością.

Jak wygląda proces wdrożenia X9 PKI?

  1. Identyfikacja zastosowania
    Najpierw należy ustalić:
    • które systemy będą korzystały z certyfikatów,
    • które występują jako serwer,
    • które jako klient,
    • czy stosowany jest mTLS,
    • czy komunikacja przekracza granice organizacji.
  1. Wybór modelu zaufania
    Należy zdecydować, czy właściwe będzie:
    • publiczne Web PKI,
    • X9 PKI,
    • Private PKI.
  1. Wybór EKU
    Dla każdego certyfikatu należy określić:
    • Server Authentication,
    • Client Authentication,
    • oba EKU.

Nie należy automatycznie stosować obu EKU, jeżeli certyfikat potrzebuje tylko jednego z nich.

  1. Generowanie klucza i CSR
    Klucz prywatny najlepiej generować bezpośrednio w środowisku, w którym będzie wykorzystywany. Następnie tworzony jest CSR przekazywany do CA.
  1. Walidacja organizacji i domen
    DigiCert przeprowadza odpowiednią walidację organizacji dla X9 oraz Domain Control Validation dla nazw znajdujących się w certyfikacie.
  1. Wydanie certyfikatu
    Po zakończeniu wymaganej walidacji DigiCert wystawia certyfikat X9.
  1. Konfiguracja trust store
    Obie strony muszą prawidłowo rozpoznawać wymagany łańcuch X9.
  1. Test mTLS
    Należy zweryfikować m.in.:
    • TLS handshake,
    • certyfikat serwera,
    • certyfikat klienta,
    • EKU,
    • SAN,
    • ważność,
    • łańcuch CA,
    • mechanizm unieważnienia.
  1. Automatyzacja cyklu życia
    Przy większej liczbie certyfikatów ręczne zarządzanie szybko staje się ryzykowne.
    Warto zautomatyzować:
    • zamawianie,
    • generowanie CSR,
    • instalację,
    • odnowienie,
    • rotację,
    • monitoring terminów ważności,
    • unieważnianie.

Kto powinien zainteresować się X9 PKI przed 2027 rokiem?

Warto przeprowadzić audyt certyfikatów, jeżeli organizacja korzysta obecnie z publicznych certyfikatów TLS w:

  • mutual TLS,
  • API,
  • komunikacji server-to-server,
  • integracjach B2B,
  • systemach płatniczych,
  • uwierzytelnianiu urządzeń,
  • komunikacji M2M.

Najprostszym sposobem jest sprawdzenie EKU używanych certyfikatów. Jeżeli znajdują się w nich jednocześnie: TLS Web Server AuthenticationTLS Web Client Authentication, należy ustalić, czy Client Authentication jest rzeczywiście wykorzystywane. Jeżeli tak, trzeba zaplanować migrację przed 1 marca 2027 r.

Najważniejsze zalety X9 PKI

  1. Client Authentication
    X9 nadal umożliwia wydawanie certyfikatów przeznaczonych do uwierzytelniania klientów.
  1. Mutual TLS
    X9 dobrze pasuje do komunikacji wymagającej kryptograficznego uwierzytelnienia obu stron.
  1. Wspólny model zaufania
    Ułatwia komunikację pomiędzy niezależnymi organizacjami.
  1. Niezależność od Web PKI
    Polityka X9 nie jest uzależniona od programów zaufania przeglądarek.
  1. Elastyczne EKU
    Certyfikat może posiadać:
    • Server Authentication,
    • Client Authentication,
    • oba EKU.
  1. Zastosowania non-browser
    X9 zostało zaprojektowane dla środowisk, w których komunikują się systemy, usługi i urządzenia.

X9 PKI – najczęściej zadawane pytania

Co to jest X9 PKI?

X9 PKI jest niezależną od publicznej Web PKI infrastrukturą klucza publicznego zarządzaną według polityki ASC X9. Została zaprojektowana przede wszystkim do interoperacyjnej komunikacji system-system, mTLS, API i innych zastosowań non-browser.

Czy X9 PKI obsługuje Client Authentication?

Tak. X9 PKI for TLS może zawierać:

  • Client Authentication,
  • Server Authentication,
  • oba EKU.

Czy X9 PKI można wykorzystać do mTLS?

Tak. Mutual TLS jest jednym z podstawowych zastosowań X9 PKI for TLS.

Czy X9 PKI zastąpi certyfikat SSL dla strony internetowej?

Nie. Publiczne strony internetowe powinny nadal korzystać z certyfikatów Web PKI zaufanych przez przeglądarki.

Czy X9 PKI nadaje się do API?

Tak. X9 może być wykorzystywane do uwierzytelniania serwerów i klientów w komunikacji API, szczególnie w przypadku mTLS.

Czy X9 PKI jest tylko dla banków?

Nie. X9 zostało stworzone przede wszystkim dla potrzeb sektora finansowego, ale rozwiązanie może być stosowane również w innych branżach, jeśli dany przypadek użycia odpowiada polityce X9.

Czym X9 PKI różni się od Private PKI?

Private PKI jest najczęściej wykorzystywane wewnątrz jednej organizacji, która sama kontroluje hierarchię zaufania. X9 PKI wykorzystuje wspólną hierarchię zaufania i jest szczególnie interesujące w komunikacji pomiędzy niezależnymi organizacjami.

Co stanie się z Client Authentication w publicznych certyfikatach TLS DigiCert?

  • Od 1 października 2025 r. DigiCert domyślnie wydaje publiczne certyfikaty TLS tylko z Server Authentication EKU.
  • Do 1 marca 2027 r. Client Authentication można jeszcze wybrać podczas zamawiania.
  • Od 1 marca 2027 r. nowe publiczne certyfikaty TLS DigiCert nie będą już mogły zawierać Client Authentication EKU.

Podsumowanie

X9 PKI jest dedykowaną infrastrukturą zaufania dla komunikacji, w której klasyczna publiczna Web PKI nie jest odpowiednim rozwiązaniem.

Najważniejsze zastosowania obejmują:

  • mutual TLS,
  • Client Authentication,
  • API,
  • komunikację server-to-server,
  • M2M,
  • uwierzytelnianie urządzeń,
  • systemy finansowe,
  • komunikację pomiędzy niezależnymi organizacjami.

Znaczenie X9 PKI rośnie w związku z wycofywaniem Client Authentication EKU z publicznie zaufanych certyfikatów TLS. Organizacje, które obecnie wykorzystują publiczne certyfikaty SSL/TLS zarówno do Server Authentication, jak i Client Authentication, powinny przed 1 marca 2027 r. sprawdzić swoje systemy i zdecydować, jaki model zaufania będzie właściwy w przyszłości.

  1. Dla systemów stricte wewnętrznych właściwym rozwiązaniem może być Private PKI.
  2. Dla komunikacji pomiędzy niezależnymi organizacjami, systemami, API lub urządzeniami X9 PKI for TLS może zapewnić wspólną, niezależną od przeglądarek infrastrukturę zaufania wraz z obsługą Client Authentication i mutual TLS.

Najważniejsza zasada pozostaje jednak niezmienna:

Certyfikat do publicznej strony WWW, certyfikat klienta mTLS i certyfikat wykorzystywany do komunikacji system-system nie muszą i coraz częściej nie powinny być tym samym certyfikatem.


Zobacz również:

  1. Dlaczego DigiCert kończy wsparcie dla Client Authentication EKU?
  2. DigiCert x9 PKI for TLS
  3. RSA vs ECC (ECDSA) w certyfikatach SSL. Co wybrać i dlaczego?
  4. Automatyzacja z DigiCert Trust Lifecycle Manager
  5. Czym jest certyfikat SSL/TLS?
Oceń ten artykuł
Średnia ocena czytelników 5,00/5,00 na podstawie 2 głosów
Informacja o plikach cookies

Ta strona wykorzystuje technologię plików cookies. Korzystając z naszego serwisu bez zmiany ustawień dotyczących cookies wyrażasz zgodę na ich używanie, zgodnie z aktualnymi ustawieniami przeglądarki. Pozwalają nam one m.in. rozpoznawać użytkowników i ich preferencje, jak również dostarczają informacji, które elementy naszej strony są najpopularniejsze i najbardziej użyteczne dla osób odwiedzających nasz serwis.

Rozumiem
SSL24 na Facebooku