SAN-Extraktor

Der SAN-Extractor extrahiert alle Subject Alternative Names aus X.509-Zertifikaten und liefert eine saubere Liste jedes Hostnamens, jeder IP-Adresse, E-Mail-Adresse und URI, für die das Zertifikat gültig ist -- entscheidend, weil moderne Browser ausschließlich SANs für die Hostname-Validierung verwenden und das Common-Name-Feld ignorieren. Fügen Sie ein oder mehrere PEM-Zertifikate ein und erhalten Sie ein vollständiges Inventar der abgedeckten Identitäten.

Subject Alternative Names verstehen

Subject Alternative Names sind die Art, wie moderne Zertifikate deklarieren, welche Identitäten sie schützen. Jedes Mal, wenn ein Browser eine Verbindung zu einer HTTPS-Website herstellt, prüft er die SAN-Erweiterung des Zertifikats, um zu sehen, ob die Domain in der Adressleiste aufgelistet ist. Wenn nicht, schlägt die Verbindung mit einem Hostname-Mismatch-Fehler fehl -- selbst wenn die Domain im älteren Common-Name-Feld erscheint. Dies ist seit Chrome Version 58 (2017) das Verhalten, und alle anderen großen Browser folgen derselben Regel.

Für Systemadministratoren ist die praktische Auswirkung erheblich. Sie müssen genau wissen, welche Domains ein Zertifikat abdeckt, bevor Sie es bereitstellen, bevor Sie es erneuern und bei der Fehlersuche von Verbindungsfehlern. Ein Zertifikat für www.example.com könnte auch example.com, api.example.com und cdn.example.com abdecken, oder es könnte nur die bloße www-Subdomain abdecken. Sie können dies weder am Dateinamen des Zertifikats noch am Common Name allein erkennen. Die SAN-Erweiterung ist die maßgebliche Wahrheitsquelle dafür, was ein Zertifikat schützt.

Dieser Extractor zieht jeden SAN-Eintrag aus einem oder mehreren Zertifikaten heraus und präsentiert sie als saubere, organisierte Liste. Bei Eingabe mehrerer Zertifikate (wie einer Kette oder einem Bündel nicht zusammengehöriger Zertifikate) zeigt er an, welche SANs von welchem Zertifikat stammen. Dies macht es einfach, Ihre Zertifikatsabdeckung über eine gesamte Infrastruktur zu prüfen -- fügen Sie alle Ihre Zertifikate ein, und Sie sehen sofort jede Domain, IP-Adresse und Identität, die geschützt ist.

So extrahieren Sie SANs aus einem Zertifikat

1. Fügen Sie ein oder mehrere PEM-codierte Zertifikate ein (beginnend mit -----BEGIN CERTIFICATE-----)
2. Das Tool extrahiert und listet alle Subject Alternative Names, nach Typ organisiert
3. Überprüfen Sie die SAN-Liste auf Vollständigkeit und Richtigkeit
4. Kopieren Sie die Ausgabe als Liste, Regex-Muster oder Konfigurationsausschnitt

Beispiel einer SAN-Extraktion

Aus einem Multi-Domain-Zertifikat:

Certificate: CN=www.example.com

Subject Alternative Names:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: *.staging.example.com
  IP:  203.0.113.50

SAN-Typen

Multi-Zertifikat-Ausgabe

Beim Einfügen eines Bündels mit mehreren Zertifikaten zeigt der Extractor, welche SANs von welchem Zertifikat stammen:

Wann Sie dieses Tool verwenden sollten

• Vor-Erneuerung-Domain-Audit -- listen Sie alle Domains auf, die von einem ablaufenden Zertifikat abgedeckt werden, um sicherzustellen, dass die Erneuerungsanforderung jeden SAN enthält
• Zertifikatsabdeckungs-Mapping -- dokumentieren Sie, welche Zertifikate welche Domains in Ihrer Infrastruktur schützen
• Wildcard-Abdeckungsüberprüfung -- bestätigen Sie, dass Wildcard-Zertifikate (*.example.com) die erwarteten Subdomains abdecken und identifizieren Sie, was sie nicht abdecken (z.B. sub.sub.example.com)
• Migrationsplanung -- extrahieren Sie SANs aus bestehenden Zertifikaten bei der Migration zu einer neuen CA oder Konsolidierung von Zertifikaten
• Sicherheitsüberprüfung -- identifizieren Sie unerwartete Domains in einem Zertifikat, die auf Fehlkonfiguration oder Kompromittierung hindeuten könnten
• Troubleshooting von Hostname-Mismatch -- verifizieren Sie, dass die Domain, die einen TLS-Fehler verursacht, tatsächlich in den SANs des Zertifikats aufgelistet ist

Wie Subject Alternative Names funktionieren

Die SAN-Erweiterung (OID 2.5.29.17) wurde eingeführt, um die Einschränkungen des Common-Name-Felds zu überwinden. Während CN nur einen einzelnen Hostnamen enthalten konnte, unterstützt die SAN-Erweiterung mehrere Namen und verschiedene Namenstypen.

CN vs. SAN: Aktuelles Browser-Verhalten

Seit 2017 haben große Browser den Common Name für die Hostname-Übereinstimmung als veraltet erklärt:

• Chrome 58+ -- ignoriert CN vollständig; prüft nur SANs
• Firefox 48+ -- ignoriert CN, wenn SANs vorhanden sind
• Safari -- folgt dem gleichen Muster

Das bedeutet, ein Zertifikat mit CN=example.com aber ohne DNS:example.com-SAN-Eintrag wird in modernen Browsern einen Hostname-Mismatch-Fehler erzeugen. Stellen Sie immer sicher, dass jede Domain in der SAN-Erweiterung erscheint.

Wildcard-Zertifikat-Geltungsbereich

Wildcard-SANs folgen spezifischen Übereinstimmungsregeln:

Wichtige Regeln:

• Wildcards stimmen nur mit einer Subdomain-Ebene überein
• Wildcards müssen das linkeste Label sein (*.example.com, nicht www.*.com)
• Die nackte Domain (example.com) wird nicht durch *.example.com abgedeckt -- sie muss als separater SAN aufgelistet werden

SANs in der Praxis verwalten

Der häufigste SAN-bezogene Fehler ist das Vergessen der nackten Domain. Wenn Ihre Benutzer sowohl auf www.example.com als auch auf example.com zugreifen, müssen beide als separate SAN-Einträge erscheinen. Ein Wildcard *.example.com deckt www.example.com ab, aber nicht example.com selbst. Dies überrascht viele Teams, wenn sie von einem reinen Wildcard-Zertifikat zu einem wechseln, von dem sie erwarten, dass es die Apex-Domain abdeckt. Fügen Sie immer sowohl example.com als auch *.example.com (oder www.example.com) als separate Einträge ein.

Für Organisationen mit vielen Subdomains ist die Entscheidung zwischen einem Wildcard-Zertifikat und einem Multi-SAN-Zertifikat eine wichtige architektonische Wahl. Wildcard-Zertifikate (*.example.com) sind praktisch, weil Sie nicht jede Subdomain auflisten müssen, aber sie können keine tieferen Subdomains wie api.v2.example.com oder die nackte Domain abdecken. Multi-SAN-Zertifikate listen jede Domain explizit auf, was Ihnen vollständige Kontrolle gibt, aber eine Aktualisierung des Zertifikats erfordert, wenn Sie eine neue Subdomain hinzufügen. Viele Organisationen verwenden ein Wildcard für dynamisch erstellte Subdomains und ein separates Multi-SAN-Zertifikat für ihre Hauptdomains.

Bei der Prüfung der Zertifikatsabdeckung vor Erneuerungen extrahieren Sie die SANs aus Ihrem ablaufenden Zertifikat und vergleichen Sie sie mit Ihren DNS-Records. Es ist überraschend häufig festzustellen, dass ein Zertifikat vor zwei Jahren mit SANs ausgestellt wurde, die nicht mehr zu Ihrer aktuellen Infrastruktur passen. Neue Subdomains wurden hinzugefügt, alte wurden stillgelegt, und das Zertifikat wurde nie aktualisiert. Dieser Prüfschritt verhindert die frustrierende Situation, ein erneuertes Zertifikat bereitzustellen, nur um festzustellen, dass es eine Subdomain nicht abdeckt, die nach der Ausstellung des ursprünglichen Zertifikats hinzugefügt wurde.

Häufig gestellte Fragen

Warum zeigt mein Zertifikat Domains, die ich nicht angefordert habe? Einige CAs fügen automatisch sowohl die nackte Domain als auch die www-Variante hinzu. Zum Beispiel kann die Anforderung eines Zertifikats für example.com SANs für sowohl example.com als auch www.example.com ergeben. Zusätzlich können Multi-Domain-(UCC/SAN-)Zertifikate Domains aus früheren Bestellungen enthalten, wenn sie erneuert statt neu ausgestellt wurden.

Wie viele SANs kann ein einzelnes Zertifikat haben? Es gibt kein festes Limit im X.509-Standard, aber praktische Grenzen existieren. Let's Encrypt erlaubt bis zu 100 SANs pro Zertifikat. Kommerzielle CAs unterstützen typischerweise 25-250 SANs je nach Produkt. Sehr große SAN-Listen vergrößern das Zertifikat und die TLS-Handshake-Zeit.

Benötigt ein Wildcard-Zertifikat die nackte Domain als separaten SAN? Ja. Ein Wildcard-SAN *.example.com deckt die nackte Domain example.com nicht ab. Wenn Sie möchten, dass sowohl *.example.com als auch example.com funktionieren, müssen beide als separate SAN-Einträge im Zertifikat erscheinen.

Kann ein Zertifikat sowohl DNS- als auch IP-SANs haben? Ja. Ein einzelnes Zertifikat kann sowohl DNS-Namen als auch IP-Adressen als SANs enthalten. Dies ist nützlich für Dienste, die sowohl über Hostnamen als auch über IP-Adresse zugänglich sind. Die meisten CAs erfordern jedoch eine zusätzliche Validierung für IP-Adressen-SANs, und Let's Encrypt stellt derzeit keine Zertifikate mit IP-SANs aus.

Warum zeigt mein Zertifikat "hostname mismatch", obwohl der CN übereinstimmt? Moderne Browser (Chrome 58+, Firefox 48+) ignorieren den Common Name für die Hostname-Validierung und prüfen nur Subject Alternative Names. Wenn Ihre Domain im CN erscheint, aber nicht als DNS-SAN-Eintrag, lehnen Browser das Zertifikat ab. Stellen Sie sicher, dass jede Domain als SAN-Eintrag aufgelistet ist, nicht nur im CN.

Wie funktionieren SANs mit mehrstufigen Subdomains? Ein Wildcard *.example.com stimmt nur mit einer Subdomain-Ebene überein. Es deckt www.example.com und api.example.com ab, aber nicht api.v2.example.com. Für mehrstufige Subdomains benötigen Sie entweder einen expliziten SAN-Eintrag für jede oder ein separates Wildcard wie *.v2.example.com.

Verwandte Tools

• X.509-Zertifikats-Viewer - Alle Zertifikatsfelder anzeigen, nicht nur SANs
• Zertifikats-Ablauf-Prüfer - Prüfen, wann Zertifikate für Ihre Domains ablaufen
• CSR-Viewer - Angeforderte SANs in einem CSR vor der Einreichung bei einer CA verifizieren
• PEM-Bundle-Splitter - Eine Kette aufteilen, um das Leaf-Zertifikat mit den SANs zu extrahieren
• Public-Key-Extractor - Den öffentlichen Schlüssel für Zertifikate Ihrer Domains extrahieren