Polskie kwalifikowane certyfikaty pod eIDAS — używane m.in. do logowania w Profilu Zaufanym i ePUAP — wydają dostawcy akredytowani przez Narodowe Centrum Certyfikacji (NCCert), tacy jak KIR czy Certum. To zupełnie inny łańcuch zaufania niż ten, który przeglądarka sprawdza przy zwykłym certyfikacie TLS strony internetowej.
Z jakich pól składa się certyfikat
- Subject — dla kogo wystawiono certyfikat (domena, organizacja, a w kontekście kwalifikowanym — konkretna osoba).
- Issuer — kto wystawił certyfikat (urząd certyfikacji, CA).
- Okres ważności — daty początku i końca ważności certyfikatu.
- Klucz publiczny — klucz używany do nawiązania bezpiecznego połączenia lub weryfikacji podpisu.
- Podpis cyfrowy — podpis wystawcy, potwierdzający autentyczność wszystkich pozostałych pól.
Ten sam format, inny łańcuch zaufania
Certyfikat kwalifikowany i certyfikat TLS witryny korzystają z dokładnie tej samej struktury X.509 i tego samego mechanizmu łańcucha zaufania: pośredni urząd certyfikacji podpisuje certyfikat końcowy, a główny (root) CA podpisuje pośredni. Różnica leży wyłącznie w tym, jaki magazyn zaufania to sprawdza: oprogramowanie do podpisu kwalifikowanego ufa CA akredytowanym przez NCCert w ramach eIDAS, podczas gdy przeglądarka ufa zupełnie innemu zestawowi komercyjnych CA dla HTTPS — obydwa łańcuchy nigdy nie muszą się spotkać.
Dlaczego okres ważności jest ograniczony
Ograniczony okres ważności (zwykle od 90 dni do 1 roku dla nowoczesnych certyfikatów webowych) zmniejsza ryzyko związane ze skompromitowanym kluczem prywatnym i wymusza regularną aktualizację parametrów kryptograficznych zgodnie z aktualnymi standardami bezpieczeństwa.
Do czego to się przydaje
- Diagnozowanie problemów z certyfikatami SSL przy konfiguracji serwera WWW.
- Sprawdzanie okresu ważności i wystawcy certyfikatu bez korzystania z zewnętrznych serwisów.
- Zrozumienie struktury certyfikatu przy pracy z mTLS, certyfikatami klienckimi lub podpisem kwalifikowanym.
Certyfikaty samopodpisane
Certyfikat może być podpisany własnym kluczem prywatnym zamiast przez jakikolwiek CA — strukturalnie wygląda identycznie jak „prawdziwy” X.509, z tymi samymi polami, ale Issuer i Subject są w nim identyczne. To to samo pytanie o zaufanie doprowadzone do skrajności: łańcuch nie prowadzi donikąd, więc nic poza twoją własną konfiguracją nie ma powodu mu ufać — dlatego nadaje się do wewnętrznych testów, ale wszędzie indziej jest oznaczany jako niezaufany.