certyfikat cyfrowy

Certyfikat cyfrowy to podpisany elektronicznie dokument, który wiąże klucz publiczny z tożsamością jego właściciela: domeną, firmą albo osobą. Standard X.509 w profilu internetowym RFC 5280 opisuje go jako strukturę, w której zaufany urząd certyfikacji (CA) swoim podpisem poświadcza, że dany klucz publiczny należy do wskazanego podmiotu ^[1]. Dzięki temu odbiorca może uznać, że klucz prywatny odpowiadający temu kluczowi publicznemu ma właściwy właściciel ^[1]. Certyfikat obowiązuje w określonym terminie i może zostać unieważniony przed jego upływem ^[1].

Jak działa

Certyfikat jest zastosowaniem kryptografii asymetrycznej. Właściciel generuje parę kluczy, zatrzymuje klucz prywatny, a klucz publiczny przekazuje urzędowi certyfikacji. Urząd sprawdza tożsamość wnioskodawcy, a następnie składa podpis cyfrowy pod zestawem danych zawierającym klucz publiczny i opis podmiotu. Każdy, kto ufa kluczowi urzędu, może ten podpis zweryfikować.

W praktyce przeglądarka nie zna kluczy wszystkich urzędów. RFC 5280 opisuje ścieżkę certyfikacji: łańcuch złożony z certyfikatu końcowego podpisanego przez jeden urząd oraz zera lub więcej certyfikatów pośrednich, podpisanych przez kolejne urzędy ^[1]. Łańcuch pozwala zweryfikować certyfikat, gdy użytkownik ma tylko ograniczoną liczbę zaufanych kluczy urzędów głównych ^[1]. Całość tego systemu nazywa się infrastrukturą klucza publicznego (PKI).

RYS. 1Weryfikacja certyfikatu przez klienta

Składniki

RFC 5280 wymienia podstawowe pola certyfikatu, które podpisuje urząd ^[1]. Najważniejsze zestawia tabela.

Okres ważności to według RFC 5280 czas od notBefore do notAfter włącznie; przez ten czas urząd zobowiązuje się utrzymywać informację o statusie certyfikatu ^[1]. Unieważnienie przed terminem ogłasza się na liście CRL, czyli podpisanej przez urząd, opatrzonej znacznikiem czasu liście unieważnionych certyfikatów ^[1]. Jako powody unieważnienia RFC podaje między innymi zmianę nazwy, zakończenie związku podmiotu z urzędem oraz kompromitację albo podejrzenie kompromitacji klucza prywatnego ^[1]. Alternatywą dla list jest protokół OCSP, który pozwala sprawdzić bieżący status certyfikatu bez pobierania CRL ^[2].

Rodzaje

Ten sam format X.509 służy wielu zastosowaniom. Najczęściej spotykany jest certyfikat SSL/TLS, który potwierdza tożsamość serwera w protokole TLS. Certyfikaty wystawia się też do podpisywania kodu, poczty elektronicznej i do uwierzytelniania osób.

Certyfikaty serwerowe różnią się zakresem weryfikacji podmiotu. Let's Encrypt wydaje wyłącznie certyfikaty z walidacją domeny (DV) i nie oferuje certyfikatów OV ani EV, bo ich wydawania nie da się zautomatyzować ^[3]. Domyślny certyfikat tego urzędu jest ważny 90 dni, a organizacja zaleca odnawianie co 60 dni; opcjonalne certyfikaty krótkożyjące są ważne sześć dni ^[3].

Okresy ważności w całej branży się skracają. Głosowanie SC081v3 CA/Browser Forum przewiduje zmniejszenie maksymalnego okresu ważności certyfikatów TLS z 398 do 47 dni, etapami od marca 2026 do marca 2029 roku ^[4]. Krótszy termin ogranicza czas, w którym skradziony klucz pozostaje użyteczny, ale wymusza automatyczne odnawianie; zob. rotacja kluczy.

W WordPressie

WordPress korzysta z certyfikatów w dwóch rolach. Jako serwer witryna przedstawia certyfikat odwiedzającym. Dokumentacja podaje, że WordPress jest w pełni zgodny z HTTPS, gdy serwer WWW ma zainstalowany certyfikat TLS/SSL ^[6]. Stała FORCE_SSL_ADMIN w wp-config.php wymusza logowanie i wszystkie sesje panelu przez szyfrowane połączenie ^[6].

define( 'FORCE_SSL_ADMIN', true );

Po przejściu na HTTPS trzeba zadbać o mixed content oraz o nagłówek HSTS, który każe przeglądarce łączyć się wyłącznie przez HTTPS.

Jako klient WordPress łączy się z innymi serwerami: pobiera aktualizacje, wywołuje API i usługi płatności. Klasa WP_Http domyślnie weryfikuje certyfikat po drugiej stronie, bo argument sslverify ma wartość domyślną true ^[5]. Listę zaufanych urzędów bierze z pliku wp-includes/certificates/ca-bundle.crt, dołączonego do rdzenia ^[5]. Wyłączenie sslverify w kodzie wtyczki usuwa tę kontrolę i otwiera drogę atakowi man-in-the-middle (MITM).

Zagrożenia i skutki

Certyfikat jest tak wiarygodny, jak urząd, który go wystawił, i jak klient, który go sprawdza. Oba ogniwa zawodziły.

• Kompromitacja urzędu. Mozilla opisała w sierpniu 2011 roku fałszywy certyfikat dla *.google.com wydany przez urząd DigiNotar ^[7]. DigiNotar wykrył włamanie do swojej infrastruktury 19 lipca 2011 roku ^[7]. Mozilla odebrała zaufanie certyfikatowi głównemu DigiNotar w nowych wersjach Firefoksa, Thunderbirda i SeaMonkey ^[7].
• Błędna weryfikacja po stronie klienta. CERT Polska opublikował 24 lipca 2026 roku informację o podatności CVE-2026-15243 w bibliotece Apereo CAS Client, która akceptowała dowolny certyfikat zaufanego urzędu dla dowolnej nazwy hosta ^[8]. Atakujący w pozycji pośrednika mógł dzięki temu przechwytywać bilety uwierzytelniające ofiar ^[8].
• Wyciek klucza prywatnego. Kto ma klucz prywatny, może podszyć się pod właściciela certyfikatu aż do jego unieważnienia albo wygaśnięcia; dlatego RFC 5280 wymienia kompromitację klucza wśród powodów unieważnienia ^[1].

Dobre praktyki

• Klucz prywatny trzymać tylko na serwerze, który go używa, z uprawnieniami ograniczonymi do procesu serwera WWW.
• Odnawiać certyfikaty automatycznie i monitorować datę notAfter; przy krótkich okresach ważności ręczne odnawianie przestaje być wykonalne ^[4].
• Po podejrzeniu wycieku klucza unieważnić certyfikat i wygenerować nową parę kluczy, a nie tylko nowy certyfikat dla starego klucza ^[1].
• W kodzie wtyczek i motywów nie wyłączać sslverify; zostawić domyślną weryfikację WP_Http ^[5].
• Przy integracjach z zewnętrznymi systemami sprawdzać nie tylko łańcuch zaufania, ale też zgodność nazwy hosta z certyfikatem ^[8].