SAN in X.509-SSL-Zertifikaten verstehen

Was ist ein alternativer Subjektname (SAN) in SSL/TLS-Zertifikaten? 

Der Subject Alternative Name (SAN) ist eine wichtige Erweiterung des X.509-Zertifikatstandards ( RFC 5280 ). Er ermöglicht es SSL/TLS-Zertifikaten, neben dem Common Name (CN) weitere Identitäten zu enthalten. Dazu gehören beispielsweise Domainnamen, Subdomains, IP-Adressen und E-Mail-Adressen – und somit die sichere Kommunikation über eine Vielzahl von Endpunkten hinweg.

Durch die Nutzung der SAN-Erweiterung können Unternehmen die Flexibilität , Skalierbarkeit und Sicherheit ihrer SSL-Zertifikate deutlich verbessern. Anstatt für jede Domain oder jeden Dienst separate Zertifikate zu verwalten, kann ein einziges SAN-fähiges Zertifikat alle erforderlichen Identitäten absichern. Dies vereinfacht die Zertifikatsverwaltung und reduziert den Betriebsaufwand.

Vor SAN: Die Common Name (CN)-Beschränkung 

Bei früheren SSL-Zertifikaten wurde der durch das Zertifikat geschützte Domainname hauptsächlich über das CN-Feld identifiziert. 

 Ejemplo: 

 Wenn die CN wäre: 

CN = www.example.com 

Das Zertifikat wäre nur gültig für: 

• www.example.com 

Wenn ein Benutzer Folgendes besucht hat: 

• example.com 
• blog.beispiel.com 
• www.example.net 

Sie würden eine Sicherheitswarnung erhalten, da das Zertifikat nicht mit der angeforderten Domain übereinstimmt. Moderne Browser verwenden zur Domainvalidierung nicht mehr das CN-Feld, sondern validieren gemäß den aktuellen Industriestandards ausschließlich anhand der Einträge im SAN-Feld, um eine höhere Sicherheit und Konsistenz zu gewährleisten. 

Nachteile der ausschließlichen Abhängigkeit von CN

• Es konnte nur ein einziger vollqualifizierter Domänenname (FQDN) gesichert werden. 

• Keine Flexibilität zum Einschließen von Subdomänen oder alternativen Domänen. 

• Für mehrere Dienste/Domänen sind separate Zertifikate erforderlich. 

• Veraltete Praxis: Aufgrund von Sicherheitsrisiken und Kompatibilitätsproblemen wird davon abgeraten, sich ausschließlich auf CN zu verlassen, da viele moderne Browser das CN ignorieren und bei der Domänenvalidierung nur der SAN-Liste vertrauen. 

Nach SAN: Mehrere Domänen, ein Zertifikat 

Durch die Verwendung der SAN- Erweiterung kann ein einzelnes SSL/TLS-Zertifikat mehrere Identitäten über verschiedene Dienste hinweg sichern. Zu diesen Identitäten können gehören:

• Subdomains (zB blog.example.com) 
• Völlig unterschiedliche Domänen (zB example.net) 

• IP-Adressen (z. B. 203.0.113.5) – Hinweis: IP-Adressen in SANs müssen genau übereinstimmen; Subnetze oder teilweise Übereinstimmungen werden nicht unterstützt. 
• Interne Hostnamen (zB intranet.local) 
• Wildcard-Domains (z. B. *.example.com) – Wildcard-Einträge in SAN-Feldern haben Einschränkungen: Sie stimmen nur mit einer Subdomain-Ebene überein (z. B. stimmt *.example.com mit blog.example.com überein, aber nicht mit dev.blog.example.com), und nicht alle Zertifizierungsstellen (CAs) unterstützen Wildcard-Einträge in SANs. Überprüfen Sie daher immer die Unterstützung und die Richtlinien der CA, bevor Sie diese verwenden. 

Ejemplo: 

Ein SAN-fähiges Zertifikat könnte Folgendes haben: 

CN = www.example.com 

SAN: 

  DNS.1 = www.example.com 

  DNS.2 = example.com 

  DNS.3 = blog.example.com 

  DNS.4 = www.example.net 

  IP.1 = 203.0.113.5 

Dieses Zertifikat ist für alle aufgeführten DNS- und IP-Einträge gültig. 

Vorteile: 

• Ein einziges Zertifikat kann mehrere Dienste absichern. 
• Vereinfacht die Verwaltung – eine Erneuerung, eine Installation. 
• Es ist kostengünstig, da der Kauf einzelner Zertifikate entfällt. 
• Unterstützt moderne Webinfrastrukturen wie Microservices, APIs und Multi-Domain-Plattformen. 
• SAN ist heute eine obligatorische Komponente in allen öffentlich vertrauenswürdigen
• SSL-Zertifikate gemäß der CA / Browser-Forum Grundlegende Anforderungen: Moderne Browser verlassen sich bei der Domainvalidierung ausschließlich auf das SAN-Feld. 

Warum ein SAN-SSL-Zertifikat verwenden?  

• Sichern Sie mehrere Domänen mit einem Zertifikat
  Sichern Sie alle Domänen unter einem einzigen SSL-Zertifikat, sodass Unternehmen leichter mehrere Websites verwalten können.
  Es ist jedoch wichtig zu beachten, dass jeder SAN-Eintrag bei der Zertifikatsausstellung einzeln validiert werden muss. Die meisten Zertifizierungsstellen verlangen eine DNS- oder HTTP-basierte Domänenvalidierung für jede in der SAN-Liste enthaltene Domäne, um die Eigentumsverhältnisse und die Einhaltung der Sicherheitsstandards zu gewährleisten.
• Vereinfachte Zertifikatsverwaltung
  Reduziert Komplexität und menschliche Fehler durch die Verwaltung, Erneuerung und Bereitstellung nur eines Zertifikats anstelle mehrerer Zertifikate.
• Kosteneffizienz
  Reduziert die Kosten, da nicht mehrere Zertifikate gekauft werden müssen – viele SAN-Zertifikate unterstützen bis zu 100 Domänen.
• Unterstützt komplexe Infrastrukturen
  Perfekt für moderne Setups wie Microservices, APIs und Cloud-Plattformen, die verschiedene Subdomains oder Domains verwenden.
• Erforderlich für die Browserkompatibilität
  Moderne Browser verwenden das SAN-Feld, wodurch SAN ein obligatorischer Bestandteil öffentlicher SSL-Zertifikate ist.
• Skalierbar für zukünftige Erweiterungen
  Das Hinzufügen von Domänen zum Zertifikat während der Erneuerung oder Neuausstellung ist einfach, was für wachsende Unternehmen von Vorteil ist.
• Steigert Vertrauen und SEO
  HTTPS auf allen Domänen schafft Benutzervertrauen, schützt Daten und verbessert das Google-Suchranking.

Wie funktioniert ein SAN-Zertifikat? 

Zertifikatserstellung mit SANs 

Bei der Generierung einer Zertifikatssignieranforderung (CSR) gibt der Administrator eine Liste von SAN-Einträgen an. Dies können sein: 

• Vollqualifizierte Domänennamen (FQDNs) 
• Subdomains 
• IP-Adressen 
• E-mailadressen 
• URIs (für spezielle Anwendungen) 

Um diese SAN-Werte einzuschließen, muss der Administrator sie im Feld „subjectAltName“ in der CSR-Konfigurationsdatei (normalerweise openssl.cnf oder gleichwertig) definieren. 
Sobald der CSR erstellt und an einen CADie Zertifizierungsstelle (CA) überprüft die Inhaberschaft oder Kontrolle jedes SAN-Eintrags. Nach erfolgreicher Validierung stellt die CA ein Zertifikat aus, in dem die SAN-Einträge in der SAN-Erweiterung kodiert sind. 

Browser/Client stellt eine sichere Anfrage 

Wenn ein Client (z. B. ein Browser oder eine App) über HTTPS eine Verbindung zu einer sicheren Website herstellt: 

• Während der TLS-Handschlag, legt der Server dem Client sein SSL-Zertifikat vor. 
• Das Zertifikat beinhaltet: 
  1. Der öffentliche Schlüssel 
  2. Das CN (Legacy-Feld) 
  3. Die SAN-Erweiterung mit allen gültigen Identitäten

Im Rahmen des Handshakes führt der Client eine Hostnamensverifizierung durch, bei der er prüft, ob die angeforderte Domain mit einem der Einträge im SAN-Feld übereinstimmt. Dieser Verifizierungsschritt ist entscheidend für den Aufbau von Vertrauen – moderne Clients verlassen sich für diese Prüfung ausschließlich auf die SAN-Erweiterung und ignorieren das CN-Feld. 

Client validiert die SAN-Liste 

Moderne Browser verwenden stattdessen die SAN-Liste und ignorieren den CN. Der Client sucht nach einer Übereinstimmung zwischen: 

• Der Domänenname, zu dem eine Verbindung hergestellt werden soll. 
• Jeder der im SAN-Feld aufgeführten Namen. 

Die Verbindung wird nur dann sicher hergestellt, wenn eine exakte oder gültige Platzhalterübereinstimmung gefunden wird. 

• Wildcard-Verhalten: Browser unterstützen SAN-Einträge mit Platzhalterdomänen (z. B. *.example.com), der Platzhalter kann jedoch nur einer Subdomänenebene entsprechen. Beispielsweise entspricht *.example.com blog.example.com, aber nicht shop.dev.example.com. 
• Interne Namen: Moderne Browser und Zertifizierungsstellen akzeptieren keine internen Namen (wie localhost oder server.local) mehr in öffentlichen Zertifikaten. Die Verwendung solcher Namen führt dazu, dass das Zertifikat als ungültig oder nicht vertrauenswürdig eingestuft wird. 

Wenn keine Übereinstimmung gefunden wird, zeigt der Browser eine Sicherheitswarnung an, beispielsweise „Ihre Verbindung ist nicht privat“ oder „Ungültiges Zertifikat“. 

Ein Zertifikat, viele Domänen 

Da die SAN-Liste mehrere Identitäten enthält, kann ein Zertifikat für folgende Zwecke verwendet werden: 

• Mehrere Websites (z. B. example.com, example.net) 
• Mehrere Subdomains (z. B. shop.example.com, blog.example.com) 
• Verschiedene Dienste (zB Exchange Server, Mailserver, API-Gateway) 

Dies macht die Verwaltung einfach und unkompliziert, da nun nicht mehr für jede Domäne separate Zertifikate installiert und verwaltet werden müssen. 

Häufige Anwendungsfälle für SAN-Zertifikate (Subject Alternative Name) 

SAN-Zertifikate werden aufgrund ihrer Multi-Domain-Unterstützung in vielen Branchen und Infrastrukturen eingesetzt. Sie ermöglichen den Schutz mehrerer Domains, Subdomains und IP-Adressen mit einem einzigen Zertifikat und sind daher ideal für Organisationen, die sowohl Skalierbarkeit als auch Einfachheit anstreben. 

 Sicherung mehrerer Websites unter einer einzigen Organisation 

Luftüberwachung

Ein Unternehmen besitzt mehrere Websites oder Markendomains: 

• example.com 
• beispiel.net 
• example.org 
• produkt.beispiel.com 
• support.example.net 

Der Kauf und die Verwaltung separater SSL-Zertifikate für jede Domain ist überhaupt nicht mehr erforderlich, da ein Unternehmen jetzt ein einziges SAN-Zertifikat zum Schutz aller Domänen und Subdomänen verwenden kann. 

Hinweis : Jede Subdomain muss explizit im SAN-Feld aufgeführt werden, es sei denn, es wird ein Platzhalter (z. B. *.example.com) verwendet. Ohne Platzhalter erfolgt die Subdomain-Übereinstimmung exakt, und nicht aufgeführte Subdomains sind nicht durch das Zertifikat abgedeckt.

Vorteile

• Zentralisierte Verwaltung 
• Kosteneinsparungen 
• Einfachere Erneuerungen und Installationen 

Sichern von Multi-Subdomain-Anwendungen 

Luftüberwachung 

Eine Webanwendung arbeitet über verschiedene Subdomänen hinweg: 

• login.example.com (Authentifizierung) 
• api.example.com (Backend-API) 
• dashboard.example.com (Benutzerportal) 
• cdn.example.com (Bereitstellung statischer Inhalte) 

Alle Subdomänen werden als SAN-Einträge in einem Zertifikat hinzugefügt. 

Vorteile

• Vereinfacht die Bereitstellung 
• Reduziert die Verbreitung von Zertifikaten 
• Einheitlicher Ablauf- und Erneuerungszyklus 

Cloudbasierte und Microservices-Architekturen 

Luftüberwachung

Moderne Anwendungen, die Mikrodienste oder Cloud-Plattformen nutzen, funktionieren über: 

• Verschiedene Subdomains 
• Separate Regionen oder Instanzen 
• Verschiedene Top-Level-Domains (TLDs) 

Ejemplo: 

• us.api.example.com 
• eu.api.example.net 
• static.cdnexample.org 

Mit einem SAN-Zertifikat können alle diese Dienste geschützt werden, auch wenn sie geografisch verteilt sind oder sich über mehrere Domänen erstrecken. 

Zu beachten ist: SAN-Zertifikate vereinfachen zwar die Verwaltung, doch die Verknüpfung zu vieler Dienste mit einem einzigen Zertifikat kann einen Single Point of Failure darstellen. Läuft das Zertifikat ab, wird es kompromittiert oder muss es neu ausgestellt werden, sind alle davon abhängigen Dienste gleichzeitig betroffen. Um dies zu vermeiden, sollten Unternehmen Dienste sorgfältig nach Risiko und Umgebung gruppieren und gegebenenfalls separate SAN-Zertifikate verwenden.

Vorteile

• Einfachere Zertifikatsautomatisierung (z. B. über CI/CD) 
• Weniger zu erneuernde Zertifikate, weniger Fehlkonfigurationen 
• Sichere Servicekommunikation in Hybrid-Cloud-Setups 

Entwicklungs-, Staging- und Testumgebungen 

Luftüberwachung

Entwickler möchten HTTPS auf lokalen oder Staging-Domänen verwenden: 

• dev.example.local 
• staging.example.com 
• test-api.example.org 

Alle Umgebungen werden durch die Verwendung von SAN-Zertifikaten gesichert, und es besteht keine Notwendigkeit für mehrere Zertifikate. 

Für interne Umgebungen wie .local-Domains (z. B. dev.example.local) wird die Verwendung einer internen Zertifizierungsstelle (CA) oder eines selbstsignierten SAN-Zertifikats empfohlen. Öffentliche Zertifizierungsstellen stellen aufgrund von Sicherheitsbeschränkungen des CA/Browser-Forums keine Zertifikate mehr für interne Domains aus. 

Vorteile

• Ermöglichen Sie genaue und sichere Tests unter realen Bedingungen HTTPS Gesundheitsproblemen. 
• Schnellere CI/CD-Testpipelines. 
• Der Aufwand für die manuelle Zertifikatsverwaltung wird reduziert. 

Microsoft Exchange Server und Office 365 

Luftüberwachung 

Microsoft Exchange und Skype for Business benötigen SAN-Zertifikate, damit sie mit verschiedenen internen und externen Diensten ordnungsgemäß funktionieren, wie zum Beispiel: 

• mail.beispiel.com 
• autodiscover.example.com 
• smtp.example.net 
• Interner Austausch.lokal 

Um die Bereitstellung zu vereinfachen, empfiehlt Microsoft Zertifikate, die mehrere SAN-Einträge unterstützen. 

In solchen Szenarien kommt häufig ein Unified Communications Certificate (UCC) zum Einsatz. Obwohl UCC oft als Spezialzertifikat bezeichnet wird, handelt es sich im Wesentlichen um einen Marketingbegriff für ein Multi-SAN-Zertifikat, das für Microsoft-Anwendungen wie Exchange, Skype for Business und Office 365 optimiert ist.

Vorteile

• Vollständige Unterstützung des vertrauenswürdigen Frameworks von Microsoft für die Zertifikatsverwaltung. 
• Sie benötigen nicht mehrere Zertifikate, ein Zertifikat kann alle Dienste (E-Mail, Kalender, automatische Erkennung usw.) sichern. 
• Einfache Einrichtung für hybride Office 365-Bereitstellungen 

Was Sie bei der Auswahl einer CA für SAN-Zertifikate beachten sollten

Ruf und Vertrauensniveau

Wählen Sie eine weltweit vertrauenswürdige Zertifizierungsstelle, die: 

• Wird von allen führenden Browsern und Betriebssystemen erkannt. 
• Einhaltung aller Richtlinien gemäß den Standards von CA/Browser Forum. 
• Bekannt für die Umsetzung hoher Sicherheitsstandards. 

Beliebte vertrauenswürdige Zertifizierungsstellen: 

• DigiCert 
• Sectigo (ehemals Comodo) 
• Anvertrauen 
• Global 
• Los Papa 
• Let's Encrypt (für begrenzte Anwendungsfälle, unterstützt SAN) 

Hinweis: Let's Encrypt genießt zwar hohes Vertrauen und eignet sich ideal für kurzfristige, automatisierte Bereitstellungen, ist aber möglicherweise nicht geeignet für längere Zertifikatslebensdauern oder komplexe Unternehmensanforderungen , die eine erweiterte Validierung (EV) , eine Organisationsvalidierung (OV) oder erweiterte Support- und Berichtsfunktionen erfordern.

Warum das wichtig ist: Bei öffentlichem Vertrauen sehen die Benutzer keine Warnungen über „Nicht vertrauenswürdige Zertifikate“. 

Preise und Lizenzierung 

Die Preise für SAN-Zertifikate können schwanken, abhängig von: 

• Anzahl der enthaltenen SANs (einige enthalten standardmäßig 2–5 SANs) 
• Kosten pro zusätzlichem SAN-Eintrag 
• Validierungsstufe (DV, OV, EV) 

Achtung: Achten Sie auf mögliche Anbieterabhängigkeit und unerwartete Verlängerungskosten . Manche Zertifizierungsstellen bieten niedrige Einstiegspreise, verlangen aber bei Verlängerungen oder beim Hinzufügen neuer SAN-Einträge deutlich höhere Gebühren. Prüfen Sie daher vor Vertragsabschluss immer das vollständige Preismodell und die Verlängerungsbedingungen.

Warum das wichtig ist: Die Skalierbarkeit kann durch die Preisgestaltung beeinflusst werden, insbesondere wenn viele Domains gleichzeitig verwaltet werden.

Zertifikatsvalidierungstyp 

CAs bieten drei Arten der Validierung an: 

Validierungstyp	Verifizierungsstufe	Vertrauensindikatoren	Am besten geeignet für
DV (Domänenvalidierung)	Überprüft nur den Domänenbesitz	Vorhängeschloss im Browser	Interne Websites, persönliche Blogs, Anwendungen mit geringem Risiko
OV (Organisationsvalidierung)	Überprüft die Domänen- und Organisationsidentität	Vorhängeschloss + Organisationsdetails in den Zertifikatsinformationen	Unternehmenswebsites, APIs, öffentlich zugängliche Apps
EV (Erweiterte Validierung)	Umfassende Prüfung des Geschäfts und der rechtlichen Existenz	Vorhängeschloss + Organisationsname in der Adressleiste des Browsers (in einigen Browsern)	Finanzdienstleistungen, E-Commerce, regulierte Branchen

Für den Umgang mit sensiblen Daten, die Ausführung öffentlicher Dienste oder das Streben nach hohem Vertrauen sollten Sie OV oder EV wählen. 

Einfache Zertifikatsverwaltung 

Suchen Sie nach CAs, die Folgendes anbieten: 

• Management-Dashboards oder APIs 
• Zertifikatsautomatisierung (z. B. über ACME Protokoll) 
• Erneuerungserinnerungen 
• SAN unterstützt flexible Neuausstellung (Domänen einfach hinzufügen/entfernen) 

Warum das wichtig ist: Effizientes und vereinfachtes Management reduziert den Aufwand und hilft bei Problemen mit dem Ablauf von Zertifikaten. 

Unterstützung für benutzerdefinierte Anforderungen

Halten: 

• Wildcard-SAN-Unterstützung (z. B. *.example.com) 
• Einbeziehung der IP-Adresse 
• Interne Domänenunterstützung (z. B. dev.local) 
• Integration in Ihre Infrastruktur (z. B. Microsoft Exchange, AWS, Kubernetes) 

Hinweis: Nicht alle Zertifizierungsstellen unterstützen die Kombination von Wildcard-Domänen und SAN-Einträgen in einem Zertifikat. Einige unterliegen Einschränkungen oder erfordern eine andere Produktstufe. Prüfen Sie diese Funktion unbedingt, falls Ihr Anwendungsfall beides umfasst.

Warum das wichtig ist: Manche Zertifizierungsstellen benötigen spezielle Konfigurationen oder bieten nur eingeschränkte Unterstützung für interne Namen, IP-Adressen oder komplexe Wildcard-/SAN-Setups – das Verständnis dieser Einschränkungen hilft, Bereitstellungsprobleme zu vermeiden.

Kundensupport und SLAs 

Bei der Bewertung von Zertifizierungsstellen sollten Sie diejenigen priorisieren, die Folgendes bieten:

• 24/7 Kundendienst 
• Schnelle Ausstellung und Neuausstellung von SLAs 
• Dedizierter Unternehmenssupport (für große Bereitstellungen) 

Die Zeit bis zur Ausstellung ist wichtigManche Zertifizierungsstellen können Domain-Validierungszertifikate (DV) innerhalb von Minuten ausstellen, während die Ausstellung von OV/EV-Zertifikaten je nach Verifizierungsprozess Stunden oder Tage dauern kann. 
Ausfallzeit bei Neuausstellung Auch folgende Punkte sollten berücksichtigt werden: Verzögerungen beim Ersetzen abgelaufener oder kompromittierter Zertifikate können zu Dienstunterbrechungen oder Sicherheitswarnungen für Benutzer führen. 

Warum das wichtig ist: Rechtzeitige Unterstützung ist unerlässlich bei Ausfällen oder Vertragsverlängerungen.

Wie Verschlüsselungsberatung helfen kann 

Die Verwaltung von SAN-Zertifikaten für mehrere Domänen, Subdomänen und IPs kann schnell zu einer Herausforderung werden – insbesondere bei großem Umfang. Hier kommt der CertSecure Manager von Encryption Consulting ins Spiel. 

Unsere Lösung für das Zertifikatslebenszyklusmanagement (CLM) automatisiert und optimiert den gesamten Prozess – von der Ermittlung und Ausstellung bis hin zur Verlängerung und dem Widerruf. Ob Sie interne Dienste, Cloud-Workloads oder komplexe Multi-Domain-Umgebungen absichern möchten, CertSecure Manager bietet Ihnen:

• Zentralisiertes Zertifikatsinventar, einschließlich SAN-Einträgen 
• Automatisierte Ausstellung und Erneuerung durch führende Zertifizierungsstellen 
• Richtliniengesteuerte Kontrollen und Genehmigungsworkflows 
• Echtzeitwarnungen zur Vermeidung von Ablaufdaten oder Fehlkonfigurationen 
• Detaillierte Prüfprotokolle und Compliance-Berichte 

Unterstützte Integrationen: CertSecure Manager lässt sich nahtlos über seine APIs in gängige Zertifizierungsstellenplattformen wie DigiCert, Sectigo und andere integrieren . Zudem unterstützt er Clients, die auf dem ACME-Protokoll basieren (z. B. Let's Encrypt), und kann Verbindungen zu Infrastrukturtools wie Microsoft CA, AWS und Azure Key Vault herstellen.

Mit CertSecure Manager können Unternehmen SAN-SSL-Zertifikate effizient, transparent und kontrolliert verwalten – alles von einer einzigen Plattform aus. 

Fazit 

SAN-Zertifikate bieten eine intelligente und skalierbare Lösung zur Absicherung mehrerer Domains, Subdomains und Dienste mit einem einzigen Zertifikat. Ob Sie eine komplexe Infrastruktur verwalten oder einfach nur die SSL-Verwaltung vereinfachen möchten: SAN-Zertifikate bieten Flexibilität, Kosteneffizienz und hohe Sicherheit – und sind damit unverzichtbar für moderne digitale Umgebungen.