Was ist ein Wildcard Zertifikat? Installation, DNS Validierung und Risiken

Was ist ein Wildcard Zertifikat?

Ein Wildcard Zertifikat ist ein einzelnes SSL Zertifikat, das eine Domain und alle ihre Subdomains der ersten Ebene absichert, geschrieben als *.example.com. Der Stern steht für genau ein Label. Somit nutzen shop.example.com und blog.example.com dasselbe Zertifikat, die Hauptdomain müssen Sie jedoch zusätzlich eintragen.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Deshalb stützen wir die technischen Teile auf offizielle Dokumentation und Standards. Jede Quelle verlinken wir im Text, denn so können Sie jeden Schritt selbst prüfen können.

Was SSL ist, erklären wir hier daher nicht noch einmal. Die Grundlagen finden Sie in unserem Ratgeber zu SSL Zertifikat und HTTPS. Dieser Beitrag behandelt nur den Umfang eines Wildcard Zertifikats, die DNS Validierung, den Ablauf der Installation und die Grenzen. Außerdem sagen wir in jedem Abschnitt, was Sie selbst erledigen können und was Sie besser Ihrem Hosting Anbieter überlassen.

Welche Adressen deckt ein Wildcard Zertifikat tatsächlich ab?

Die Standards sind hier eindeutig, also bleibt wenig Raum für Raten. RFC 9525 legt fest, dass das Platzhalterzeichen nur als vollständiges, am weitesten links stehendes Label vorkommen darf. Außerdem passt es nur auf ein einziges Label. Daher ist der Umfang enger, als viele erwarten.

Ein Zertifikat für *.example.com sichert diese Adressen ab:

• www.example.com, weil das einzelne Label "www" den Stern ersetzt.
• Jede Subdomain der ersten Ebene, etwa shop.example.com oder blog.example.com.
• Auch künftige Subdomains, also Adressen, die Sie noch nicht angelegt haben.

Dasselbe Zertifikat sichert diese Adressen nicht ab:

• example.com selbst, also die nackte Hauptdomain, weil es kein Label zum Abgleichen gibt.
• Adressen mit zwei Ebenen wie a.b.example.com, weil der Stern nur ein Label abdeckt.
• Eine andere Domain wie example.net.

In der Praxis beantragen Sie sowohl example.com als auch *.example.com. So liegen die Hauptdomain und alle Subdomains der ersten Ebene in einer Datei. RFC 9525 weist zudem darauf hin, dass dieses Verhalten bewusst von Platzhaltern im DNS abweicht. Das heißt, Sie können den Umfang eines DNS Platzhalters nicht eins zu eins auf ein Zertifikat übertragen.

Wie unterscheidet sich ein Wildcard Zertifikat von Einzeldomain und SAN Zertifikaten?

Der Unterschied liegt darin, welche Namen Sie in einem Zertifikat bündeln. Zunächst stellt die folgende Tabelle die drei Modelle nebeneinander. Wenn sich Ihre Subdomains häufig ändern, erleichtert sie die Entscheidung.

Allerdings ist hier ein Detail wichtig. Technisch trägt auch ein Wildcard Zertifikat den Eintrag "*.example.com" im SAN Feld. Die Modelle schließen sich also nicht aus. Ein Zertifikat kann example.com und *.example.com enthalten, und Sie können sogar weitere Domains ergänzen.

In der Praxis nutzen wir eine einfache Faustregel. Sind Ihre Namen wenige und stabil, reicht ein SAN Zertifikat. Sind sie zahlreich oder wechselhaft, lässt sich ein Wildcard leichter verwalten. Allerdings gilt: Eine sensible Adresse gehört bei beiden Modellen auf ein eigenes Zertifikat.

Wann brauchen Sie ein Wildcard Zertifikat wirklich?

Nicht jede Website braucht eines, denn der Bedarf hängt vom Aufbau ab. Zunächst sollten Sie prüfen, wie viele Subdomains Sie betreiben und wie schnell sie sich ändern. Für eine Handvoll fester Adressen ist ein Einzeldomain oder SAN Zertifikat meist einfacher und sicherer.

Ein Wildcard Zertifikat ist in diesen Fällen sinnvoll:

• Sie betreiben ein Softwareprodukt, das für jeden Kunden eine eigene Subdomain öffnet.
• Sie legen für Test, Staging und Produktion häufig neue Subdomains an.
• Sie verwalten viele Kampagnen oder Regionen Subdomains an einer Stelle.
• Die Überwachung der Erneuerung pro Subdomain belastet Ihr Team.

Zum Beispiel bündelt ein Wildcard die Arbeit, wenn Shop, Blog und Support auf getrennten Subdomains liegen. Haben Sie dagegen nur drei feste Adressen, sind drei einzelne Zertifikate ein besserer Kompromiss als ein gemeinsamer Schlüssel. Die Risiken behandeln wir daher in den späteren Abschnitten.

Außerdem kommt ein Marketing Aspekt dazu. Veröffentlichen Sie Kampagnenseiten auf Subdomains, bremst das Warten auf ein Zertifikat jeden Start. In diesem Fall verkürzt ein Wildcard die Wartezeit. Dennoch sollten Sie es nicht allein wegen der Geschwindigkeit wählen.

Unterscheidet sich ein kostenloses Wildcard Zertifikat von einem bezahlten?

Browser interessiert nämlich nicht, ob ein Zertifikat kostenlos oder bezahlt war. Sie prüfen die Kette, den Umfang, das Ablaufdatum und ob der Name passt. Bei einem domainvalidierten (DV) Wildcard Zertifikat sollten Sie daher keinen sichtbaren Unterschied für Besucher erwarten.

Der Unterschied liegt also meist rund um das Zertifikat. Bezahlte Anbieter bieten in der Regel Support, Garantiebedingungen und ein Verwaltungsportal. Dagegen liegen bei einer kostenlosen Lösung Erneuerung und Überwachung bei Ihnen. Preise und Laufzeiten unterscheiden sich je nach Anbieter, deshalb nennen wir hier keine Zahlen. Lesen Sie die aktuellen Bedingungen auf der Seite des jeweiligen Anbieters.

• Mit einem technischen Team, das Automatisierung aufsetzen kann, genügt eine kostenlose Lösung.
• Wer die Verantwortung für Ausfälle abgeben möchte, fährt mit einem betreuten Produkt sicherer.
• Wo Ihr Hoster Wildcard über AutoSSL anbietet, zahlen Sie daher womöglich nichts extra.

Denken Sie bei der Entscheidung an die Gesamtkosten. Die Gebühr für das Zertifikat ist vielleicht ein kleiner Posten, ein Ausfall nach einer gescheiterten Erneuerung kostet aber deutlich mehr. Fragen Sie deshalb neben "Ist es kostenlos?" auch "Wer ist verantwortlich?".

Warum funktioniert die Validierung eines Wildcard Zertifikats nur über DNS?

Bevor eine Zertifizierungsstelle einen Platzhalternamen freigibt, verlangt sie den Nachweis, dass Sie die Domain kontrollieren. Die FAQ von Let's Encrypt legt fest, dass Wildcard Zertifikate die DNS-01 Challenge verwenden müssen. Anders gesagt reicht eine Datei auf dem Webserver für diese Aufgabe nicht aus.

Bei der DNS-01 Challenge erzeugt Ihr Client einen TXT Eintrag, der sich aus einem Token und Ihrem Kontoschlüssel ableitet. Diesen Eintrag veröffentlichen Sie unter _acme-challenge.example.com. Danach liest die Zertifizierungsstelle den Eintrag aus dem DNS und schließt die Validierung ab. Das deckt sich also mit der Übersicht der Challenge Typen von Let's Encrypt.

Die erste Frage bei einem Wildcard Zertifikat lautet also nicht "Ist mein Server bereit?", sondern "Wer kontrolliert das DNS und wie?". Liegt das DNS bei einer anderen Firma, dann hängt der Ablauf von deren Erlaubnis und API ab.

DNS Änderungen brauchen mitunter Zeit, weil sie sich erst verbreiten müssen. Die Seite von Let's Encrypt nennt die Verzögerung durch die Verbreitung ausdrücklich als Nachteil. Machen Sie daher nicht sofort nach dem Anlegen des TXT Eintrags weiter. Fragen Sie ihn zunächst mit einem Abfrage Tool ab und starten Sie erst dann die Validierung. Außerdem sollten Sie alte _acme-challenge Einträge löschen, weil ein alter Wert mit dem neuen kollidieren kann.

Was sollten Sie vor der Installation vorbereiten?

Klären Sie zunächst vier Dinge, bevor Sie einen Befehl ausführen. Bei einem Wildcard Zertifikat liegt der häufigste Stolperstein nicht in der Technik, sondern bei den Berechtigungen. Wer verwaltet die Domain, wo liegt das DNS und wer erreicht den Server?

1. Prüfen Sie zunächst, ob Sie Zugriff auf die DNS Verwaltung der Domain haben.
2. Klären Sie dann, ob Ihr DNS Anbieter eine API bereitstellt.
3. Listen Sie außerdem alle Server auf, die das Zertifikat nutzen.
4. Legen Sie schließlich fest, wer bei einem Fehler der Erneuerung eine Warnung erhält.

Sichern Sie außerdem Ihre aktuellen DNS Einträge an einem sicheren Ort. Ein DNS Abfrage Tool zeigt sie Ihnen schnell. Unser Beitrag zur Backup Strategie liefert Ihnen einen Rahmen für die Ablage. Ein kleiner Fehler bei einer DNS Änderung kann den Zugriff auf Ihre ganze Website stören.

Beachten Sie außerdem noch einen Punkt. Hat Ihre Domain einen CAA Eintrag, legt dieser fest, welche Zertifizierungsstellen Zertifikate ausstellen dürfen. Für Wildcard Namen gibt es ein eigenes Tag namens issuewild. Erlaubt der Eintrag Ihre gewählte Stelle nicht, scheitert die Ausstellung also, selbst wenn die Validierung gelingt.

Wie holen Sie sich ein Wildcard Zertifikat von Let's Encrypt Schritt für Schritt?

Mit einem VPS oder Server mit Root Zugriff ist Certbot daher der häufigste Weg. Zunächst installieren Sie Certbot. Folgen Sie für aktuelle Anleitungen der offiziellen Seite (certbot.eff.org), denn die Methode unterscheidet sich je nach Distribution.

Das Certbot Benutzerhandbuch nennt die DNS Validierung als einzigen Weg zu Wildcard Zertifikaten von Let's Encrypt. Das manuelle Beispiel dort bevorzugt zudem die DNS Challenge. Eine Automatisierung über Hook Skripte sieht so aus:

certbot certonly --manual --preferred-challenges=dns \
  --manual-auth-hook /path/to/dns/authenticator.sh \
  --manual-cleanup-hook /path/to/dns/cleanup.sh \
  -d example.com -d "*.example.com"

Geben Sie keine Hooks an, fordert Certbot Sie auf, den TXT Eintrag von Hand anzulegen. Der Ablauf sieht dann so aus:

1. Certbot zeigt einen TXT Wert auf dem Bildschirm.
2. Dann legen Sie in Ihrem DNS Portal einen TXT Eintrag mit dem Namen _acme-challenge und diesem Wert an.
3. Nachdem sich der Eintrag verbreitet hat, machen Sie in Certbot weiter.
4. Dann entstehen bei erfolgreicher Validierung die Zertifikatsdateien.

Machen Sie nicht weiter, bevor sich der Eintrag verbreitet hat. Prüfen Sie per DNS Abfrage oder in der Kommandozeile, dass der TXT Eintrag sichtbar ist. Sonst scheitert die Validierung, denn die Zertifizierungsstelle findet den Eintrag nicht. Der manuelle Ablauf eignet sich für einmalige Tests, Sie müssten ihn aber alle 90 Tage wiederholen.

Wie automatisieren Sie die Erneuerung eines Wildcard Zertifikats mit einer DNS API?

Die Standardlaufzeit eines Let's Encrypt Zertifikats beträgt 90 Tage, so steht es in der FAQ. Eine manuelle Erneuerung ist also kein tragfähiger Weg. Für die Automatisierung nutzen Sie das Certbot Plugin Ihres DNS Anbieters. Das Handbuch listet Plugins für Cloudflare, DigitalOcean, Google und Route 53 auf.

Die Dokumentation des Cloudflare Plugins für Certbot empfiehlt für Cloudflare einen eingeschränkten API Token. Dieser Token trägt nur die Berechtigung, DNS Einträge der betreffenden Zone zu bearbeiten. So sieht die Datei mit den Zugangsdaten aus:

dns_cloudflare_api_token = HIER_DEN_TOKEN_EINTRAGEN

Schränken Sie die Dateirechte ein. Die Dokumentation zeigt deshalb chmod 600. Denn wer die Datei lesen kann, kann in Ihrem Namen API Aufrufe ausführen. Der Befehl für das Wildcard Zertifikat sieht dann so aus:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  -d example.com \
  -d "*.example.com"

Für die Erneuerung nennt das Handbuch den Befehl certbot renew. Sie planen ihn per Cronjob oder systemd Timer ein. Für einen ersten Test können Sie certbot renew --dry-run ausführen. Nutzen Sie einen anderen DNS Anbieter, folgen Sie der Dokumentation des passenden Plugins in derselben Reihenfolge.

Wie binden Sie ein Wildcard Zertifikat in Nginx und Apache ein?

Certbot legt die Zertifikatsdateien standardmäßig unter /etc/letsencrypt/live/example.com/ ab. Dort finden Sie fullchain.pem und privkey.pem. In der Konfiguration des Webservers verweisen Sie nur auf diese beiden Dateien.

Hier ein Beispiel für einen Nginx Serverblock:

server {
    listen 443 ssl;
    server_name example.com *.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Bei Apache gilt dieselbe Logik. In die Zeile SSLCertificateFile tragen Sie die vollständige Kette ein, in die Zeile SSLCertificateKeyFile den privaten Schlüssel. Danach testen Sie die Konfiguration und laden den Dienst neu.

Nach der Erneuerung muss der Server die neue Datei einlesen, sonst läuft das alte Zertifikat weiter. Mit der Certbot Option --deploy-hook können Sie den Befehl zum Neuladen anhängen. Sollen mehrere Server dasselbe Zertifikat nutzen, bewegen Sie den privaten Schlüssel mit Sorgfalt. Denn jede Kopie des Schlüssels ist ein weiterer Risikopunkt. Erwägen Sie deshalb, das Zertifikat auf jedem Server einzeln zu erneuern.

Wie installieren Sie ein Wildcard Zertifikat in cPanel?

Bei Shared Hosting entscheidet daher größtenteils Ihr Anbieter. Laut SSL Leitfaden von cPanel sichert ein Wildcard Zertifikat Subdomains ab, die sich eine IP Adresse teilen. Es sichert die Domain example.com selbst allerdings nicht ab.

Derselbe Leitfaden nennt den Let's Encrypt Anbieter als Möglichkeit, Wildcard Domains abzusichern. AutoSSL nimmt dagegen nur Domains auf, die die Domain Control Validation (DCV) bestehen. Somit hängt alles von der AutoSSL Einstellung Ihres Anbieters ab.

Besitzen Sie bereits ein Wildcard Zertifikat, sieht der allgemeine Ablauf so aus:

1. Öffnen Sie in cPanel den Bereich SSL/TLS.
2. Dann gehen Sie zum Abschnitt "Install and Manage SSL for your site (HTTPS)".
3. Fügen Sie Zertifikat, privaten Schlüssel und gegebenenfalls das CA Paket in die passenden Felder ein.
4. Schließlich wählen Sie die Domain, die das Zertifikat nutzen soll, und schließen Sie die Installation ab.

Die Menünamen können je nach cPanel Version und Einstellungen Ihres Anbieters abweichen. Laut cPanel Dokumentation können Sie zudem in der erweiterten Oberfläche kein Wildcard Zertifikat kaufen. Für den Kauf nutzen Sie daher die einfache Oberfläche. Kommen Sie nicht weiter, ist eine Nachricht an den Support Ihres Anbieters der schnellste Weg.

Wie prüfen Sie die Installation eines Wildcard Zertifikats?

Prüfen Sie nach der Installation drei Dinge: welche Namen das Zertifikat trägt, das Ablaufdatum und ob die Kette vollständig ist. Für eine schnelle Kontrolle genügt ein SSL Check. Bevorzugen Sie die Kommandozeile, listen Sie die Namen im Zertifikat mit openssl auf.

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null | openssl x509 -noout -ext subjectAltName -dates

In der Ausgabe sollten Sie example.com und *.example.com sehen. Öffnen Sie danach mehrere Subdomains im Browser und kontrollieren Sie das Schloss Symbol. Testen Sie jede Subdomain einzeln, denn manche laufen womöglich auf einem anderen Server.

Testen Sie außerdem die automatische Erneuerung. Der Befehl certbot certificates listet die vorhandenen Zertifikate und ihre Ablaufdaten auf. Scheitert ein Erneuerungsversuch, deutet die Fehlermeldung meist auf den DNS Eintrag oder die API Berechtigung. Führen Sie diese Kontrolle direkt nach der Installation und danach in regelmäßigen Abständen aus.

Warum funktioniert ein Wildcard Zertifikat bei mehrstufigen Subdomains nicht?

Das ist also die am häufigsten missverstandene Grenze. Ein Zertifikat für *.example.com sichert api.example.com ab, aber nicht v1.api.example.com. RFC 9525 legt fest, dass der Stern nur ein Label abdeckt. Deshalb zeigt eine Adresse der zweiten Ebene im Browser einen Zertifikatsfehler.

Sie haben drei Möglichkeiten:

• Erstens holen Sie für die zweite Ebene ein eigenes Wildcard Zertifikat für *.api.example.com.
• Zweitens tragen Sie diese Adressen einzeln als SAN in das Zertifikat ein.
• Drittens flachen Sie Ihre Adressstruktur auf eine Ebene ab, zum Beispiel auf v1api.example.com.

Prüfen Sie Ihre Domainplanung, bevor Sie die Struktur festlegen. Unser Ratgeber zur Domain Wahl hilft bei dieser Planung. Öffnet Ihr Produkt verschachtelte Subdomains pro Kunde, kostet die richtige Hierarchie am Anfang weniger als eine Korrektur später.

Welche Risiken hat ein Wildcard Zertifikat?

Das größte Risiko eines Wildcard Zertifikats ist der einzelne Schlüssel. Derselbe private Schlüssel liegt auf vielen Subdomains und oft auf mehreren Servern. Gelangt er in fremde Hände, besitzt ein Angreifer ein gültiges Zertifikat für jede Subdomain im Geltungsbereich.

Die Dokumentation von Let's Encrypt nennt das Risiko, API Zugangsdaten auf Webservern zu speichern, als Nachteil der DNS-01 Methode. Außerdem weist sie darauf hin, dass nicht jeder DNS Anbieter die nötige API bereitstellt. Diese beiden Punkte sind ein echter Preis, den Sie vor dem Aufbau der Automatisierung abwägen sollten.

Wie senken Sie die Risiken eines Wildcard Zertifikats?

Das Risiko verschwindet nicht, aber Sie können es daher steuern. Erstens halten Sie den Schlüssel an möglichst wenigen Orten. Zweitens schränken Sie die DNS Berechtigung ein. Drittens lassen Sie kritische Adressen außerhalb des Wildcards.

• Beschränken Sie den API Token auf die betreffende DNS Zone und nur auf die Berechtigung zum Bearbeiten von DNS Einträgen.
• Speichern Sie die Datei mit den Zugangsdaten mit Rechten, die nur der nötige Benutzer lesen kann.
• Geben Sie sensiblen Subdomains wie Zahlung, Admin Bereich und Kundendaten ein eigenes Zertifikat.
• Kopieren Sie den Wildcard Schlüssel nicht auf Entwicklungs und Testserver.
• Richten Sie für das Ablaufdatum eine unabhängige Überwachung oder einen Kalenderhinweis ein.

Außerdem können Sie die DNS Validierung an eine andere Zone übergeben. Laut Dokumentation von Let's Encrypt können Sie per CNAME oder NS Einträgen die Challenge an eine andere DNS Zone delegieren. So vermeiden Sie, dass der Server die API Berechtigung Ihrer Hauptzone erhält. Dieser Ansatz verlangt eine sorgfältige Einrichtung, deshalb empfehlen wir, Fachleute hinzuzuziehen.

Welche Fehler passieren bei der Einrichtung eines Wildcard Zertifikats?

Die meisten Probleme stammen aus denselben fünf Stellen, deshalb lohnt der Blick. Wer sie kennt, findet die Ursache in Minuten. Lesen Sie die Liste deshalb einmal vor dem Start.

1. Die Hauptdomain fehlt im Zertifikat. Folglich zeigt example.com einen Fehler.
2. Die Validierung startet, bevor sich der TXT Eintrag verbreitet hat.
3. Der Eintrag _acme-challenge landet unter dem falschen Namen. Zum Beispiel erscheint er als example.com.example.com.
4. Der API Token erhält die falsche Zone oder zu wenig Berechtigung.
5. Zuletzt lädt der Webserver nach der Erneuerung nicht neu.

Der fünfte Punkt ist besonders tückisch. Certbot schreibt die neue Datei, doch der laufende Server kann das alte Zertifikat im Speicher behalten. Fügen Sie daher einen Schritt zum Neuladen in Ihre Automatisierung ein. Suchen Sie Fehlermeldungen im Certbot Protokoll und im Protokoll des Webservers.

Dazu kommt ein Fehler im Management: Niemand ist für das Zertifikat zuständig. Verlässt die Person, die es eingerichtet hat, das Unternehmen, stoppt die Erneuerung still. Benennen Sie deshalb schriftlich eine verantwortliche Person und eine Vertretung.

Wie überwachen Sie das Ablaufdatum eines Wildcard Zertifikats?

Eine automatische Erneuerung allein genügt nicht, denn auch Automatisierung geht kaputt. Ein DNS Token kann ablaufen, ein Eintrag kann sich ändern oder ein Timer kann stehen bleiben. Beobachten Sie das Ablaufdatum daher auf einem unabhängigen Weg.

• Führen Sie auf dem Server in regelmäßigen Abständen certbot certificates aus, um Ablaufdaten zu sehen.
• Für den Blick von außen nutzen Sie den SSL Check zusammen mit einer Kalendererinnerung.
• Leiten Sie das Protokoll der Erneuerung an einen Ort weiter, damit Fehler nicht unbemerkt bleiben.
• Senden Sie die Warnung kurz vor Ablauf an mindestens zwei Personen.

Überwachen Sie außerdem pro Subdomain. Denn eine Subdomain kann auf einem anderen Server mit einem alten Zertifikat laufen. Obwohl ein Wildcard ein einziges Zertifikat ist, erneuert jeder Server seine eigene Kopie. Daher heißt die Meldung "Zertifikat erneuert" nicht "jede Adresse erneuert".

Worauf achten Sie, wenn Sie ein Wildcard Zertifikat auf einen neuen Server oder Hoster umziehen?

Beim Umzug haben Sie zwei Möglichkeiten: dasselbe Zertifikat kopieren oder auf dem neuen Server ein neues ausstellen. Kopieren geht schnell, dennoch wandert der private Schlüssel an einen neuen Ort. Ein neues Zertifikat braucht etwas Zeit, dafür bleibt der Schlüssel nur dort, wo Sie ihn nutzen.

1. Listen Sie auf, welche Subdomains auf dem alten und auf dem neuen Server laufen.
2. Bereiten Sie das Zertifikat auf dem neuen Server vor, bevor Sie DNS Einträge ändern.
3. Testen Sie nach dem Wechsel jede Subdomain im Browser und mit einem Prüftool.
4. Löschen Sie die Kopien des Schlüssels auf dem alten Server auf sichere Weise.

Vielleicht möchten Sie beim Umzug auch ein Backup anlegen. Allerdings ist die Sicherung des privaten Schlüssels deutlich sensibler als das Zertifikat selbst. Bewahren Sie den Schlüssel daher nur an einem verschlüsselten Ort mit begrenztem Zugriff auf. Unser Beitrag zur Backup Strategie ist ein guter Startpunkt für die Sicherungsroutine.

Warum sind vergessene Subdomains bei einem Wildcard Zertifikat gefährlich?

Ein Wildcard Zertifikat deckt auch Subdomains ab, die noch gar nicht existieren. Deshalb birgt ein vergessener DNS Eintrag, also eine Subdomain, die auf einen nicht mehr genutzten Dienst zeigt, ein eigenes Risiko. Übernimmt jemand anderes diesen Dienst, kann er unter Ihrer Adresse eine Seite ausliefern, die mit Ihrem Zertifikat gültig aussieht.

Das Zertifikat selbst trifft hier keine Schuld. Ein Wildcard erweitert jedoch den Vertrauensbereich, daher wächst die Folge. Betrachten Sie die Entscheidung für das Zertifikat also zusammen mit einer Aufräumaktion im DNS.

• Prüfen Sie die Einträge Ihrer DNS Zone in regelmäßigen Abständen.
• Löschen Sie CNAME Einträge, die auf nicht mehr genutzte Dienste zeigen.
• Notieren Sie bei jeder neuen Subdomain den Eintrag und die zuständige Person.
• Entfernen Sie Adressen von Testumgebungen aus dem DNS, wenn die Arbeit endet.

Für das größere Bild der Websicherheit ist unser OWASP Top 10 Beitrag eine gute Anlaufstelle. Außerdem können Sie Ihre Einträge von Hand mit einer DNS Abfrage prüfen.

Welche Checkliste arbeiten Sie nach der Installation ab?

Mit der Installation endet die Arbeit also nicht. Eine kleine Checkliste verringert Überraschungen nach Monaten. Halten Sie sie schriftlich fest und teilen Sie sie mit Ihrem Team.

1. Enthält das Zertifikat example.com und *.example.com?
2. Öffnet sich jede kritische Subdomain im Browser ohne Warnung?
3. Ist der Testlauf der automatischen Erneuerung erfolgreich?
4. Lädt der Webserver nach der Erneuerung die neue Datei?
5. Besitzt der API Token nur die nötige Berechtigung?
6. Ist eine unabhängige Warnung für das Ablaufdatum eingerichtet?
7. Steht schriftlich fest, wer für Zertifikat und Schlüssel zuständig ist?

Arbeiten Sie diese Liste nach jeder größeren DNS oder Serveränderung erneut ab. Zum Beispiel gewinnt sie wieder an Bedeutung, wenn Sie den Hoster wechseln oder eine neue Gruppe von Subdomains öffnen.

Wann sollten Sie ein Wildcard Zertifikat nicht selbst installieren, sondern Ihrem Hosting Anbieter überlassen?

Seien wir ehrlich: Sie müssen nicht alles selbst machen. In manchen Fällen ist es sicherer und günstiger, die Aufgabe Ihrem Anbieter zu überlassen. Wir betreiben kein Hosting, deshalb können wir diese Wahl ohne eigenes Interesse beschreiben.

Überlassen Sie die Aufgabe in diesen Fällen Ihrem Anbieter:

• Sie nutzen Shared Hosting und haben keinen Root Zugriff auf den Server.
• Ihre DNS Einträge liegen bei einer anderen Firma und Sie bekommen keinen API Zugang.
• Die Kommandozeile ist Ihnen fremd und ein Fehler könnte Ihre Website lahmlegen.
• Sie betreiben einen Shop mit Zahlungen und können das Risiko eines Ausfalls nicht tragen.
• Sie arbeiten in einem Konzern oder einem regulierten Umfeld, das Richtlinien für das Schlüsselmanagement braucht.

Fragen Sie Ihren Anbieter dann: "Bieten Sie Wildcard Zertifikate über AutoSSL an und wer überwacht die Erneuerung?" Außerdem sammelt unser Ratgeber zur Webhosting Auswahl Fragen für die Auswahl eines Anbieters. Für die Sicherheit liefert der OWASP Top 10 Beitrag den allgemeinen Rahmen.

In welcher Reihenfolge entscheiden Sie sich für ein Wildcard Zertifikat?

Die Reihenfolge ist daher einfach. Zuerst hinterfragen Sie den Bedarf, dann wägen Sie das Risiko ab, und erst zuletzt wählen Sie das Werkzeug. Für die meisten Unternehmen ist ein Mix die richtige Antwort: eigene Zertifikate für feste Adressen und ein Wildcard für wechselnde.

1. Wie viele Subdomains haben Sie und wie oft ändern sie sich?
2. Müssen sensible Dienste dasselbe Zertifikat teilen?
3. Unterstützt Ihr DNS Anbieter die Validierung per API?
4. Wer überwacht die Erneuerung und wer erhält die Warnung bei einem Fehler?
5. Soll Ihr Anbieter das Zertifikat verwalten oder Sie selbst?

Die Entscheidung für ein Zertifikat ist für sich genommen keine Marketing Aufgabe, hängt aber eng mit Vertrauen und Geschwindigkeit Ihrer Website zusammen. Fällt HTTPS aus, sehen Besucher eine Browserwarnung, und bezahlter wie organischer Traffic verpufft. Unsere Hinweise zum Einfluss der Ladezeit auf SEO und zur SEO Beratung erklären diesen Zusammenhang. Planen Sie eine neue Website, klären wir diese Infrastruktur Entscheidungen gern gemeinsam im Rahmen unserer Webdesign Leistung.