Wildcard vs. SAN-Zertifikat
wildcard zertifikat · san zertifikat · multi domain ssl
Vergleich von Wildcard-, SAN- und Einzelzertifikaten mit Risiken, Renewal-Aufwand, Subdomain-Abdeckung und Prüfstrategie.
Von DN01 Netzwerk-Team
Die Zertifikatswahl entscheidet darüber, wie einfach Renewals, Subdomain-Launches und Incident-Eingrenzung später werden. Für Besucher sieht das Ergebnis oft nur wie "Diese Verbindung ist nicht privat" aus, während Betreiber mehrere Schichten auseinanderhalten müssen: DNS-Ziel, Server Name Indication, Zertifikatskette, Gültigkeit, SAN-Namen, Protokollversion und Browser-Cache.
Der praktische Startpunkt ist der DN01 SSL Certificate Checker unter /de/ssl-certificate-checker. Er zeigt die öffentlich sichtbare TLS-Antwort einer Domain und hilft, Panel-Angaben, Load-Balancer-Konfiguration und Browserfehler gegen Live-Daten zu prüfen.
Dieser Leitfaden ist bewusst operativ geschrieben: erst eingrenzen, dann ändern, danach erneut messen. Verlinken Sie die relevanten SSL-Guides im Change-Ticket, damit Support, Hosting-Team und Entwickler nicht mit unterschiedlichen Annahmen arbeiten.
Wann dieser Check wichtig ist
Der Vergleich ist nützlich vor Domain-Migrationen, SaaS-Mandantenmodellen, CDN-Rollouts und wenn ein Team viele Subdomains mit einem Zertifikat bündeln möchte.
Besonders kritisch sind Änderungen, die nicht überall gleichzeitig sichtbar werden: DNS-Umzüge, neue CDN-Zonen, Ingress-Regeln in Kubernetes, Zertifikatswechsel auf mehreren Nodes oder parallele IPv4/IPv6-Pfade. Prüfen Sie deshalb nicht nur die Hauptdomain, sondern auch www, api, mail, staging und jede öffentlich verlinkte Subdomain.
Öffnen Sie /de/ssl-certificate-checker, testen Sie den Hostnamen ohne Pfad und dokumentieren Sie Zeitpunkt, IP-Ziel, Ablaufdatum, Aussteller und Kette. Bei DNS-Fragen ergänzt /de/dns-checker die Sicht auf A-, AAAA- und CNAME-Ziele; bei Security-Headern hilft /de/http-header-checker.
Schritt-für-Schritt prüfen
1. Domain im SSL Checker testen und zuerst den Hostnamen im Zertifikat mit der geprüften Domain vergleichen. 2. notBefore und notAfter lesen. 3. Intermediate-Zertifikate und Reihenfolge prüfen. 4. Ergebnis mit Browserfehler, Server-Config und Deploy-Zeitpunkt abgleichen.
Prüfen Sie mit dem Checker jede tatsächlich ausgelieferte Subdomain. Ein Wildcard deckt *.example.com ab, aber nicht example.com selbst und nicht automatisch tiefere Ebenen wie a.b.example.com.
Wenn ein Ergebnis unerwartet ist, wiederholen Sie die Prüfung mit exakt demselben Hostnamen nach einem TTL-Zyklus und zusätzlich über den alternativen Namen, zum Beispiel example.com und www.example.com. Unterschiedliche Resultate deuten meist auf SNI, CDN, IPv6 oder einen nicht aktualisierten Backend-Knoten hin.
Häufige Fehler in der Praxis
Wildcard-Zertifikate werden oft als Freifahrtschein für alle Namen missverstanden. SAN-Zertifikate wachsen leicht unübersichtlich und werden bei jeder Namensänderung neu ausgestellt.
Ein weiterer Klassiker ist die Verwechslung von Zertifikat und HTTPS-Weiterleitung: Ein Redirect auf https://www.example.com hilft nicht, wenn https://example.com bereits vor dem Redirect mit falschem Zertifikat antwortet. Der TLS-Handshake passiert zuerst, die HTTP-Weiterleitung danach.
Verlassen Sie sich nicht nur auf Hosting-Panels. Panels zeigen oft das gespeicherte Zertifikat, nicht zwingend das Zertifikat, das der öffentliche Edge, Proxy oder Mail-Server gerade ausliefert.
Nützliche Querprüfungen
Lesen Sie im selben Cluster weiter: /de/guides/ssl/multi-domain-ssl-san-planung, /de/guides/ssl/ssl-zertifikat-erneuern-checkliste, /de/guides/ssl/sni-und-hostname-mismatch. Diese Guides decken angrenzende Ursachen ab und verhindern, dass ein Chain-Problem als DNS-Problem oder ein HSTS-Problem als Zertifikatsproblem behandelt wird.
Für Migrationen lohnt sich ein kleines Prüfprotokoll: alte IP, neue IP, geprüfter Hostname, Zertifikatsfingerprint, Ablaufdatum, Chain-Status, Browserfehler und verantwortlicher Dienst. Dieses Protokoll beschleunigt Eskalationen, weil Provider konkrete Live-Werte statt Screenshots aus lokalen Browsern bekommen.
Nach der Korrektur erneut mit dem SSL Checker prüfen und erst dann Caches, CDN-Purge oder HSTS-Änderungen ausrollen. So bleibt klar, welche Änderung den Fehler wirklich beseitigt hat.
| Beobachtung | Wahrscheinliche Ursache | Nächster Schritt |
|---|---|---|
| Browserfehler nur auf einer Subdomain | SAN-Name fehlt oder falscher vHost | Subdomain separat im SSL Checker prüfen |
| Mobil funktioniert, Desktop nicht | Kette oder Trust Store unterscheidet sich | Intermediate-Reihenfolge vergleichen |
| IPv6 liefert anderes Zertifikat | AAAA-Pfad zeigt auf alten Edge | DNS und Load Balancer gemeinsam prüfen |
| Fehler nach Renewal | Neues Zertifikat nicht auf allen Nodes aktiv | Fingerprint pro Edge/Backend vergleichen |
Häufig gestellte Fragen
- Ist Wildcard unsicher?
Nicht automatisch, aber der private Schlüssel schützt mehr Namen. Key-Management und Zugriffskontrolle werden wichtiger.
- Kann ein Zertifikat Wildcard und Root-Domain enthalten?
Ja, wenn beide Namen explizit im SAN stehen, zum Beispiel example.com und *.example.com.