Jakie są metody weryfikacji domeny przy wydawaniu certyfikatu SSL?

Metody weryfikacji domeny przy wydawaniu certyfikatu SSL obejmują autoryzację przez e-mail (kliknięcie linku zatwierdzającego wysłanego na z góry określoną skrzynkę administratora), walidację opartą na pliku HTTP (umieszczenie unikalnego pliku tekstowego na serwerze webowym) oraz weryfikację DNS (dodanie specjalnego rekordu TXT do strefy zarządzania domeną). Urzędy certyfikacji (CA) stosują te mechanizmy, by upewnić się bez cienia wątpliwości, że wnioskodawca ma faktyczną i techniczną kontrolę nad adresem internetowym przed wystawieniem mu kryptograficznego podpisu. To twardy rynkowy standard.

Zajmujemy się wdrażaniem takich zabezpieczeń na produkcji właściwie każdego dnia. Prawda jest zresztą absolutnie taka, że bez prawidłowego potwierdzenia własności żaden komercyjny ani darmowy urząd nie wyda ci kłódki do przeglądarki. Wybór odpowiedniej ścieżki autoryzacji zależy od tego, do czego masz obecnie dostęp. Do poczty, do serwera plików, czy do panelu rejestratora.

Jakie są metody weryfikacji domeny przy wydawaniu certyfikatu SSL w praktyce?

Kiedy wysyłasz żądanie podpisania certyfikatu (CSR) do urzędu certyfikacji, ten musi sprawdzić, czy faktycznie rządzisz zgłaszanym adresem. Proces ten nazywa się walidacją kontroli nad domeną (Domain Validation – DV). Weryfikacja SSL opiera się na udowodnieniu władzy nad infrastrukturą.

Mamy do dyspozycji cztery główne ścieżki postępowania.

• Weryfikacja przez adres e-mail (Email Challenge) polega na odebraniu wiadomości z linkiem aktywacyjnym. Urząd wyśle ją tylko na konkretne adresy zdefiniowane w standardach branżowych. Są to admin@, administrator@, webmaster@, hostmaster@ oraz postmaster@. System akceptuje również adresy widniejące bezpośrednio w bazie Whois, o ile rejestrator ich nie ukrył. To metoda najszybsza. Wymaga jednak posiadania włączonej poczty w samej domenie.
• Autoryzacja przez plik na serwerze (HTTP/HTTPS File Authentication). Polega na pobraniu z panelu urzędu specjalnego pliku tekstowego z ciągiem znaków. Następnie musisz go wgrać na swój serwer FTP do specjalnie utworzonego ukrytego katalogu. Ścieżka wygląda zawsze tak samo: /.well-known/pki-validation/nazwapliku.txt.
• Weryfikacja przez rekord DNS (DNS TXT Record) to umieszczenie w strefie domeny unikalnego ciągu znaków jako rekordu tekstowego. Robot urzędu odpytuje globalne serwery nazw. Kiedy znajdzie zgodny hash, autoryzuje wniosek.
• Weryfikacja protokołem ACME (np. Let’s Encrypt). To zautomatyzowane podejście, które pod maską wykorzystuje wyzwania HTTP-01 lub DNS-01, ale proces negocjacji z CA wykonuje za nas oprogramowanie na serwerze, takie jak Certbot.

Z naszego doświadczenia wynika, że klienci najczęściej wybierają metodę plikową. Wydaje się najprostsza. Logujesz się na serwer, wrzucasz plik, klikasz weryfikuj. Działa od razu.

Na czym polega weryfikacja SSL przez e-mail (Email Approval) i dlaczego bywa uciążliwa?

Wybierając metodę pocztową, zlecasz urzędowi wysłanie tokena autoryzacyjnego. Odbierasz maila, klikasz w link, wklejasz kod na stronie CA. Certyfikat generuje się w kilka sekund.

Brzmi świetnie. Problem pojawia się w strukturach firmowych.

Zrobiliśmy na wdrożeniu certyfikatów dla dużej spółki prosty test. Okazało się, że nikt w firmie nie miał dostępu do konta admin@. Polityka bezpieczeństwa zakładała tworzenie wyłącznie skrzynek imiennych. Próbowaliśmy użyć adresu z bazy Whois. Niestety, w dobie RODO i ochrony prywatności, rejestratorzy maskują maile właścicieli. Urząd certyfikacji widział tam tylko ciąg znaków przypisany do usługi proxy. Zmiana konfiguracji poczty i dodanie aliasu webmaster@ zajęła działowi IT dwa dni. Cały proces stanął.

Urzędy certyfikacji są tu bezlitosne. Nie wyślą maila weryfikacyjnego na adres biuro@, kontakt@ ani prezes@. To wymóg ustalony przez CA/Browser Forum. Chroni to przed sytuacją, w której szeregowy pracownik recepcji przejmuje kontrolę nad SSL i generuje certyfikat do ataku man-in-the-middle. Musisz mieć konto z uprawnieniami administracyjnymi.

Dlaczego walidacja przez plik HTTP/HTTPS sprawia problemy na serwerach aplikacji?

Metoda plikowa (HTTP File Challenge) omija problemy z pocztą. Wymaga dostępu do plików źródłowych strony. W klasycznym hostingu współdzielonym z panelem cPanel czy DirectAdmin to banalnie proste zadanie.

Schody zaczynają się przy nowoczesnych frameworkach.

Ostatnio wdrażaliśmy certyfikat pod aplikację napisaną w Next.js. Serwer Node.js przechwytywał wszystkie żądania. Gdy bot urzędu certyfikacji próbował wejść pod adres /.well-known/pki-validation/plik.txt, router aplikacji zwracał błąd 404 albo przekierowywał go na stronę główną. Musieliśmy pisać specjalne reguły w Nginx, żeby ruch do ukrytego katalogu serwować jako pliki statyczne, z pominięciem logiki aplikacji.

Kolejny problem to wymuszanie HTTPS. Wyobraź sobie sytuację. Kupujesz nowy certyfikat, bo stary wygasł. Twoja strona ma twarde przekierowanie z HTTP na HTTPS (HSTS). Urząd certyfikacji próbuje odczytać plik weryfikacyjny po HTTP. Twój serwer mówi: „przejdź na HTTPS”. Bot urzędu idzie na HTTPS, ale widzi nieważny certyfikat (bo właśnie próbujesz go odnowić). Zrywa połączenie. Błąd weryfikacji.

W takich przypadkach trzeba tymczasowo wyłączyć wymuszanie szyfrowania dla folderu .well-known. To żmudna praca przy konfiguracji serwera.

Jak poprawnie dodać rekord TXT DNS do autoryzacji SSL i uniknąć przestojów?

Weryfikacja DNS-01 polega na udowodnieniu CA, że rządzisz strefą DNS. Otrzymujesz z urzędu specjalny ciąg znaków. Wchodzisz do panelu swojego operatora (np. Cloudflare, OVH czy nazwa.pl) i tworzysz nowy rekord typu TXT.

Zazwyczaj dodajesz go dla subdomeny lub głównego rekordu. W przypadku Let’s Encrypt musisz utworzyć rekord o nazwie _acme-challenge.twojadomena.pl z wartością tokena.

To jest całkowicie niezależne od tego, czy masz już postawioną stronę internetową. Rekord DNS TXT sprawdza się idealnie, gdy konfigurujesz infrastrukturę przed oficjalnym startem projektu. Certyfikat czeka gotowy na serwerze, zanim jeszcze podepniesz tam docelowy adres IP.

Jest tu jednak haczyk. Propagacja.

Zmieniliśmy te zasady na robocie u klienta w zeszłym miesiącu. Serwery nazw miały ustawiony wysoki parametr TTL (Time to Live) na poziomie 86400 sekund (24 godziny). Dodaliśmy rekord TXT. Urząd certyfikacji odpytał globalne serwery. Nic nie znalazł. Czekaliśmy. Minęła godzina. Dalej nic. Boty CA pamiętały starą wersję strefy i odmawiały wydania SSL. Musieliśmy ręcznie wymuszać czyszczenie cache u głównych operatorów telekomunikacyjnych.

Dlatego przed rozpoczęciem weryfikacji przez DNS zmniejsz TTL swojej strefy do 300 sekund. Zrób to dzień wcześniej. Kiedy dodasz rekord weryfikacyjny dla certyfikatu, rozejdzie się on po świecie w pięć minut.

Jak zautomatyzować odnawianie SSL używając protokołu ACME?

Ręczne przeklejanie plików i klikanie w maile co rok to archaizm. Prawdziwa weryfikacja domeny odbywa się dzisiaj automatycznie przez protokół ACME (Automated Certificate Management Environment).

Uruchamiasz na serwerze demona, na przykład program Certbot. Wpisujesz jedną komendę. Oprogramowanie samo komunikuje się z serwerami Let’s Encrypt. Zgłasza chęć uzyskania certyfikatu. Let’s Encrypt wysyła wyzwanie HTTP-01. Certbot sam tworzy plik w /.well-known/pki-validation/. CA to weryfikuje. Certbot pobiera klucz prywatny i publiczny, instaluje go w Nginx i przeładowuje serwer.

To trwa cztery sekundy.

Zautomatyzowane metody weryfikacji domeny przy wydawaniu certyfikatu SSL całkowicie zabiły rynek płatnych, tanich kłódek DV. Nie ma żadnego racjonalnego powodu, by płacić za podstawowy certyfikat, skoro ACME robi to samo za darmo i odnawia go co 60 dni bez udziału człowieka.

Wyzwanie DNS-01 w środowiskach rozproszonych

Protokół ACME obsługuje też weryfikację przez DNS. Używamy tego do wystawiania certyfikatów typu Wildcard (czyli chroniących *.twojadomena.pl). Let’s Encrypt nie wyda Wildcarda po pliku HTTP. Wymaga twardego dowodu własności całej strefy.

Wymaga to spięcia Certbota z API twojego operatora DNS. Instalujesz wtyczkę, np. certbot-dns-cloudflare. Podajesz klucz API. Przy każdym odnowieniu Certbot sam loguje się do Cloudflare, dodaje rekord TXT, czeka na propagację, pobiera SSL i usuwa rekord. Czysta inżynieria.

Czym różni się weryfikacja DV od OV i EV w kontekście biznesowym?

Wszystko, co opisałem do tej pory, dotyczy certyfikatów Domain Validation (DV). Urząd sprawdza tylko i wyłącznie to, czy kontrolujesz adres internetowy. Nie obchodzi go, kim jesteś. Możesz być hakerem z drugiego końca świata. Jeśli przejmiesz serwer DNS, dostaniesz ważny certyfikat na dowolną stronę.

Dlatego banki i duże korporacje potrzebują wyższego poziomu zaufania.

Weryfikacja Organization Validation (OV) oraz Extended Validation (EV) idzie o krok dalej. Urząd certyfikacji najpierw weryfikuje domenę (jedną z trzech wyżej wymienionych metod), a potem zaczyna weryfikować podmiot.

• Sprawdzają dane w Krajowym Rejestrze Sądowym (KRS) lub CEIDG.
• Weryfikują rachunki za prąd i telefon przypisane do adresu firmy.
• Dzwonią na numer telefonu widniejący w publicznych spisach, by porozmawiać z osobą zamawiającą certyfikat SSL.

Wdrożenie certyfikatu EV to droga przez mękę. Czasem trwa dwa tygodnie. Urzędnicy potrafią odrzucić wniosek, bo nazwa spółki we wniosku CSR ma skrót „Sp. z o.o.”, a w rejestrze widnieje „Spółka z ograniczoną odpowiedzialnością”. Przechodziliśmy przez to wielokrotnie. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, to przeglądarki wycofały się z pokazywania zielonego paska z nazwą firmy. Certyfikaty EV powoli tracą sens z punktu widzenia widocznego interfejsu (UX), pozostając jedynie wymogiem audytorów bezpieczeństwa.

Co zrobić, gdy urząd certyfikacji odrzuca wniosek o SSL z powodu błędu CAA?

Czasem robisz wszystko dobrze. Masz maila, dodałeś plik HTTP, a CA i tak rzuca błędem i przerywa wydawanie certyfikatu. W logach widzisz tajemniczy komunikat: „CAA record prevents issuance”.

Rekord CAA (Certification Authority Authorization) to potężne narzędzie w strefie DNS. Mówi on globalnej sieci, które konkretnie urzędy certyfikacji mają prawo wystawić SSL dla twojej domeny.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Klient przeniósł do nas serwis. Miał w DNS wpis CAA zezwalający na wystawianie certyfikatów tylko przez firmę DigiCert. My próbowaliśmy wygenerować darmowy certyfikat z Let’s Encrypt. Serwery Let’s Encrypt sprawdzały strefę, widziały zakaz i natychmiast ubijały proces weryfikacji domeny.

Rozwiązanie jest proste. Edytuj strefę DNS. Zmień wpis CAA lub dodaj nowy, zezwalający nowemu urzędowi na operacje. Na przykład: 0 issue "letsencrypt.org". To blokada bezpieczeństwa. Działa świetnie, ale trzeba o niej pamiętać przy migracjach.

Wieloznacznikowe adresy i ograniczenia walidacji certyfikatów

Zabezpieczanie subdomen wymaga osobnego planowania. Weryfikacja domeny przy wydawaniu certyfikatu SSL dla pojedynczego adresu sklep.twojadomena.pl jest prosta. Jednak przy infrastrukturze chmurowej, gdzie subdomeny generują się dynamicznie, potrzebujesz certyfikatu Wildcard.

Pamiętaj o twardej zasadzie. Certyfikat wystawiony na *.twojadomena.pl chroni adres panel.twojadomena.pl. Nie chroni jednak adresu bazowego twojadomena.pl ani sub-subdomeny test.panel.twojadomena.pl.

Przy zgłaszaniu wniosku (CSR) o taki certyfikat, musisz udowodnić kontrolę nad całą gałęzią. CA wymusi na tobie użycie metody DNS TXT. Żadne maile i żadne pliki na serwerze nie przejdą. Urzędy uznają, że udowodnienie kontroli nad jedną stroną WWW to za mało, by powierzyć ci klucze do wszystkich potencjalnych subdomen w strukturze.

Odwołanie i unieważnienie certyfikatu SSL

Weryfikacja kontroli nad domeną to nie tylko proces wydawania. To także proces unieważniania (Revocation). Jeśli twój klucz prywatny wycieknie, musisz zgłosić to do urzędu.

CA ponownie sprawdzi twoją tożsamość. Użyje tych samych metod. Wyśle maila z linkiem do odwołania certyfikatu, poprosi o wrzucenie pliku na serwer lub zmianę DNS. Wszystko po to, by haker, który ukradł klucz, nie mógł złośliwie cofnąć zabezpieczeń bez dostępu do infrastruktury.

Baza unieważnionych certyfikatów trafia na listy CRL (Certificate Revocation List) oraz do serwerów OCSP. Przeglądarki na bieżąco sprawdzają ten status. Jeśli proces weryfikacji domeny upadnie lub wykaże oszustwo, certyfikat jest palony na poziomie globalnym.

Ostatecznie to wszystko sprowadza się do utrzymania absolutnego porządku w konfiguracji serwerów nazw i serwerów WWW. Weryfikacja SSL nie wybacza błędów konfiguracyjnych. Sprawdź swoje strefy DNS. Zobacz, ile wisi tam starych rekordów TXT od wygasłych walidacji z poprzednich lat. Usuń ten bałagan, zanim przy kolejnym odnowieniu certyfikatu automat zgłupieje i zablokuje ci szyfrowanie sklepu w środku nocy.

FAQ – Metody weryfikacji domeny przy wydawaniu certyfikatu SSL

• Co to jest weryfikacja kontroli nad domeną (DV)? To proces, w którym urząd certyfikacji (CA) upewnia się, że osoba wnioskująca o wydanie certyfikatu SSL ma prawo do zarządzania danym adresem internetowym.
• Ile trwa weryfikacja domeny przez e-mail? Proces zajmuje zazwyczaj kilkanaście sekund. Po kliknięciu w link z wiadomości e-mail (wysłanej np. na adres admin@), urząd natychmiast generuje certyfikat.
• Dlaczego nie dostałem maila weryfikacyjnego SSL? Prawdopodobnie podałeś adres, który nie znajduje się na liście akceptowanych przez CA (np. biuro@ zamiast webmaster@) lub wiadomość wylądowała w filtrze antyspamowym.
• Czym jest autoryzacja HTTP File dla certyfikatu SSL? To metoda polegająca na umieszczeniu pliku tekstowego z unikalnym kodem w specjalnym katalogu na serwerze (/.well-known/pki-validation/). Robot CA odczytuje go przez przeglądarkę.
• Dlaczego Let’s Encrypt odrzuca weryfikację DNS-01? Najczęstszą przyczyną jest opóźnienie w propagacji DNS. Dodałeś rekord TXT, ale serwery Let’s Encrypt jeszcze nie widzą zmiany w globalnej sieci. Należy zmniejszyć TTL strefy.
• Czy do weryfikacji certyfikatu Wildcard mogę użyć metody plikowej? Nie. Urzędy certyfikacji wymagają udowodnienia kontroli nad całą strefą, co zmusza do użycia weryfikacji opartej na rekordzie DNS TXT.

Bibliografia i źródła wiedzy

1. Naukowa i Akademicka Sieć Komputerowa (NASK) – https://nask.pl
2. Let’s Encrypt – https://letsencrypt.org
3. CA/Browser Forum – https://cabforum.org
4. Internet Engineering Task Force (IETF) – https://ietf.org
5. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
6. CERT Polska – https://cert.pl