Wildcard DNS a wildcard SSL certifikát: co pokrývá *.example.com

DNS záznam *.example.com odpovídá za každé jméno, které v zóně neexistuje, a to v libovolné hloubce: a.example.com i a.b.example.com. Nepokrývá samotné example.com ani jména, která už existují. Wildcard certifikát *.example.com je přísnější: pokrývá přesně jednu úroveň, tedy a.example.com ano, example.com a a.b.example.com ne. Let’s Encrypt vydává wildcard certifikáty pouze přes výzvu DNS-01.

Co pokrývá hvězdička: DNS, certifikát a nginx

Tři systémy čtou hvězdičku různě a většina problémů s wildcardem vzniká právě tam, kde se setkávají. Tabulka shrnuje výsledky testů popsaných níže.

Hlavní past je ve třetím řádku: a.b.example.test se přeloží, nginx stránku obslouží a prohlížeč ukáže chybu certifikátu.

Jak funguje wildcard v DNS

Postavili jsme zónu s jedním záznamem *, několika explicitními jmény a druhým wildcardem pro náhledová prostředí:

$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

Odpovědi autoritativního serveru:

$ 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 *)

Logiku určuje RFC 4592. Server najde nejbližší existující jméno nad dotazem a zkontroluje jen to, zda přímo pod ním existuje wildcard. Pro a.b.example.test je nejbližším existujícím jménem example.test, takže odpovídá *.example.test, bez ohledu na to, kolik návěští dotaz má. Z toho plyne pravidlo, které mnoho správců chápe špatně: v DNS wildcard není omezen na jednu úroveň, u certifikátu ano.

Explicitní jméno wildcard úplně zablokuje

Jakmile v zóně existuje www nebo api, wildcard se na toto jméno přestane uplatňovat, a to pro jakýkoli typ záznamu. Na stendu má api.example.test jen záznam A, proto dotazy MX nebo TXT na něj vracejí prázdnou odpověď, ne data z wildcardu. Apex také vždy existuje (jsou v něm SOA a NS), takže example.test se bez vlastního záznamu A nenačte, ať už wildcard máte, nebo ne.

Prázdné mezilehlé uzly (empty non-terminals)

Záznam x.dev způsobí, že dev.example.test existuje, i když nemá žádné záznamy. Výstup ukazuje důsledek: dev.example.test dostane prázdnou odpověď a y.dev.example.test NXDOMAIN, protože pod dev žádný wildcard není. *.preview se chová stejně: po jeho přidání přestal preview.example.test odpovídat adresou 192.0.2.80. Když jsme *.preview odebrali, obě jména se přes horní wildcard vrátila k 192.0.2.80.

NXDOMAIN, nebo NOERROR

S wildcardem dostane jakékoli náhodné jméno NOERROR a adresu. Chyba DNS_PROBE_FINISHED_NXDOMAIN na subdoménách zmizí a s ní i signál, že jméno bylo napsáno s překlepem. Bez wildcardu (zóna nowild.test) vrátí stejné jméno NXDOMAIN. Pokud k existujícímu wildcardu přidáte novou explicitní subdoménu, rychlost, s jakou se objeví, závisí na TTL záznamů, jak vysvětlujeme v návodu, jak dlouho trvá propagace DNS.

Pošta a TXT: co wildcard udělá s MX a SPF

Když wildcard obsahuje jen záznam A, dotaz MX na a.example.test vrátí prázdnou odpověď. Vypadá to jako „tady žádná pošta není“. Podle RFC 5321 však poštovní server, který nenajde MX, použije záznam A, takže každá náhodná subdoména vypadá jako poštovní hostitel. Pro subdomény, které nikdy poštu nepřijímají, jsme do wildcardu přidali null MX (RFC 7505) a přísné 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

Tři závěry. Explicitní jména (api, www) wildcard nechrání a potřebují vlastní null MX a vlastní SPF. Wildcard TXT odpovídá pod jakýmkoli neexistujícím jménem, dokonce i _dmarc.a.example.test nebo _acme-challenge.shop.example.test, proto tam nikdy nedávejte ověřovací kódy služeb. A wildcard CNAME nemůže u * existovat vedle jiných záznamů: BIND odmítl takovou zónu načíst.

Wildcard SSL: přesně jedna úroveň

Vydali jsme testovací certifikáty s různými sadami SAN a každé jméno ověřili pomocí openssl a 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 odpovídá pravidlům odvětví. Baseline Requirements CA/Browser Fora (verze 2.3.1, platná od 4. října 2026) definují wildcard doménové jméno jako řetězec začínající *., za nímž následuje plně kvalifikované doménové jméno, a zakazují certifikáty pro veřejné sufixy jako *.co.uk. RFC 9525 doplňuje, že hvězdička smí být jen celým nejlevějším návěštím a odpovídá právě jednomu návěští. Další tři zjištění ze stendu:

• Certifikát *.*.example.test (žádná veřejná CA by ho nevydala) selhal pro a.b.example.test i pro x.y.example.test.
• Částečný vzor shop*.example.test openssl pro shop1.example.test přijal, curl ho ale odmítl. Klienti se neshodnou, takovým jménům se proto vyhněte.
• Pokud má certifikát SAN, CN se ignoruje: certifikát s CN *.example.test a nesouvisejícím SAN selhal s chybou 62.

Apex a jeho subdomény tedy potřebují obě jména v jednom certifikátu a každá hlubší úroveň potřebuje vlastní wildcard. Prohlížeče takové neshody hlásí jako „Vaše připojení není soukromé“ s kódem ERR_CERT_COMMON_NAME_INVALID.

Wildcard od Let’s Encrypt: jen DNS-01

FAQ Let’s Encrypt to říká jasně: vydání wildcardu musí používat výzvu DNS-01. Stránka o typech výzev (aktualizovaná 12. února 2026) dodává, že HTTP-01 a TLS-ALPN-01 pro wildcardy použít nelze a že DNS-01 má smysl jen tehdy, když váš poskytovatel DNS nabízí API pro automatické změny. Jméno _acme-challenge můžete delegovat do jiné zóny záznamem CNAME nebo NS.

Na našem stendu s Pebble skončila žádost o *.site.example.com metodou webroot hláškou Certbotu Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. S DNS-01 pokryla jedna objednávka apex i wildcard a _acme-challenge.wild.example.com obsahoval současně dvě hodnoty TXT; obě musely zůstat až do konce validace. Více o výzvách a chybách najdete v našem návodu na SSL zdarma od Let’s Encrypt. Placené wildcard certifikáty a jejich ceny porovnáváme v článku cena SSL certifikátu.

Na sdíleném hostingu vše závisí na tom, kde je DNS zóna obsluhována a zda ovládací panel umí DNS-01. Než postavíte projekt na wildcardu, zeptejte se podpory svého poskytovatele, zda je takový certifikát ve vašem tarifu dostupný.

nginx: wildcard v server_name a duplicitní obsah

Běžný návod radí „nasměrujte všechny subdomény na web“. Takhle to dopadne, když DNS už obsahuje *:

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ždý překlep a každé vymyšlené jméno vrátí stejnou stránku se stavem 200. Vyhledávače, které takové URL najdou v odkazech, vidí úplné kopie webu, a útočník získá věrohodnou URL na vaší doméně. Všimněte si, že *.example.test v nginx odpovídá libovolné hloubce, jak uvádí dokumentace nginx, takže na web se dostal i a.b.example.test.

Opravená konfigurace, kterou jsme otestovali: neznámá jména se zavírají, SaaS klienti (tenanti) se obsluhují jen na jedné úrovni a neexistující tenant dostane 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

Pokud subdomény pro klienty nemáte, je jednodušší přesměrovat všechna neznámá jména na hlavní adresu. V nginx má přesné jméno přednost před wildcardem, takže www funguje jako obvykle:

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

U HTTPS mějte na paměti, že a.b.example.test dostane chybu certifikátu ještě před jakýmkoli přesměrováním, protože certifikát se kontroluje dřív, než server odpoví. Hotová pravidla najdete v článku o přesměrování 301 v .htaccess a Nginx.

Kdy wildcard opravdu potřebujete

• WordPress Multisite na subdoménách. Nové weby v síti vznikají, aniž by kdokoli sahal do DNS, takže wildcard záznam a certifikát pro apex a *. dávají smysl.
• SaaS s adresami zákazníků jako acme.example.com. Wildcard v DNS a k tomu kontrola jména v aplikaci nebo v nginx, jako v konfiguraci výše.
• Náhledová prostředí pro větve nebo pull requesty. Dejte jim samostatnou úroveň, *.preview.example.com, s certifikátem přesně pro ni: *.example.com nepokrývá pr-42.preview.example.com.

Pokud máte jen pár předem známých subdomén, wildcard vynechte: explicitní záznamy a certifikát se seznamem jmen jsou jednodušší a bezpečnější.

Rozhodovací tabulka

V hostingových tarifech RichHost jsou bezplatné certifikáty Let’s Encrypt dostupné ve vlastním ovládacím panelu s asistentem AI. Zda je pro vaši doménu dostupný wildcard certifikát a wildcard záznam, zjistíte u podpory: pracuje od 10:00 do 20:00 kyjevského času a odpovídá zhruba do 30 minut.

Časté otázky

Pokrývá certifikát *.example.com také example.com?

Ne. Přidejte apex jako druhé jméno do stejného certifikátu: na stendu byl certifikát s example.test a *.example.test platný pro obě jména.

Potřebuji pro wildcard certifikát DNS záznam *?

Ne, jedno na druhém nezávisí. Certifikát jen autorizuje jména; validace DNS-01 potřebuje záznam TXT na _acme-challenge.example.com, ne wildcard.

Škodí wildcard DNS SEO?

Samotný záznam ne. Problém je webový server, který na jakékoli jméno odpoví 200 se stejným obsahem. Neznámá jména uzavřete kódem 404 nebo 444, nebo je přesměrujte na hlavní adresu.

Proč se a.b.example.com načte, ale ukáže chybu certifikátu?

Wildcard v DNS platí v libovolné hloubce, kdežto certifikát *.example.com pokrývá jen jednu úroveň. Potřebujete samostatný certifikát *.b.example.com nebo přesné jméno v SAN.