Jakie są metody weryfikacji domeny przy wydawaniu certyfikatu SSL?

Weryfikacja domeny stanowi kluczowy element procesu wydawania certyfikatów SSL/TLS, ponieważ urzędy certyfikacji muszą potwierdzić, że wnioskodawca rzeczywiście kontroluje domenę, dla której żąda certyfikatu. Obecnie stosuje się zarówno tradycyjne metody oparte na e‑mailu, jak i bezpieczniejsze podejścia DNS oraz HTTP. Branża przechodzi na bardziej odporne i automatyzowalne mechanizmy walidacji, a kontrole realizowane są z wielu perspektyw sieciowych.

Treść (pokaż)

Fundament weryfikacji domeny w ekosystemie SSL/TLS

Zanim urząd certyfikacji (CA) wyda certyfikat SSL/TLS, musi potwierdzić kontrolę nad domeną. Proces ten, znany jako domain control validation (DCV), jest obowiązkowy dla wszystkich publicznych certyfikatów.

Wszystkie certyfikaty — DV, OV i EV — wymagają pomyślnego przejścia zatwierdzonej metody DCV przed wydaniem.

Standaryzacja metod przez CA/Browser Forum ujednoliciła procesy i zwiększyła bezpieczeństwo. Rzetelne potwierdzenie kontroli nad domeną ogranicza ryzyko phishingu, malware i innych nadużyć.

Przegląd głównych metod domain control validation

W praktyce stosuje się następujące ścieżki DCV:

weryfikacja e‑mail – potwierdzenie przez link/kod wysyłany na zdefiniowany adres powiązany z domeną;
weryfikacja DNS TXT – publikacja rekordu TXT z tokenem dostarczonym przez CA;
weryfikacja DNS CNAME – dodanie rekordu CNAME wskazującego na cel walidacyjny CA;
weryfikacja HTTP/HTTPS (plik) – udostępnienie pliku w katalogu /.well-known/ na serwerze WWW;
specjalny CNAME u dostawcy hostingu – model dla aliasów wskazujących na infrastrukturę usługodawcy.

Dla szybkiego porównania kluczowych właściwości metod walidacji domeny warto skorzystać z poniższej tabeli:

Metoda	Automatyzacja	Obsługa wildcard	Wymagania dostępu	Największe atuty	Ograniczenia
E‑mail	niska/średnia	nie	aktywny MX/poczta	prosta, szybka	filtry antyspam, zależność od poczty
DNS TXT	wysoka	tak	panel DNS	bezpieczna, działa bez WWW	propagacja DNS
DNS CNAME	wysoka	tak	panel DNS	delegacja, elastyczność	propagacja DNS
HTTP/HTTPS (plik)	średnia	nie	port 80/443, serwer WWW	szybka, bez zmian DNS	brak WWW/portów blokuje walidację
CNAME u hostera	wysoka	zależnie od dostawcy	alias CNAME	wygodne dla klientów hostingu	zależność od infrastruktury dostawcy

Metoda weryfikacji e‑mail

To jedna z najstarszych i najprostszych metod DCV. CA wysyła wiadomość na uprawniony adres powiązany z domeną, a odbiorca potwierdza kontrolę linkiem lub kodem.

Aktualnie akceptowane są trzy warianty e‑mail, niezależne od WHOIS:

Email to DNS TXT Contact – adres kontaktowy publikowany w rekordzie TXT pod subdomeną _validation-contactemail;
Email to DNS CAA Record Contact – adres kontaktowy zdefiniowany w rekordzie CAA domeny;
Constructed Email Method – wiadomości kierowane na standardowe skrzynki: admin@, administrator@, webmaster@, hostmaster@, postmaster@.

Warunkiem działania tej metody jest poprawny rekord MX w DNS domeny, aby CA mogło dostarczyć wiadomość weryfikacyjną.

Najważniejsze zalety weryfikacji e‑mail:

prosta konfiguracja po stronie wnioskodawcy,
szybkość całej procedury,
brak konieczności zmian w DNS lub na serwerze WWW.

Najczęstsze ograniczenia i ryzyka:

zależność od sprawnej poczty i konfiguracji MX,
możliwość odfiltrowania przez antyspam i przeoczenia wiadomości,
mniejsza niezawodność w organizacjach z częstymi zmianami adresów kontaktowych.

Metody weryfikacji oparte na DNS

Walidacja w DNS zyskuje na popularności dzięki bezpieczeństwu, odporności i możliwości pełnej automatyzacji. Wymaga dostępu do panelu DNS, ale daje mocny dowód kontroli.

DNS TXT polega na publikacji rekordu TXT z unikalnym tokenem przekazanym przez CA (np. w _pki-validation.example.com). Po wykryciu poprawnej wartości CA uznaje kontrolę nad domeną.

DNS CNAME wymaga dodania rekordu CNAME wskazującego na cel walidacyjny CA. Przykładowy wpis może zawierać skróty MD5/SHA‑256 CSR oraz token, np.: _517835F790CD5BFD248CBD1A9CD54579.yoursite.tld. 14400 IN CNAME 911b64b097e8e42d4179eb2b27452b4.abaaeb0073f872979666894dbce871cb.f08916997c.ssl.com.

Możliwe są rozszerzenia, np. DNSTXTPREFIX z prefiksem _certum (_certum._pki-validation.example.com) dla bardziej granularnej kontroli.

Kluczowe atuty DNS to wysoki poziom bezpieczeństwa, pełna automatyzacja, działanie bez aktywnej strony WWW i obsługa certyfikatów wildcard. Wadą bywa propagacja zmian.

Aby zminimalizować problemy z propagacją, zastosuj następujące praktyki:

obniż TTL rekordów na kilka dni przed planowaną zmianą,
poczekaj na wygaśnięcie dotychczasowych wpisów w cache resolverów,
sprawdzaj widoczność nowych rekordów z wielu lokalizacji (narzędzia diagnostyki DNS).

Metoda weryfikacji HTTP/HTTPS z przesyłaniem pliku

Właściciel domeny umieszcza plik tekstowy z wymaganym tokenem w katalogu /.well-known/acme-challenge/ lub /.well-known/pki-validation/. CA weryfikuje jego obecność przez HTTP GET (80) lub HTTPS GET (443).

Przykład: plik 8593532A8FA01E6CEBB0B7E85E510D0F.txt powinien być dostępny pod adresem http://www.example.com/.well-known/pki-validation/8593532A8FA01E6CEBB0B7E85E510D0F.txt.

Najważniejsze zalety metody HTTP/HTTPS:

łatwa dla administratorów WWW,
szybka weryfikacja po wdrożeniu pliku,
możliwa automatyzacja w narzędziach DevOps.

Ograniczenia i zastrzeżenia:

brak wsparcia dla wildcard,
wymóg aktywnego dostępu na portach 80/443,
niedostępna dla domen bez publicznego serwera WWW lub z restrykcyjną zaporą.

Metoda weryfikacji CNAME dla dostawców hostingu

Stosowana, gdy domena‑alias (CNAME) wskazuje na infrastrukturę usługodawcy hostingowego. Pozwala wydać certyfikat bez bezpośredniego dostępu do pierwotnych rekordów DNS domeny głównej. To wygodne w modelach multi‑tenant, gdzie operator hostingu centralnie koordynuje DCV.

Weryfikacja w kontekście różnych typów certyfikatów SSL

Certyfikaty domain validation (DV)

Najprostsze certyfikaty, wymagają jedynie DCV. Możliwe metody: e‑mail, DNS (TXT/CNAME) lub HTTP/HTTPS. Wydanie zwykle trwa od kilku minut do kilku godzin.

Rekomendowane dla blogów, portfolio i serwisów bez przetwarzania wrażliwych danych.

Certyfikaty organization validation (OV)

OV obejmuje DCV oraz weryfikację tożsamości organizacji. Typowy przebieg składa się z pięciu etapów:

autentykacja organizacji w rejestrach,
potwierdzenie lokalnej obecności,
weryfikacja telefonu w zatwierdzonym katalogu,
weryfikacja domeny (DCV),
rozmowa weryfikacyjna (callback).

Wydanie trwa zwykle 1–3 dni robocze, szybciej, jeśli dane są łatwo dostępne.

Certyfikaty extended validation (EV)

Najwyższy poziom zaufania: komplet kontroli DV/OV oraz dodatkowe sprawdzenia rejestracyjne, jurysdykcyjne i antyfraudowe.

Kluczowe elementy procesu EV obejmują:

weryfikację w źródłach rządowych i bazach (np. Dun & Bradstreet),
telefoniczne potwierdzenie aktywnego numeru w katalogu,
rozmowę weryfikacyjną z upoważnioną osobą,
ocenę ryzyk nadużyć i wykluczeń.

Czas wydania zazwyczaj 1–5 dni roboczych, w sprzyjających warunkach możliwe większe przyspieszenie.

Multi-perspective issuance corroboration (MPIC) – nowy standard weryfikacji

MPIC (Ballot SC‑067) wymaga, aby CA weryfikowały DCV i rekordy CAA z wielu, niezależnych perspektyw sieciowych i regionów RIR, by zwiększyć odporność na ataki (np. BGP hijacking, DNS spoofing).

Najważniejsze cele MPIC to ograniczenie skuteczności ataków na routing i rozstrzyganie rozbieżności poprzez model quorum.

Harmonogram wdrażania MPIC obejmuje kluczowe etapy:

marzec 2025 – start zbierania danych z wielu perspektyw (faza obserwacyjna),
wrzesień 2025 – wymóg spójnych wyników z wielu perspektyw do wydania certyfikatu,
kolejne miesiące – pełne przestrzeganie MPIC w całej branży.

Organizacje muszą zapewnić, że zasoby weryfikacyjne (DNS/HTTP) są dostępne globalnie, bez geoblokad i ograniczeń IP.

Zanikanie weryfikacji opartej na WHOIS

CA/Browser Forum (Ballot SC‑80v3) nakazało rezygnację z DCV opartych na WHOIS z uwagi na spadek jakości i prywatność danych.

Główne powody odejścia od WHOIS:

ograniczenia prywatności (GDPR) i powszechne ukrywanie danych,
niskie wskaźniki dokładności i aktualności kontaktów,
ryzyka bezpieczeństwa wynikające z publicznego, łatwo fałszowalnego rejestru.

Przykładowy harmonogram wygaszania (DigiCert):

8 stycznia 2025 – wstrzymanie wysyłek e‑mail DCV na adresy z WHOIS,
8 maja 2025 – wstrzymanie wsparcia dla WHOIS‑based Email DCV,
8 lipca 2025 – zakończenie ponownego użycia walidacji opartych na WHOIS.

Rekomendowane są alternatywy oparte na DNS: Email to DNS TXT Contact, Email to DNS CAA Contact lub Constructed Email.

Wpływ zmian w czasach ważności certyfikatów na weryfikację domeny

Ballot SC‑081 skraca maksymalne okresy ważności certyfikatów: 200 dni (od III 2026), 100 dni (od III 2027), 47 dni (od III 2029).

Poniższa tabela podsumowuje terminy i dopuszczalne okresy ponownego użycia danych walidacyjnych:

Wejście w życie	Maks. ważność certyfikatu	Ponowne użycie danych DCV
marzec 2026	200 dni	200 dni
marzec 2027	100 dni	100 dni
marzec 2029	47 dni	10 dni

W praktyce wymusza to automatyzację odnowień i weryfikacji. ACME (Automated Certificate Management Environment) umożliwia automatyczne żądanie, walidację i instalację certyfikatów bez ręcznej ingerencji przy każdym odnowieniu.

Wybór odpowiedniej metody weryfikacji domeny

Kryteria wyboru metody weryfikacji

Dla certyfikatów DV masz pełną elastyczność: e‑mail, DNS lub HTTP – zgodnie z zasobami i preferencją bezpieczeństwa. Kontrola nad serwerem WWW sprzyja HTTP; brak WWW lub chęć automatyzacji – wybierz DNS.

Dla certyfikatów OV i EV preferowane są metody DNS ze względu na bezpieczeństwo i niezawodność podczas bardziej rygorystycznej walidacji organizacji.

Dla certyfikatów wildcard jedyną dozwoloną metodą jest weryfikacja DNS, ponieważ wyłącznie ona dowodzi kontroli nad całym zakresem subdomen.

Scenariusze użycia i rekomendacje

W zależności od profilu serwisu i wymagań rozważ poniższe rekomendacje:

blogi i strony portfolio – najprostsza w implementacji będzie weryfikacja e‑mail, bez potrzeby modyfikacji DNS czy WWW;
serwisy e‑commerce i finansowe – preferuj metody DNS (zwykle wraz z OV/EV) dla wyższego poziomu bezpieczeństwa i automatyzacji;
usługi wewnętrzne i środowiska testowe – stosuj DCV w DNS, gdy brak publicznego WWW lub ruch jest filtrowany;
aplikacje wymagające automatyzacji – użyj ACME z walidacją DNS, aby zautomatyzować żądania, weryfikację i instalację certyfikatów.

Praktyczne implementacje i wyzwania techniczne

Zagadnienia z propagacją DNS

Globalne cache resolverów i wartość TTL mogą opóźnić widoczność nowych rekordów do 48–72 godzin. To naturalna cecha dystrybuowanego DNS.

Aby skrócić czas propagacji, warto:

obniżyć TTL (np. do 300 s) kilka dni przed zmianą,
zaplanować okno zmian i odczekać pełne wygaśnięcie starych wpisów w cache,
weryfikować propagację z różnych lokalizacji (narzędzia diagnostyczne DNS).

Problemy z dostępem do zasobów z wielu perspektyw

MPIC wymaga dostępności zasobów weryfikacyjnych z całego internetu. Restrykcyjne zapory lub ACL mogą blokować ruch z niektórych regionów.

Przygotowanie do MPIC obejmuje:

udokumentowanie architektury sieci i punktów dostępu,
weryfikację reguł zapór/ACL pod kątem geoblokad i list IP,
testy dostępności z różnych regionów (HTTP/DNS) i korektę konfiguracji,
wdrożenie monitoringu punktów końcowych DCV, aby szybko wykrywać problemy.

Integracja z istniejącymi systemami infrastrukturalnymi

Przy złożonych środowiskach (CDN, load balancery, multi‑DNS) zadbaj o spójność obsługi walidacji.

Zwróć uwagę na:

konsekwentne serwowanie plików DCV przez wszystkie węzły CDN,
spójne odpowiedzi z każdego serwera za load balancerem,
jednoznaczne i zsynchronizowane aktualizacje rekordów u wielu dostawców DNS.

Zaawansowane tematy – certyfikaty wielodomenowe i wildcard

Certyfikaty wielodomenowe (UCC/SAN)

Chronią wiele nazw w jednym certyfikacie. Każda domena/SAN wymaga osobnego potwierdzenia DCV – można łączyć metody (np. część przez e‑mail, część przez DNS).

Przykład: dla example.com, www.example.com, support.example.com, api.example.com należy wykonać DCV dla każdej pozycji z osobna.

Certyfikaty wildcard i subdomeny

Wildcard (*.example.com) chroni wszystkie subdomeny jednego poziomu, ale nie obejmuje samego example.com ani subdomen trzeciego poziomu (np. mail.support.example.com).

Najważniejsze zasady pokrycia wildcard:

obejmuje subdomeny pierwszego poziomu (np. mail.example.com),
nie obejmuje domeny bazowej drugiego poziomu (example.com),
nie obejmuje subdomen głębszych niż jeden poziom.

DCV dla wildcard jest dozwolone wyłącznie metodami DNS (TXT lub CNAME).

Przyszłość weryfikacji domeny i trendy branżowe

Przyspieszająca automatyzacja

Skracające się okresy ważności (do 47 dni) czynią ręczne odnowienia niepraktycznymi. Organizacje powinny wdrożyć ACME i procesy IaC/DevOps dla certyfikatów.

Wzmocnione bezpieczeństwo poprzez weryfikację wieloperspektywiczną

MPIC podnosi poprzeczkę bezpieczeństwa, wymagając zgodnych wyników z wielu niezależnych punktów w sieci.

Ciągłe doskonalenie standardów

CA/Browser Forum stale doskonali wytyczne, przyspiesza wycofywanie przestarzałych praktyk (np. WHOIS) i wprowadza nowe wymagania bezpieczeństwa. Bycie na bieżąco z normami to klucz do bezproblemowej emisji i odnowień.