SSL-Zertifikat erstellen: wann ein Wildcard falsch ist

Ob *.beispiel.de oder drei einzelne Namen: Das ist die Frage, die vor dem Zertifikat steht, und sie wird meistens aus Bequemlichkeit beantwortet. Die Ausstellung selbst ist dagegen kein Thema mehr. Sie kostet nichts, dauert Minuten und läuft automatisch, wenn man sie einmal eingerichtet hat.

Was ein Wildcard abdeckt#

Ein Wildcard-Zertifikat lautet auf *.beispiel.de. Der Platzhalter steht für eine einzige Ebene, die äußerst linke (RFC 6125, Abschnitt 6.4.3).

Die nackte Domain ist nicht dabei. Wer beispiel.de ohne Subdomain ausliefert, braucht sie zusätzlich im Zertifikat, bei den meisten Ausstellern als zweiten Namen im selben Zertifikat.

Warum ein Wildcard oft die schlechtere Wahl ist#

Ein Zertifikat besteht aus einem öffentlichen Teil und einem privaten Schlüssel. Wer den privaten Schlüssel hat, kann sich als jeder Name ausgeben, auf den das Zertifikat lautet. Bei einem Wildcard heißt das: Ein kompromittierter Schlüssel deckt alle Subdomains ab. Der Server, auf dem er liegt, müsste so gut geschützt sein wie die am besten geschützte Subdomain. Üblich ist das Gegenteil: Dasselbe Wildcard liegt auch auf dem Testsystem, das seit zwei Jahren niemand aktualisiert hat.

Dazu hebt ein Wildcard jede Trennung auf. Wer intern.beispiel.de vom öffentlichen Auftritt trennen will, hat das mit einem gemeinsamen Schlüssel nicht getan. RFC 6125 empfiehlt in Abschnitt 7.2, Platzhalter in ausgestellten Zertifikaten gar nicht zu verwenden; Clients sollen sie nur aus Rückwärtskompatibilität akzeptieren.

Richtig ist ein Wildcard, wenn die Namen im Voraus nicht bekannt sind: ein Dienst mit einer Subdomain je Kunde, Vorschauumgebungen je Entwicklungszweig, interne Umgebungen mit vielen kurzlebigen Namen. Für drei, fünf oder zwölf feste Subdomains ist ein Zertifikat mit mehreren Namen die bessere Wahl.

So sieht ein solches Zertifikat aus#

In eigener Sache das Zertifikat dieser Seite, am 03.10.2026 mit openssl abgefragt:

openssl s_client -connect www.cyberscale.io:443 -servername www.cyberscale.io </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates -subject -ext subjectAltName

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Aug 22 07:00:08 2026 GMT
notAfter=Nov 20 07:00:07 2026 GMT
subject=CN=cyberscale.io
X509v3 Subject Alternative Name:
    DNS:cyberscale.io, DNS:www.cyberscale.io

Zwei Namen, kein Platzhalter, 90 Tage Laufzeit, ausgestellt von Let's Encrypt und vom Hoster automatisch erneuert. Mehr braucht eine Website mit einer Hauptdomain und www nicht.

Wer in Tirol was einsetzt#

Dieselbe Abfrage habe ich am 03.10.2026 für die 140 Domains aus meiner Akquise-Liste (Tiroler Betriebe und Tourismusverbände) gemacht, nur den TLS-Handshake, kein HTTP. 131 lieferten ein Zertifikat. Nur Summen, keine Namen:

Zwei Drittel laufen also auf dem kostenlosen Aussteller mit kurzer Laufzeit. Die 17 mit einem Jahr Laufzeit sind der Fall, in dem jemand das Ablaufdatum im Kalender haben muss. Let's Encrypt hat zudem angekündigt, neben den 90 Tagen auch Zertifikate mit sechs Tagen Laufzeit anzubieten; der Trend geht zu kürzer, und kürzer geht nur mit Automatik.

Der Weg zum Zertifikat#

Beim Hoster nachsehen. Viele Anbieter richten Zertifikate von sich aus ein und erneuern sie automatisch; bei Netlify, wo diese Seite liegt, ist das der Fall. Für Hetzner steht der Weg unter SSL-Zertifikat bei Hetzner.

Sonst über einen ACME-Client. Das Protokoll ist RFC 8555; Clients sind certbot, acme.sh, Caddy oder der eingebaute Mechanismus des Webservers. Der Client beantragt, weist die Verfügungsgewalt über die Domain nach und erneuert selbstständig. Für eine normale Domain reicht der Nachweis über eine Datei unter /.well-known/acme-challenge/ (HTTP-01).

Für ein Wildcard geht das nur über DNS. Es braucht einen TXT-Eintrag, den der Client setzt (DNS-01). Der Client braucht dafür Zugriff auf die DNS-Verwaltung, meist über einen API-Schlüssel. Ob dieser Schlüssel auf dem Webserver liegen soll, ist der zweite Grund, sich das Wildcard zu überlegen.

Ein selbst signiertes Zertifikat verschlüsselt, aber kein Browser vertraut ihm. Für interne Werkzeuge hinter einem Passwort vertretbar, für alles Öffentliche nicht.

Drei Irrtümer#

Ein gekauftes Zertifikat verschlüsselt nicht besser. Bezahlte Zertifikate unterscheiden sich in der Prüftiefe der Organisation und in der Haftung, nicht in der Stärke der Verschlüsselung.

Die lange Laufzeit ist kein Vorteil. Kurze Laufzeiten sind der Grund, warum die Erneuerung automatisiert ist, und Automatisierung ist der Unterschied zwischen einem gültigen Zertifikat und einem, das an einem Sonntag abläuft.

Ein gültiges Zertifikat heißt nicht, dass die Seite richtig ausgeliefert wird. Unvollständige Kette, fehlende Weiterleitung von HTTP, gemischte Inhalte: Das prüft der Security-Scan zusammen mit den Antwort-Headern, zu denen auch HSTS gehört (Security-Header einrichten).

Stand 03.10.2026. Quellen abgerufen und Befehle nachgestellt am selben Tag.