SSL-Zertifikat erstellen — und wann ein Wildcard falsch ist

Ein Zertifikat für eine Domain zu bekommen kostet heute nichts und dauert wenige Minuten. Die Frage, die davor steht, wird trotzdem meistens falsch beantwortet: ein Zertifikat je Name, oder ein Wildcard für alles?

Die Antwort hat weniger mit Bequemlichkeit zu tun, als es aussieht.

Was ein Wildcard abdeckt — und was nicht#

Ein Wildcard-Zertifikat lautet auf *.beispiel.de. Der Platzhalter steht für genau eine Ebene, und zwar die äußerst linke.

Die letzten beiden Zeilen sind die, an denen sich Leute verrechnen. Der Standard ist an dieser Stelle eindeutig: Ein Client soll nichts anderes als das äußerst linke Label vergleichen, und der Platzhalter darf auch nur dort stehen.

Die nackte Domain ist nicht dabei. Wer beispiel.de ohne Subdomain ausliefert, braucht sie zusätzlich im Zertifikat — bei den meisten Ausstellern geht das als zweiter Name 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 der 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 der Schlüssel liegt, muss deshalb so gut geschützt sein wie die am besten geschützte Subdomain, die er abdeckt — und in der Praxis ist es umgekehrt: Das Wildcard liegt auch auf dem Testsystem, das seit zwei Jahren niemand aktualisiert hat.

Dazu kommt: Ein Wildcard hebt jede Trennung auf. Wer intern.beispiel.de vom öffentlichen Auftritt trennen will, hat mit einem gemeinsamen Schlüssel genau das nicht getan.

Das RFC formuliert seine Empfehlung entsprechend zurückhaltend — Platzhalter sollen in ausgestellten Zertifikaten grundsätzlich nicht verwendet und von Clients nur aus Rückwärtskompatibilität akzeptiert werden.

Wann es trotzdem richtig ist#

Es gibt einen guten Fall, und er ist klar umrissen: wenn die Namen im Voraus nicht bekannt sind.

• Ein Dienst, bei dem jeder Kunde eine eigene Subdomain bekommt.
• Ein System, das Vorschauumgebungen je Zweig anlegt.
• Interne Umgebungen mit vielen kurzlebigen Namen.

In allen anderen Fällen — drei, fünf, zwölf feste Subdomains — ist ein Zertifikat mit mehreren Namen die bessere Wahl. Es deckt genau die Namen ab, die es soll, und der Schlüssel jedes Systems trägt nur, was dieses System braucht.

Der Weg zum Zertifikat#

Der praktische Teil ist kurz, weil ihn die Automatisierung übernimmt.

Beim Hoster nachsehen, ob es schon da ist. Die meisten Anbieter richten Zertifikate von sich aus ein und erneuern sie automatisch. Für den Hetzner-Fall steht der Weg unter SSL-Zertifikat bei Hetzner.

Sonst über einen ACME-Client. Certbot, acme.sh, Caddy oder der eingebaute Mechanismus des Webservers. Er beantragt, weist die Verfügungsgewalt über die Domain nach und erneuert selbstständig.

Für ein Wildcard geht das nur über DNS. Der Nachweis per HTTP-Datei reicht dafür nicht aus; es braucht einen TXT-Eintrag, den der Client setzt. Das heißt in der Praxis: Der Client braucht Zugriff auf die DNS-Verwaltung, meist über einen API-Schlüssel. Ob dieser Schlüssel auf dem Webserver liegen soll, ist eine eigene Frage — und der zweite Grund, es sich zu überlegen.

Ein selbst signiertes Zertifikat ist kein Sparmodell, sondern etwas anderes. Es verschlüsselt, aber kein Browser vertraut ihm. Für interne Werkzeuge hinter einem Passwort ist das vertretbar, für alles Öffentliche nicht.

Was nicht hilft#

Ein Zertifikat kaufen, weil es „mehr Sicherheit" verspricht. Die Verschlüsselung ist bei einem kostenlosen Zertifikat dieselbe. Bezahlte unterscheiden sich in der Prüftiefe der Organisation und in der Haftung, nicht in der Stärke.

Die Laufzeit als Vorteil sehen. Kurze Laufzeiten sind der Grund, warum die Erneuerung automatisiert ist — und Automatisierung ist der Unterschied zwischen einem funktionierenden Zertifikat und einem, das an einem Sonntag abläuft.

Nach der Einrichtung nicht nachsehen. Ein Zertifikat kann gültig sein und die Seite trotzdem falsch ausgeliefert werden: unvollständige Kette, fehlende Weiterleitung von HTTP, gemischte Inhalte. Das prüft der kostenlose SSL-Check, und was der Host sonst preisgibt, zeigt der Security-Scan.

Die Entscheidung in einem Satz#

Feste, bekannte Namen: ein Zertifikat mit mehreren Namen. Unbekannte oder ständig wechselnde Namen: Wildcard, aber mit einem DNS-Schlüssel, der nicht auf jedem Webserver liegt.

Quellen#

• RFC 6125, Abschnitt 6.4.3 — Wildcard-Vergleich — der Platzhalter darf nur das äußerst linke Label bilden, und es wird nichts anderes als dieses Label verglichen
• RFC 6125, Abschnitt 7.2 — Sicherheitsbetrachtung zu Wildcards — Platzhalter sollen in ausgestellten Zertifikaten nicht verwendet werden
• Let's Encrypt — häufige Fragen — Laufzeit, Automatisierung und die DNS-Bedingung für Wildcards