urząd certyfikacji

Urząd certyfikacji (certificate authority, CA) to zaufany podmiot, który sprawdza tożsamość wnioskodawcy, wystawia mu certyfikat cyfrowy i w razie potrzeby go unieważnia. W standardzie RFC 5280 urząd certyfikacji jest jednym z elementów architektury infrastruktury klucza publicznego (PKI), obok podmiotów końcowych, opcjonalnego urzędu rejestracji i wystawcy list unieważnień ^[1]. Certyfikat jest wiarygodny tylko w takim stopniu, w jakim wiarygodny jest urząd, który go podpisał. Kompromitacja urzędu podważa więc zaufanie do wszystkich certyfikatów, które wydał.

Jak działa

Urząd certyfikacji wiąże klucz publiczny z tożsamością, składając na certyfikacie swój podpis cyfrowy. Przeglądarka albo system operacyjny ma zestaw zaufanych certyfikatów głównych. RFC 5280 opisuje certyfikaty samopodpisane jako te, które służą do przekazania klucza publicznego, od którego zaczyna się ścieżka certyfikacji ^[1]. Odbiorca sprawdza łańcuch: od certyfikatu serwera, przez jeden lub więcej certyfikatów urzędów, aż do zaufanego certyfikatu głównego ^[1].

Rozszerzenie basicConstraints z flagą cA odróżnia certyfikat urzędu od certyfikatu podmiotu końcowego, a pole pathLenConstraint ogranicza, ile poziomów urzędów podrzędnych może się pod nim znaleźć ^[1]. Gdy certyfikat traci ważność przed terminem, na przykład po ujawnieniu klucza, urząd publikuje podpisaną listę unieważnionych certyfikatów ^[1].

Cykl życia certyfikatu pokazuje schemat poniżej.

RYS. 1Cykl życia certyfikatu u urzędu certyfikacji

Rodzaje

Urzędy tworzą hierarchię. Klucz urzędu głównego podpisuje certyfikaty urzędów pośrednich, a te wystawiają certyfikaty dla serwerów i osób. Przykładem jest Let's Encrypt: klucze jego certyfikatów głównych są przechowywane offline, a certyfikaty subskrybentów wystawiają urzędy pośrednie ^[2].

Poza publicznymi urzędami, którym ufają przeglądarki, istnieją urzędy prywatne, tworzone wewnątrz firm na potrzeby VPN, poczty czy podpisywania kodu. Ich certyfikaty są zaufane tylko na urządzeniach, na których zainstalowano ich certyfikat główny.

W WordPressie

WordPress sam nie jest urzędem certyfikacji, ale korzysta z nich w dwóch miejscach. Pierwsze to połączenia przychodzące: dokumentacja zaznacza, że WordPress w pełni obsługuje HTTPS, gdy na serwerze zainstalowano certyfikat SSL/TLS ^[7]. Certyfikat wystawia urząd, najczęściej za pośrednictwem hostingu. Stała FORCE_SSL_ADMIN w wp-config.php wymusza logowanie i sesje panelu przez SSL ^[7].

Drugie miejsce to połączenia wychodzące, na przykład sprawdzanie aktualizacji i żądania wtyczek do zewnętrznych API. Klasa WP_Http domyślnie weryfikuje certyfikat serwera, bo argument sslverify ma wartość domyślną true ^[6]. Lista zaufanych urzędów pochodzi z pliku wp-includes/certificates/ca-bundle.crt, wskazanego przez argument sslcertificates ^[6].

Z punktu widzenia bezpieczeństwa ważne jest, by wtyczki nie wyłączały tej weryfikacji. Ustawienie sslverify na false sprawia, że połączenie jest szyfrowane, ale strona nie wie, z kim rozmawia. Otwiera to drogę do ataku man-in-the-middle (MITM) na komunikację z bramkami płatności, licencjami czy serwerami aktualizacji. Taki przypadek to jedna z postaci błędnej konfiguracji zabezpieczeń.

Zagrożenia i skutki

Urząd certyfikacji jest pojedynczym punktem zaufania. Jeśli atakujący przejmie jego klucz albo system wystawiania, może wygenerować prawidłowo podpisane certyfikaty dla dowolnej domeny. Przeglądarka nie odróżni ich od prawdziwych, a ruch użytkowników można przechwycić przez MITM albo przekierować w ramach pharmingu.

Błędy zdarzają się również po stronie oprogramowania, które sprawdza certyfikaty. CERT Polska 25 maja 2026 roku opisał podatność CVE-2026-9058 w Szafir SDK Krajowej Izby Rozliczeniowej ^[5]. Biblioteka automatycznie pobierała certyfikat nadrzędnego urzędu certyfikacji z adresu podanego w niezaufanym certyfikacie, importowała go i zwracała wynik weryfikacji pozytywnej ^[5]. Według komunikatu mogło to prowadzić do obejścia uwierzytelniania i podszycia się pod innego użytkownika w aplikacjach, które korzystały z biblioteki ^[5]. Podatne były wszystkie wersje poniżej 1.8.463.2 ^[5].

Jak się bronić

• Monitorować logi Certificate Transparency. RFC 9162 opisuje publiczne rejestrowanie certyfikatów TLS tak, by każdy mógł audytować działania urzędów i zauważyć wystawienie podejrzanych certyfikatów ^[3]. Właściciel domeny może regularnie sprawdzać, czy nie wystawiono dla niej certyfikatu, którego się nie spodziewał ^[3].
• Nie wyłączać weryfikacji certyfikatu w kodzie i konfiguracji, także w środowisku testowym, z którego ustawienia łatwo trafiają na produkcję.
• Chronić klucz prywatny certyfikatu serwera; po jego ujawnieniu wystąpić o unieważnienie certyfikatu ^[1].
• Aktualizować system i oprogramowanie, bo razem z nimi przychodzą aktualne listy zaufanych urzędów.

Historia i przykłady

Najczęściej przywoływanym przykładem jest holenderski urząd DigiNotar. Mozilla 29 sierpnia 2011 roku poinformowała, że DigiNotar wystawił fałszywy certyfikat dla *.google.com ^[4]. Sprawę zgłosił Mozilli Google ^[4]. Według wpisu użytkownicy przejętej sieci mogli trafić na strony z fałszywym certyfikatem, uznać je za prawdziwe i podać na nich login oraz hasło ^[4]. Mozilla wydała aktualizacje Firefoksa, Thunderbirda i SeaMonkey, które cofnęły zaufanie do certyfikatu głównego DigiNotar ^[4]. Incydent pokazał, że utrata zaufania do jednego urzędu unieważnia w praktyce wszystkie jego certyfikaty.