Wildcard DNS i certyfikat SSL wildcard: co obejmuje *.example.com

Rekord DNS *.example.com odpowiada za każdą nazwę, która nie istnieje w strefie, na dowolnej głębokości: a.example.com, a nawet a.b.example.com. Nie obejmuje samego example.com ani nazw, które już istnieją. Certyfikat wildcard *.example.com jest bardziej rygorystyczny: obejmuje dokładnie jeden poziom, czyli a.example.com tak, example.com i a.b.example.com nie. Let’s Encrypt wystawia certyfikaty wildcard wyłącznie przez wyzwanie DNS-01.

Co obejmuje gwiazdka: DNS, certyfikat i nginx

Trzy systemy różnie odczytują gwiazdkę, a większość problemów z wildcardami pojawia się właśnie na ich styku. Tabela podsumowuje wyniki testów opisanych niżej.

Główna pułapka to trzeci wiersz: a.b.example.test się rozwiązuje, nginx serwuje stronę, a przeglądarka pokazuje błąd certyfikatu.

Jak działa wildcard w DNS

Zbudowaliśmy strefę z jednym rekordem *, kilkoma jawnymi nazwami i drugim wildcardem dla środowisk podglądu:

$TTL 300
@          SOA  ns1.example.test. hostmaster.example.test. 2026111001 7200 3600 1209600 600
@          NS   ns1.example.test.
@          MX   10 mail.example.test.
; no A record on the apex
www        A    192.0.2.10
mail       A    192.0.2.25
*          A    192.0.2.80
api        A    192.0.2.81
x.dev      A    192.0.2.82
*.preview  A    192.0.2.90

Odpowiedzi serwera autorytatywnego:

$ dig @127.0.23.1 <name> A +norec
a.example.test              NOERROR   192.0.2.80
qwerty123.example.test      NOERROR   192.0.2.80
a.b.example.test            NOERROR   192.0.2.80
x.y.z.example.test          NOERROR   192.0.2.80
example.test                NOERROR   (no answer)
www.example.test            NOERROR   192.0.2.10
dev.example.test            NOERROR   (no answer)
y.dev.example.test          NXDOMAIN
preview.example.test        NOERROR   (no answer)
pr-42.preview.example.test  NOERROR   192.0.2.90
a.nowild.test               NXDOMAIN  (zone without *)

Logikę określa RFC 4592. Serwer szuka najbliższej istniejącej nazwy powyżej zapytania i sprawdza tylko, czy bezpośrednio pod nią jest wildcard. Dla a.b.example.test najbliższą istniejącą nazwą jest example.test, więc odpowiada *.example.test, niezależnie od liczby etykiet w zapytaniu. Stąd zasada, którą wielu administratorów rozumie opacznie: w DNS wildcard nie jest ograniczony do jednego poziomu, w certyfikacie tak.

Jawna nazwa całkowicie blokuje wildcard

Gdy tylko w strefie istnieje www lub api, wildcard przestaje działać dla tej nazwy, dla każdego typu rekordu. Na stanowisku api.example.test ma tylko rekord A, więc zapytania MX lub TXT o tę nazwę zwracają pustą odpowiedź, a nie dane z wildcarda. Apex też zawsze istnieje (są w nim SOA i NS), więc example.test nie otworzy się bez własnego rekordu A, z wildcardem czy bez.

Puste węzły pośrednie (empty non-terminals)

Rekord x.dev sprawia, że dev.example.test istnieje, choć nie ma żadnych rekordów. Wynik pokazuje skutek: dev.example.test dostaje pustą odpowiedź, a y.dev.example.test NXDOMAIN, bo pod dev nie ma wildcarda. *.preview zachowuje się tak samo: po jego dodaniu preview.example.test przestał odpowiadać adresem 192.0.2.80. Gdy usunęliśmy *.preview, obie nazwy wróciły do 192.0.2.80 przez wildcard wyższego poziomu.

NXDOMAIN czy NOERROR

Z wildcardem każda losowa nazwa dostaje NOERROR i adres. Błąd DNS_PROBE_FINISHED_NXDOMAIN znika na subdomenach, a razem z nim sygnał, że nazwa została wpisana z literówką. Bez wildcarda (strefa nowild.test) ta sama nazwa zwraca NXDOMAIN. Jeśli dodajesz nową jawną subdomenę obok istniejącego wildcarda, to jak szybko się pojawi, zależy od TTL rekordów, co wyjaśniamy w poradniku o tym, ile trwa propagacja DNS.

Poczta i TXT: co wildcard robi z MX i SPF

Gdy wildcard zawiera tylko rekord A, zapytanie MX o a.example.test zwraca pustą odpowiedź. Wygląda to jak „tu nie ma poczty”. Jednak według RFC 5321 serwer pocztowy, który nie znajdzie MX, sięga po rekord A, więc każda losowa subdomena wygląda jak host pocztowy. Dla subdomen, które nigdy nie odbierają poczty, dodaliśmy do wildcarda null MX (RFC 7505) i ścisły SPF:

; added: @ A 192.0.2.10 / * MX 0 . / * TXT "v=spf1 -all"
a.example.test         MX   0 .
a.example.test         TXT  "v=spf1 -all"
api.example.test       MX   NOERROR (no answer)
api.example.test       TXT  NOERROR (no answer)
_dmarc.a.example.test  TXT  "v=spf1 -all"

$ named-checkzone example.test bad.zone      # + "* CNAME www.example.test."
dns_master_load: bad.zone:23: *.example.test: CNAME and other data

Trzy wnioski. Jawne nazwy (api, www) nie są chronione przez wildcard i potrzebują własnego null MX i własnego SPF. Wildcard TXT odpowiada pod każdą nieistniejącą nazwą, nawet _dmarc.a.example.test czy _acme-challenge.shop.example.test, więc nigdy nie umieszczaj tam kodów weryfikacyjnych usług. Wreszcie wildcard CNAME nie może współistnieć z innymi rekordami przy *: BIND odmówił załadowania takiej strefy.

Wildcard SSL: dokładnie jeden poziom

Wystawiliśmy certyfikaty testowe z różnymi zestawami SAN i sprawdziliśmy każdą nazwę przez openssl i curl:

$ openssl s_client -connect 127.0.23.1:8441 -servername H -verify_hostname H -CAfile ca.pem
$ curl --cacert ca.pem --resolve H:8441:127.0.23.1 https://H:8441/

SAN: DNS:*.example.test
a.example.test              Verify return code: 0 (ok)                  HTTP 200
example.test                Verify return code: 62 (hostname mismatch)
a.b.example.test            Verify return code: 62 (hostname mismatch)
curl: (60) SSL: no alternative certificate subject name matches target host name 'a.b.example.test'

SAN: DNS:example.test, DNS:*.example.test
example.test                Verify return code: 0 (ok)                  HTTP 200
a.example.test              Verify return code: 0 (ok)                  HTTP 200
a.b.example.test            Verify return code: 62 (hostname mismatch)

SAN: DNS:example.test, DNS:*.example.test, DNS:*.preview.example.test
pr-42.preview.example.test  Verify return code: 0 (ok)                  HTTP 200

To zgodne z zasadami branży. Baseline Requirements CA/Browser Forum (wersja 2.3.1, obowiązująca od 4 października 2026) definiują nazwę domeny wildcard jako ciąg zaczynający się od *., po którym następuje pełna nazwa domeny, i zabraniają certyfikatów dla sufiksów publicznych, takich jak *.co.uk. RFC 9525 dodaje, że gwiazdka może być tylko całą skrajnie lewą etykietą i pasuje dokładnie do jednej etykiety. Jeszcze trzy wyniki z testów:

• Certyfikat *.*.example.test (żadne publiczne CA by go nie wystawiło) nie zadziałał ani dla a.b.example.test, ani dla x.y.example.test.
• Częściowy wzorzec shop*.example.test openssl zaakceptował dla shop1.example.test, ale curl go odrzucił. Klienci się nie zgadzają, więc lepiej unikać takich nazw.
• Jeśli certyfikat ma SAN, CN jest ignorowany: certyfikat z CN *.example.test i niezwiązanym SAN zakończył się błędem 62.

Apex i jego subdomeny potrzebują więc obu nazw w jednym certyfikacie, a każdy głębszy poziom potrzebuje własnego wildcarda. Przeglądarki zgłaszają takie niezgodności komunikatem „To nie jest prywatne połączenie” z kodem ERR_CERT_COMMON_NAME_INVALID.

Wildcard Let’s Encrypt: tylko DNS-01

FAQ Let’s Encrypt mówi wprost: wystawienie wildcarda wymaga wyzwania DNS-01. Strona o typach wyzwań (zaktualizowana 12 lutego 2026) dodaje, że HTTP-01 i TLS-ALPN-01 nie nadają się do wildcardów, a DNS-01 ma sens tylko wtedy, gdy dostawca DNS udostępnia API do automatycznych zmian. Nazwę _acme-challenge można delegować do innej strefy rekordem CNAME lub NS.

Na naszym stanowisku z Pebble żądanie *.site.example.com metodą webroot zakończyło się komunikatem Certbota Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. Z DNS-01 jedno zamówienie objęło zarówno apex, jak i wildcard, a _acme-challenge.wild.example.com zawierał jednocześnie dwie wartości TXT; obie musiały pozostać do końca walidacji. Więcej o wyzwaniach i błędach w naszym poradniku o darmowym certyfikacie SSL Let’s Encrypt. Płatne certyfikaty wildcard i ich ceny porównujemy w artykule ile kosztuje certyfikat SSL.

Na hostingu współdzielonym wszystko zależy od tego, gdzie obsługiwana jest strefa DNS i czy panel sterowania obsługuje DNS-01. Zanim zbudujesz projekt wokół wildcarda, zapytaj wsparcie swojego dostawcy, czy taki certyfikat jest dostępny w Twoim planie.

nginx: wildcard w server_name i zduplikowana treść

Popularny poradnik mówi „skieruj wszystkie subdomeny na stronę”. Oto efekt, gdy w DNS jest już *:

server {
    listen 80;
    server_name example.test *.example.test;
    root /srv/cw23/www/main;
}

$ curl -H "Host: <name>" http://127.0.23.1/
example.test            200  32 bytes  md5 d8c92a07
www.example.test        200  32 bytes  md5 d8c92a07
wwww.example.test       200  32 bytes  md5 d8c92a07
random123.example.test  200  32 bytes  md5 d8c92a07
a.b.example.test        200  32 bytes  md5 d8c92a07

Każda literówka i każda wymyślona nazwa zwraca tę samą stronę ze statusem 200. Wyszukiwarki, które znajdą takie adresy URL w linkach, widzą pełne kopie serwisu, a atakujący dostaje wiarygodny adres w Twojej domenie. Zwróć uwagę, że *.example.test w nginx pasuje na dowolnej głębokości, jak podaje dokumentacja nginx, więc również a.b.example.test trafił na stronę.

Poprawiona konfiguracja, którą przetestowaliśmy: nieznane nazwy są zamykane, klienci SaaS (tenanci) obsługiwani są tylko na jednym poziomie, a nieistniejący tenant dostaje 404.

# 1) catch-all: unknown Host / SNI -> closed connection
server {
  listen 80 default_server;
  listen 443 ssl default_server;
  server_name _;
  ssl_reject_handshake on;          # nginx >= 1.19.4: no certificate for unknown names
  return 444;                       # or: return 404;
}
# 2) the main site: only the names you really use
server {
  listen 80;
  listen 443 ssl;
  server_name example.test www.example.test;
  ssl_certificate     /srv/cw23/ca/both.pem;
  ssl_certificate_key /srv/cw23/ca/both.key;
  root /srv/cw23/www/main;
}
# 3) SaaS tenants: exactly one label, unknown tenant -> 404
server {
  listen 80;
  listen 443 ssl;
  server_name ~^(?<tenant>[a-z0-9-]+)\.example\.test$;
  ssl_certificate     /srv/cw23/ca/both.pem;
  ssl_certificate_key /srv/cw23/ca/both.key;
  root /srv/cw23/www/tenants/$tenant;
  location / { try_files $uri $uri/index.html =404; }
}

example.test, www.example.test  200  main site
acme.example.test               200  tenant acme
wwww.example.test               404
a.b.example.test                curl: (52) Empty reply from server
a.b.example.test (HTTPS)        curl: (35) ... tlsv1 unrecognized name

Jeśli nie masz subdomen klientów, prościej przekierować wszystkie nieznane nazwy na główny adres. W nginx dokładna nazwa wygrywa z wildcardem, więc www działa jak zwykle:

server { listen 80; server_name *.example.test; return 301 https://www.example.test$request_uri; }

wwww.example.test   301 https://www.example.test/page?x=1
a.b.example.test    301 https://www.example.test/page?x=1

Przy HTTPS pamiętaj, że a.b.example.test i tak dostanie błąd certyfikatu przed jakimkolwiek przekierowaniem, bo certyfikat jest sprawdzany, zanim serwer odpowie. Gotowe reguły znajdziesz w artykule o przekierowaniu 301 w .htaccess i Nginx.

Kiedy wildcard jest naprawdę potrzebny

• WordPress Multisite na subdomenach. Nowe witryny w sieci powstają bez ruszania DNS, więc rekord wildcard i certyfikat dla apexu oraz *. mają sens.
• SaaS z adresami klientów, takimi jak acme.example.com. Wildcard w DNS plus sprawdzanie nazwy w aplikacji lub w nginx, jak w konfiguracji powyżej.
• Środowiska podglądu dla gałęzi lub pull requestów. Daj im osobny poziom, *.preview.example.com, z certyfikatem dokładnie dla niego: *.example.com nie obejmuje pr-42.preview.example.com.

Jeśli masz kilka subdomen znanych z góry, zrezygnuj z wildcarda: jawne rekordy i certyfikat z listą nazw są prostsze i bezpieczniejsze.

Tabela decyzyjna

W planach hostingowych RichHost darmowe certyfikaty Let’s Encrypt są dostępne we własnym panelu sterowania z asystentem AI. Aby sprawdzić, czy dla Twojej domeny dostępny jest certyfikat wildcard i rekord wildcard, napisz do wsparcia: działa w godzinach 10:00 do 20:00 czasu kijowskiego i odpowiada w około 30 minut.

FAQ

Czy certyfikat *.example.com obejmuje example.com?

Nie. Dodaj apex jako drugą nazwę w tym samym certyfikacie: na stanowisku certyfikat z example.test i *.example.test był ważny dla obu.

Czy do certyfikatu wildcard potrzebny jest rekord DNS *?

Nie, to niezależne rzeczy. Certyfikat tylko autoryzuje nazwy; walidacja DNS-01 wymaga rekordu TXT pod _acme-challenge.example.com, a nie wildcarda.

Czy wildcard DNS szkodzi SEO?

Sam rekord nie. Problemem jest serwer WWW, który dla każdej nazwy odpowiada 200 z tą samą treścią. Zamknij nieznane nazwy kodem 404 lub 444 albo przekieruj je na główny adres.

Dlaczego a.b.example.com się otwiera, ale pokazuje błąd certyfikatu?

Wildcard w DNS pasuje na dowolnej głębokości, a certyfikat *.example.com obejmuje tylko jeden poziom. Potrzebujesz osobnego certyfikatu *.b.example.com albo dokładnej nazwy w SAN.