Ein Zertifikat gilt nicht für „eine Website“, sondern für bestimmte Namen. Welche das sind, steht in der Erweiterung Subject Alternative Name (SAN). Dort können mehrere Domains stehen oder ein Platzhalter wie *.beispiel.de, der viele Subdomains auf einmal abdeckt. Dieser Artikel erklärt, wie die Namensliste funktioniert, was Multi-Domain- und Wildcard-Zertifikate sind, welche Regeln für Platzhalter gelten und wann welche Lösung sinnvoll ist.
Subject Alternative Name: die Namensliste im Zertifikat
Früher stand der Domainname im Feld Common Name (CN) des Inhabers. Weil dort nur ein Name Platz hat, kam die Erweiterung Subject Alternative Name hinzu, die beliebig viele Einträge erlaubt. Seit 2017 werten Browser nur noch die SAN-Liste aus; ein Name, der nur im CN steht, führt in Chrome zum Fehler NET::ERR_CERT_COMMON_NAME_INVALID. Wo die Erweiterung im Zertifikat steht, zeigt X.509-Zertifikat einfach erklärt.
Die SAN-Liste kann verschiedene Arten von Namen enthalten:
- DNS-Namen wie www.techuni.de, der Normalfall bei Websites,
- IP-Adressen, etwa für Geräte ohne Domainnamen; öffentliche CAs stellen dafür nur selten Zertifikate aus,
- E-Mail-Adressen bei E-Mail-Zertifikaten,
- URIs bei manchen Maschinen-Identitäten.
Das Zertifikat von techuni.de enthält zwei DNS-Namen: techuni.de und www.techuni.de. Beim Verbindungsaufbau vergleicht der Browser den Namen aus der Adresszeile mit dieser Liste. Umlaut-Domains stehen dort in der ASCII-Schreibweise Punycode: aus bücher.de wird xn--bcher-kva.de.
Mehrere Domains in einem Zertifikat
Ein Multi-Domain-Zertifikat (auch SAN- oder UCC-Zertifikat genannt) enthält mehrere unterschiedliche Domains, etwa beispiel.de, beispiel.at und beispiel-shop.de. Let’s Encrypt erlaubt bis zu 100 Namen pro Zertifikat. Das ist praktisch, wenn ein Server viele Domains bedient, hat aber Nebenwirkungen:
- Jeder Besucher kann im Zertifikat alle anderen Domains lesen.
- Kommt eine Domain hinzu oder fällt weg, muss das ganze Zertifikat neu ausgestellt werden.
- Scheitert die Prüfung einer einzigen Domain, scheitert der ganze Antrag.
Wie man Namen in den Antrag schreibt, zeigt Schlüsselpaar und CSR erstellen.
Wildcard-Zertifikate: die Regeln
Ein Wildcard-Zertifikat enthält einen Namen mit Sternchen, etwa *.beispiel.de. Das Sternchen steht für genau eine beliebige Beschriftung. Die Regeln aus den Baseline Requirements und RFC 9525 (Nachfolger von RFC 6125):
- Das Sternchen darf nur ganz links stehen und muss die ganze Beschriftung ersetzen: *.beispiel.de ist erlaubt, www.*.beispiel.de oder w*.beispiel.de nicht.
- Es deckt genau eine Ebene ab.
- Für öffentliche Endungen wie *.de oder *.co.uk wird nie ein Wildcard ausgestellt.
- EV-Zertifikate dürfen keine Wildcards enthalten.
Was ein Wildcard abdeckt und was nicht
Für ein Zertifikat mit dem Namen *.beispiel.de gilt:
- www.beispiel.de: ja
- shop.beispiel.de: ja
- beispiel.de: nein, die Domain selbst hat keine Beschriftung links, die das Sternchen ersetzen könnte.
- test.shop.beispiel.de: nein, das sind zwei Ebenen.
- www.beispiel.com: nein, andere Domain.
Deshalb enthalten Wildcard-Zertifikate fast immer zusätzlich die Domain selbst. Ein Beispiel aus den öffentlichen Protokollen: Für techuni.de gibt es ein Zertifikat von Google Trust Services mit den beiden Namen *.techuni.de und techuni.de. Wer auch zweite Ebenen braucht, nimmt einen weiteren Eintrag wie *.shop.beispiel.de auf. Zum Aufbau von Domainnamen siehe wie funktioniert DNS.
Vor- und Nachteile
Ein Wildcard-Zertifikat ist bequem: Neue Subdomains funktionieren sofort, ohne neues Zertifikat, und in den öffentlichen Certificate-Transparency-Protokollen erscheinen die einzelnen Subdomains nicht. Dem stehen Risiken gegenüber:
- Ein Schlüssel für alles: Meist liegt derselbe private Schlüssel auf vielen Servern. Wird er auf einem schlecht gesicherten Testserver gestohlen, kann ein Angreifer sich als jeder andere Server der Domain ausgeben, auch als Mailserver oder Shop.
- Größere Angriffsfläche: Je mehr Kopien eines Schlüssels existieren, desto wahrscheinlicher geht eine verloren.
- Aufwendige Prüfung: Wildcards lassen sich nur über einen DNS-Eintrag validieren, nicht über eine Datei auf dem Webserver.
Faustregel: Für wenige feste Namen sind einzelne Zertifikate oder ein Multi-Domain-Zertifikat besser. Ein Wildcard lohnt sich, wenn ständig neue Subdomains entstehen, etwa bei Plattformen, die jedem Kunden eine eigene Subdomain geben, oder wenn ein vorgeschalteter Dienst die Zertifikate zentral verwaltet. Mit automatischer Ausstellung über ACME sind einzelne Zertifikate heute kaum noch Mehraufwand.
Wildcard-Zertifikate mit Let’s Encrypt
Let’s Encrypt stellt Wildcards seit 2018 kostenlos aus, verlangt aber die DNS-Prüfung (DNS-01): Der ACME-Client muss einen TXT-Eintrag unter _acme-challenge.beispiel.de anlegen. Damit das automatisch klappt, braucht der Client Zugriff auf die DNS-Zone, meist über die Schnittstelle des DNS-Anbieters. Ein Aufruf mit certbot sieht so aus, hier mit einem Plugin für Cloudflare:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini -d beispiel.de -d "*.beispiel.de"
Der Zugangsschlüssel für die DNS-Schnittstelle sollte nur das Ändern von TXT-Einträgen erlauben, denn wer ihn besitzt, kann Zertifikate für die ganze Domain bekommen. Mehr zum Ablauf in ACME und Let’s Encrypt.
Häufige Fragen
Deckt *.beispiel.de auch beispiel.de ab? Nein. Die Domain selbst muss als eigener Name in der SAN-Liste stehen.
Wie viele Namen darf ein Zertifikat haben? Die Regeln nennen keine feste Grenze; Let’s Encrypt erlaubt 100, kommerzielle CAs oft 100 bis 250. Sehr lange Listen machen das Zertifikat größer.
Funktioniert ein Wildcard-Zertifikat für E-Mail-Server? Ja, wenn der Name passt, etwa mail.beispiel.de. Aus Sicherheitsgründen ist ein eigenes Zertifikat für den Mailserver trotzdem besser.
Kann ich ein Zertifikat für eine IP-Adresse bekommen? Bei manchen CAs ja. Let’s Encrypt erlaubt IP-Adressen nur bei kurzlebigen Zertifikaten mit rund sechs Tagen Laufzeit.
Fazit
Die SAN-Erweiterung legt fest, für welche Namen ein Zertifikat gilt, und ist heute das einzige Namensfeld, das Browser prüfen. Multi-Domain-Zertifikate bündeln mehrere Domains, Wildcard-Zertifikate decken genau eine Ebene von Subdomains ab, aber nicht die Domain selbst. Weil ein Wildcard-Schlüssel oft auf vielen Servern liegt, sind einzelne, automatisch erneuerte Zertifikate meist die sicherere Wahl. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.
Quellen und weiterführende Links
- RFC 9525: Service Identity in TLS (IETF)
- Baseline Requirements für TLS-Zertifikate (CA/Browser Forum)
- Challenge-Typen (Let’s Encrypt)
- Rate Limits und Namen pro Zertifikat (Let’s Encrypt)















Neueste Kommentare