2026-10-30 · RESEARCH · Zespół Offensive Technology

Czy certyfikat wieloznaczny ukrywa Twoje subdomeny?

Czy certyfikat wieloznaczny ukrywa Twoje subdomeny? W większości tak, ale niemal nikt nie używa go w ten sposób. Przeanalizowaliśmy aktualne certyfikaty dla 660 czołowych domen za pomocą tych samych publicznych logów Certificate Transparency, z których może skorzystać każdy, i sklasyfikowaliśmy ujawniane przez nie dane. 63.8% wymienia z nazwy przynajmniej jedną rzeczywistą subdomenę w zwykłych wpisach SAN, bez żadnej ochrony ze strony certyfikatu wieloznacznego. Jedynie 22.9% polega wyłącznie na certyfikacie wieloznacznym, ukrywając strukturę subdomen w sposób, na jaki pozwala ta technologia. Jeśli dodamy do tego 11.1% domen, które stosują oba podejścia naraz, okaże się, że 74.8% aktualnych certyfikatów w czołowych domenach ujawnia konkretną nazwę hosta, niezależnie od tego, czy obejmują one również certyfikat wieloznaczny. Certyfikat wieloznaczny działa dokładnie tak, jak został zaprojektowany. Niemal nikt nie wybiera go jednak z tego powodu.

Dlaczego to decyzja, a nie zwykły domysł

Certyfikaty wieloznaczne oraz SAN (Subject Alternative Name) rozwiązują ten sam problem, czyli zabezpieczenie więcej niż jednej nazwy hosta za pomocą jednego certyfikatu, lecz robią to w zupełnie odmienny sposób. Certyfikat wieloznaczny dopasowuje wzorzec: *.example.com jest poprawny dla każdej pojedynczej nazwy w domenie example.com, bez konieczności ujawniania jej w samym certyfikacie. Z kolei certyfikat SAN wymienia nazwy hostów jawnie, jeden certyfikat może zabezpieczać app.example.com, api.example.com oraz admin.example.com, wpisując całą trójkę w pole SAN. Oba rozwiązania są standardem, oba są wystawiane przez każdy publiczny urząd certyfikacji, a pole Subject certyfikatu nie wskazuje, czy dane podejście było celowym wyborem, czy jedynie przypadkowym skutkiem użytych narzędzi.

Ten przypadek jest zresztą najczęstszym scenariuszem. Bezpłatne, zautomatyzowane wystawianie, z którego korzysta dziś niemal każde wdrożenie, zazwyczaj żąda certyfikatu dla dokładnej nazwy hosta, na którą skonfigurowany jest serwer. Jeśli uruchomisz dziesięć subdomen z dziesięcioma osobnymi, automatycznymi żądaniami, otrzymasz dziesięć certyfikatów SAN, z których każdy zarejestruje własną nazwę, zamiast jednego certyfikatu wieloznacznego obejmującego wszystkie dziesięć. Wybór certyfikatu wieloznacznego to dodatkowy krok, którego większość zespołów nie wykonuje, ponieważ ścieżka domyślna od razu zapewnia działający certyfikat.

Dane: co faktycznie wybiera 660 aktualnych certyfikatów

Dla każdej z 660 czołowych domen posiadających historię w Certificate Transparency pobraliśmy najnowszy certyfikat znajdujący się już w naszej lokalnej pamięci podręcznej (zero nowych zapytań do crt.sh w tym badaniu, wykorzystaliśmy zestaw danych z trzech poprzednich wpisów) i przeanalizowaliśmy ich pola Subject oraz SAN. Każdy certyfikat sklasyfikowaliśmy na podstawie tego, co ujawnia poza standardową, uniwersalną parą czystej domeny i jej adresu www.: sam wpis wieloznaczny bez dodatkowych danych, certyfikat wieloznaczny wraz z nazwanymi hostami, nazwane hosty bez certyfikatu wieloznacznego lub brak obu tych opcji.

Bursztynowe słupki oznaczają ujawnienie konkretnej nazwy hosta na certyfikacie; morskie słupki oznaczają brak ujawnienia. Tylko 22.9% grupy wykorzystującej wyłącznie certyfikaty wieloznaczne oraz 2.3% grupy obejmującej wyłącznie domenę główną, łącznie 25.2% próby, zachowuje nazewnictwo swoich subdomen poza rejestrem publicznym. Pozostałe trzy na cztery domeny ujawniają w tej chwili co najmniej jedną prawdziwą nazwę subdomeny każdemu, kto zagląda do Certificate Transparency.

Rzadko kończy się na jednej nazwie

Gdy certyfikat ujawnia cokolwiek, rzadko ogranicza się to do jednej przypadkowej nazwy hosta. Wśród 494 certyfikatów wymieniających przynajmniej jedną konkretną subdomenę, typowy przypadek zawiera tylko jedną lub dwie, jednak rozkład ma długi ogon: rekordowy certyfikat w próbie wymienia aż 70 unikalnych subdomen, a 20 certyfikatów (4.0% wszystkich ujawniających) zawiera dziesięć lub więcej, z czego 9 wymienia 25 lub więcej. Certyfikat o takiej skali niczego nie ukrywa, przypomina raczej publiczną mapę infrastruktury organizacji, wystawioną w ramach jednego żądania i zapisaną w jednym logu.

Warto zatrzymać się przy tym ostatnim wierszu. Jeden certyfikat w grupie "mieszanej" zawiera 94 unikalne wpisy wieloznaczne na pojedynczym kluczu, obok nazwanych wpisów SAN. Jest to niemal na pewno dostawca platformy lub usług SaaS, który zabezpiecza wiele subdomen klientów lub regionów naraz. To rozwiązanie efektywne operacyjnie. Oznacza jednak także, że w przypadku kradzieży tego jednego klucza prywatnego, jest on ważny jednocześnie dla każdej subdomeny we wszystkich tych 94 wzorcach, zarówno obecnych, jak i przyszłych. Stosowanie certyfikatów wieloznacznych zamienia poufność nazw subdomen na inne ryzyko, jakim jest zakres rażenia w przypadku naruszenia pojedynczego klucza.

Dlaczego nie wszyscy używają certyfikatów wieloznacznych

Skoro certyfikat wieloznaczny ukrywa więcej, dlaczego tylko 22.9% badanej próby korzysta z niego na wyłączność? Istnieje kilka praktycznych powodów, z których żaden z osobna nie jest błędem:

• Automatyzacja domyślnie wymienia nazwy, zamiast używać symboli wieloznacznych. Narzędzia takie jak Certbot żądają certyfikatu dla nazwy hosta, na którą serwer już odpowiada. Uzyskanie certyfikatu wieloznacznego wymaga potwierdzenia kontroli nad domeną za pomocą wyzwania DNS-01, co stanowi dodatkowy krok wymagający dodatkowych narzędzi, często pomijany przy wdrożeniach.
• Certyfikat wieloznaczny obejmuje tylko jeden poziom. *.example.com dopasowuje app.example.com, ale już nie a.app.example.com. Każda rzeczywista hierarchia drugiego poziomu wymaga drugiego certyfikatu wieloznacznego lub nazwanych wpisów, co skłania organizacje ku jawnemu wyliczaniu nazw, nawet jeśli dysponują już certyfikatem wieloznacznym.
• Promień rażenia przy przejęciu klucza jest realny. Pojedynczy klucz prywatny dla certyfikatu wieloznacznego, po ujawnieniu, pozwala podszyć się pod każdą subdomenę, którą obejmuje. Skompromitowany klucz dla pojedynczego hosta dotyczy tylko tej jednej maszyny. Zespoły zarządzające wrażliwymi subdomenami o odrębnej strukturze właścicielskiej wybierają niekiedy certyfikaty imienne specjalnie po to, aby ograniczyć zasięg potencjalnego wycieku, nawet kosztem utraty poufności nazw subdomen.
• Niektóre audyty wymagają jawnego wyszczególnienia zasobów. Część procedur zgodności i inwentaryzacji łatwiej przeprowadzić w oparciu o certyfikat wymieniający każdą chronioną nazwę hosta z osobna niż taki, który deklaruje ochronę wyłącznie za pomocą wzorca.

Jak sprawdzić własną domenę

Zajmuje to mniej niż minutę i wymaga jedynie przeglądarki, ponieważ bazuje na tych samych publicznych rejestrach, z których korzystaliśmy w tym badaniu.

• Wyszukaj swój aktualny certyfikat w crt.sh. Otwórz https://crt.sh/?q=yourdomain.com&output=json i sprawdź pole name_value najnowszego wpisu lub zweryfikuj certyfikat serwera bezpośrednio poleceniem openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name".
• Policz, co faktycznie ujawnia. Pojedynczy wpis *.yourdomain.com bez żadnych innych danych oznacza wyłączne użycie certyfikatu wieloznacznego. Wszystko inne, każdy nazwany host wykraczający poza samą domenę oraz www., jest już publicznie dostępny za pośrednictwem CT, niezależnie od tego, czy posiadasz także certyfikat wieloznaczny w innym miejscu.
• Podejmij świadomą decyzję. Jeśli w Twojej architekturze poufność nazw subdomen liczy się bardziej niż promień rażenia przy kradzieży klucza, przejdź na certyfikat wieloznaczny i proces wystawiania oparty na DNS-01. Jeśli nie, traktuj każdy nazwany wpis SAN jako trwale publiczny i przestań polegać na niejawnej nazwie subdomeny jako formie zabezpieczenia.

Czego te dane nie dowodzą

Uczciwe spojrzenie na ograniczenia, ponieważ liczba podana bez kontekstu to tylko marketing.

• Analizowaliśmy najnowszy certyfikat dla każdej domeny, a nie pełną historię. Domena mogła używać certyfikatu wieloznacznego przez lata i dopiero niedawno dodać nazwany wpis SAN, lub odwrotnie. Jest to obraz bieżącego stanu ujawniania danych, a nie pełnego cyklu życia infrastruktury.
• Nazwany wpis SAN nie dowodzi, że stojąca za nim usługa działa lub jest osiągalna. Klasyfikowaliśmy tekst nazw hostów na certyfikacie, nic więcej. Niektóre z nazwanych subdomen mogą wskazywać na infrastrukturę, która już dawno nie istnieje.
• Próba 660 domen obejmuje duże, uznane serwisy. Ranking najpopularniejszych witryn Tranco faworyzuje organizacje o infrastrukturze na tyle rozbudowanej, że z założenia wymagają więcej niż jednej nazwy hosta. Inna grupa badawcza mogłaby wykazać odmienne proporcje.
• To badanie mierzy ujawnianie danych, a nie podatność na ataki. Znajomość nazwy subdomeny to jedynie faza rozpoznania. To, co atakujący może z tą nazwą zrobić, zależy wyłącznie od tego, co faktycznie działa pod wskazanym adresem.

Często zadawane pytania

Czy certyfikat wieloznaczny ukrywa subdomeny?

Częściowo. Certyfikat wieloznaczny dla *.example.com odnotowuje w logach jedynie sam wzorzec, bez konkretnych etykiet. Jednak w naszej próbie 63.8% aktualnych certyfikatów i tak wymienia prawdziwe subdomeny, a jedynie 22.9% polega wyłącznie na certyfikacie wieloznacznym bez ujawniania jakichkolwiek nazwanych hostów.

Czy subdomeny objęte certyfikatem wieloznacznym mogą nadal pojawiać się w logach Certificate Transparency?

Sam wpis wieloznaczny pojawia się wyłącznie jako wzorzec, a nie konkretna nazwa. Jednak w momencie, gdy oddzielny certyfikat wskaże hosta jawnie, nazwa ta trafia do logów w całości, nawet jeśli funkcjonuje obok istniejącego certyfikatu wieloznacznego. 11.1% badanych tu certyfikatów łączy oba te podejścia.

Jaka jest różnica między certyfikatem wieloznacznym a certyfikatem SAN?

Certyfikat wieloznaczny pokrywa wzorzec *.example.com bez wymieniania jakiejkolwiek subdomeny z nazwy. Certyfikat SAN zawiera jawną listę konkretnych nazw hostów. Zautomatyzowane procesy wystawiania domyślnie generują certyfikaty SAN dla dokładnej nazwy hosta skonfigurowanej na serwerze, dlatego jawne wyliczanie nazw, a nie stosowanie certyfikatów wieloznacznych, jest w praktyce standardem.

Czy certyfikat wieloznaczny jest bezpieczniejszy niż jawne wymienienie każdej subdomeny?

Pod względem poufności nazw subdomen, tak. Jeśli jednak chodzi o promień rażenia przy przejęciu klucza, niekoniecznie: jeden skradziony klucz prywatny certyfikatu wieloznacznego pozwala na podszycie się pod każdą subdomenę, którą obejmuje, podczas gdy skompromitowany klucz pojedynczego hosta dotyczy wyłącznie tej jednej maszyny.

Co się stanie, jeśli klucz prywatny certyfikatu wieloznacznego zostanie skompromitowany?

Atakujący może podszyć się pod dowolną subdomenę pasującą do danego wzorca do momentu, aż certyfikat zostanie odwołany i wymieniony we wszystkich miejscach jego wdrożenia. W naszej próbie jeden z certyfikatów zawierał 94 unikalne wpisy wieloznaczne na pojedynczym kluczu, co w razie wycieku oznacza ogromny zasięg rażenia.

Czy certyfikat wieloznaczny obejmuje subdomeny kolejnych poziomów?

Nie. Wzorzec *.example.com pasuje do a.example.com, ale nie obejmie a.b.example.com. Nazwa drugiego poziomu wymaga własnego certyfikatu wieloznacznego lub jawnego wpisu SAN. To jeden z powodów, dla których organizacje decydują się na wymienianie nazw hostów, nawet jeśli dysponują już certyfikatem wieloznacznym.

W jaki sposób atakujący wykorzystują logi Certificate Transparency do enumeracji subdomen z list SAN?

Każdy certyfikat wystawiony przez publiczny urząd CA jest rejestrowany zgodnie z RFC 6962 i można go bezpłatnie przeszukiwać przez crt.sh. Certyfikat wyliczający nazwy hostów dostarcza atakującemu gotową mapę subdomen, bez potrzeby prowadzenia skanowania.

Czy warto wybrać certyfikat wieloznaczny lub SAN ze względów bezpieczeństwa, a nie tylko dla wygody?

Jeśli zachowanie poufności nazewnictwa subdomen ma znaczenie, certyfikat wieloznaczny jest bezpieczniejszym wyborem domyślnym, choć większość organizacji w badanej próbie nie decyduje się na ten krok. Jeśli decydujesz się na jawne wyliczanie, traktuj każdy wpis SAN jako bezpowrotnie publiczny, a przed przejściem na certyfikat wieloznaczny oceń ryzyko związane z potencjalnym przejęciem klucza.

Warto przeczytać

• Jak logi Certificate Transparency ujawniają wewnętrzne subdomeny Ta sama pamięć podręczna, analiza zawartości: jakie kategorie wewnętrznych nazw hostów faktycznie trafiają do rejestrów, gdy certyfikat ujawnia dane.
• Jak szybko certyfikat pojawia się w logach CT? Te same analizy crt.sh, tym razem pod kątem czasu propagacji, a nie ujawniania danych.
• Czy wymóg 200-dniowych certyfikatów już obowiązuje? Trzecie spojrzenie na tę samą próbę 660 domen: dopuszczalny czas ważności certyfikatów, a nie zawartość ich pól.