Was ist ein alternativer Name des Subjekts (SAN)?

Ein „Subject Alternative Name“ (SAN) ist eine X.509-Zertifikatserweiterung, in der alle Hostnamen, IP-Adressen oder sonstigen Identitäten aufgeführt sind, für die ein Zertifikat gültig ist, und die über das einzelne Feld „Common Name“ hinausgeht. Moderne TLS-Clients und Browser überprüfen die Identität eines Zertifikats anhand seiner SAN-Einträge und nicht anhand des „Common Name“, wodurch SAN praktisch unverzichtbar wird.

Die wichtigsten Erkenntnisse

• SAN listet alle Hostnamen und IP-Adressen auf, die durch ein Zertifikat geschützt sind.
• TLS-Clients überprüfen die Identität anhand der SAN-Einträge und nicht anhand des Common Name.
• RFC 5280 definiert SAN als eine Standarderweiterung für X.509v3-Zertifikate.
• Ein einzelnes Zertifikat kann viele SAN-Einträge unterschiedlicher Art enthalten.
• Versa VMS-Zertifikate erfordern einen SAN-Eintrag für jeden verwendeten FQDN oder jede verwendete IP-Adresse.

Auf dieser Seite: Warum das wichtig ist · So funktioniert es · Arten · SAN & Versa · Häufig gestellte Fragen

Warum ist SAN wichtig?

Jahrzehntelang verglichen TLS-Clients die Identität eines Zertifikats anhand eines einzigen Feldes: dem Common Name (CN). Das funktionierte, solange ein Server nur einen Hostnamen verwendete, was in modernen Infrastrukturen jedoch selten der Fall ist – beispielsweise bei Lastenausgleich über mehrere Namen hinweg, bei einer Domain und ihren Subdomains oder bei einem Gerät, das über mehrere IP-Adressen erreichbar ist. SAN löste dieses Problem, indem es einem Zertifikat ermöglichte, alle Identitäten anzugeben, für die es gültig ist.

Diese Umstellung ist auch für die Sicherheit von Bedeutung. Browser und TLS-Bibliotheken vertrauen bereits seit Jahren nicht mehr auf den „Common Name“ zur Identitätsabgleichung – Chrome hat ihn bereits 2017 als veraltet eingestuft, und die Baseline Requirements des CA/Browser-Forums schreiben nun für jedes öffentlich vertrauenswürdige Zertifikat die Verwendung von SAN vor. Ein Zertifikat ohne passenden SAN-Eintrag scheitert sofort bei der Validierung, unabhängig von seinem „Common Name“. Bei der Ausstellung oder Fehlerbehebung von TLS-Zertifikaten muss man heute in SAN-Kategorien denken, nicht in CN-Kategorien.

Was ist ein SAN?

Der „Subject Alternative Name“ ist eine Zertifikatserweiterung, die in RFC 5280 definiert ist, dem Standard für X.509v3-Zertifikate mit öffentlichem Schlüssel. Es handelt sich um eine dem Zertifikat angehängte Liste, wobei jeder Eintrag einen Typ hat: einen DNS-Namen (am häufigsten), eine IP-Adresse, eine E-Mail-Adresse oder eine URI sowie weitere, seltener verwendete Typen. Ein einzelnes Zertifikat kann viele Einträge enthalten – üblicherweise eine primäre Domain, mehrere Subdomains und eine oder mehrere IP-Adressen.

Wenn ein TLS-Client eine Verbindung herstellt, vergleicht er den von ihm eingegebenen Hostnamen oder die IP-Adresse mit jedem Eintrag in der SAN-Liste; eine Übereinstimmung mit einem beliebigen Eintrag reicht aus, und der Common Name wird ignoriert, selbst wenn er vorhanden ist. Zertifizierungsstellen überprüfen vor der Ausstellung die Eigentumsrechte für jeden Eintrag. Aus diesem Grund bedeutet das Hinzufügen eines Hostnamens zu einem bestehenden Zertifikat, dass dieses mit einer aktualisierten Liste neu ausgestellt wird und nicht, dass ein Feld direkt bearbeitet wird.

Arten von SAN-Einträgen

RFC 5280 definiert mehrere Arten von SAN-Einträgen, wobei sich in der Praxis jedoch einige wenige durchgesetzt haben. DNS-Name (dNSName) Einträge dieser Art sind am häufigsten und identifizieren ein Zertifikat anhand des vollqualifizierten Domänennamens; ein führendes Platzhalterzeichen (*.example.com) umfasst eine gesamte Subdomain-Ebene in einem Eintrag. IP-Adresse (iPAddress) Die Einträge identifizieren ein Zertifikat anhand einer festen IPv4- oder IPv6-Adresse. E-Mail-Adresse und URI Einträge kommen bei S/MIME und anderen Anwendungen außerhalb des Webs vor, bei TLS-Implementierungen hingegen weitaus seltener.

Auf diesen Typen basieren zwei Einsatzszenarien. Ein Multi-Domain-Zertifikat (SAN/UCC) listet mehrere, nicht miteinander in Zusammenhang stehende Domänen in einem Zertifikat auf. Dies ist sinnvoll, wenn eine Organisation viele Dienste betreibt, aber nur ein einziges Zertifikat verwalten möchte. Ein Wildcard-Plus-SAN-Zertifikat kombiniert einen Wildcard-Eintrag mit expliziten Einträgen für Hosts, die nicht unter dieses Muster fallen.

SAN & Versa

Versa Zertifikate des Messaging-Dienstes (VMS) sind der deutlichste Ort, an dem SAN-Einträge in einer „ Versa “-Bereitstellung auftreten. Bei der Installation und Konfiguration von VMS muss jedes Zertifikat – sowohl das Serverzertifikat, das von Agenten und VOS-Geräten verwendet wird, als auch das interne Datenbankzertifikat – einen SAN-Eintrag für jeden FQDN oder jede IP-Adresse enthalten, auf die der Cluster reagiert: die Verwaltungsschnittstelle, die elastische Schnittstelle für den Agentendatenverkehr und die Southbound-Schnittstelle. Sowohl das selbstsignierte Skript als auch der CSR-Workflow, der zur Eingabe von fünf bis sieben SAN-Einträgen auffordert, stellen dies sicher.

Hochverfügbarkeitscluster stellen noch höhere Anforderungen: Eine HA-basierte VMS-Bereitstellung benötigt SAN-Einträge für den FQDN jedes Knotens sowie für den gemeinsam genutzten elastischen FQDN, damit das Zertifikat unabhängig davon gültig bleibt, welcher Knoten die Anfrage beantwortet. Ein fehlender SAN-Eintrag – häufig der elastische FQDN, der nachträglich hinzugefügt wurde – führt häufig zu Verbindungsfehlern, da der Handshake fehlschlägt, obwohl der Netzwerkpfad einwandfrei ist.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem SAN und einem Common Name?

Der Common Name (CN) ist ein einzelnes, veraltetes Identitätsfeld im „Subject“ eines Zertifikats; SAN ist eine Liste, die zahlreiche Identitäten enthält – DNS-Namen, IP-Adressen und mehr. Moderne TLS-Clients führen die Validierung ausschließlich anhand von SAN durch; der CN wird bei der Identitätsprüfung ignoriert, selbst wenn er ausgefüllt ist.

Kann ein Zertifikat einen SAN-Eintrag haben, aber keinen Common Name?

Ja. Die Baseline Requirements des CA/Browser Forums lassen Zertifikate mit einem leeren oder fehlenden Common Name zu, solange ein SAN vorhanden ist, und einige Zertifizierungsstellen lassen den CN mittlerweile standardmäßig weg. Das SAN allein reicht für die Identitätsprüfung aus; der CN spielt dabei keine Rolle mehr.

Warum vertrauen Browser dem „Common Name“ nicht mehr?

Die Verwendung des „Common Name“ führte zu Mehrdeutigkeiten und uneinheitlichen Auswertungen in verschiedenen TLS-Bibliotheken, was Angreifer ausnutzten, um irreführende Zertifikate zu erhalten. Chrome hat die CN-Prüfung im Jahr 2017 als veraltet eingestuft, und das CA/Browser Forum hat später branchenweit die Verwendung von SAN für alle öffentlich vertrauenswürdigen Zertifikate vorgeschrieben.

Was passiert, wenn in einem Zertifikat ein SAN-Eintrag für den aufgerufenen Host fehlt?

Der TLS-Handshake scheitert bei der Validierung – Clients und Browser lehnen die Verbindung mit einem Fehler wegen Namensabweichung ab, selbst wenn der Common Name übereinstimmt oder das Zertifikat ansonsten gültig ist. Die Lösung besteht darin, das Zertifikat neu auszustellen und den fehlenden Host in die SAN-Liste aufzunehmen.

Kann die SAN-Liste eines Zertifikats sowohl DNS-Namen als auch IP-Adressen enthalten?

Ja. Eine einzelne SAN-Liste kann verschiedene Eintragstypen – DNS-Namen, IP-Adressen, E-Mail-Adressen und URIs – enthalten, solange jeder Eintrag von der ausstellenden Zertifizierungsstelle validiert wird. Die Kombination von DNS- und IP-Einträgen ist bei Infrastrukturen üblich, die in beide Richtungen erreichbar sind.

Mehr zum Thema SAN

Wenn Sie mehr erfahren möchten, finden Sie hier Quellen, denen wir vertrauen.

Verwandte Begriffe

Wenn Sie sich gerade mit SAN beschäftigen, sollten Sie sich als Nächstes diese Artikel ansehen.