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-Zertifikat Standard, definiert in RFC 5280. SSL/TLS-Zertifikate können mehrere Identitäten enthalten, die über das Feld „Common Name“ (CN) hinausgehen. Diese Identitäten können Domänennamen, Subdomänen, IP-Adressen, E-Mail-Adressen und mehr umfassen und ermöglichen so eine sichere Kommunikation über eine Vielzahl von Endpunkten hinweg. 

Durch die Verwendung der SAN-Erweiterung können Unternehmen die Flexibilität, Skalierbarkeit und Sicherheitdienst ihrer SSL-Zertifikate. Anstatt separate Zertifikate für jede Domäne oder jeden Dienst zu verwalten, kann ein SAN-fähiges Zertifikat alle erforderlichen Identitäten unter einem einzigen Zertifikat sichern, was die Zertifikatsverwaltung vereinfacht und den Betriebsaufwand reduziert. 

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, eine einzelne SSL / TLS-Zertifikat kann sichern mehrere Identitäten über verschiedene Dienste hinweg. Diese Identitäten können Folgendes umfassen: 

• 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 Subdomäne muss explizit im SAN-Feld aufgeführt sein, es sei denn, es ist ein Platzhaltereintrag (z. B. *.example.com) enthalten. Ohne Platzhalter ist die Subdomänenübereinstimmung exakt, und nicht aufgeführte Subdomänen werden vom Zertifikat nicht 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. 

Berücksichtigung: SAN-Zertifikate vereinfachen zwar die Verwaltung, doch die Verknüpfung zu vieler Dienste mit einem einzigen Zertifikat kann zu einem Single Point of Failure führen. Läuft das Zertifikat ab, wird es kompromittiert oder muss es neu ausgestellt werden, sind alle darauf angewiesenen Dienste gleichzeitig betroffen. Um dies zu vermeiden, sollten Unternehmen ihre 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. 

A Unified Communications-Zertifikat (UCC) wird in diesen Szenarien häufig verwendet. Obwohl UCC allgemein 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: Während Lass uns verschlüsseln ist weithin vertrauenswürdig und ideal für kurzfristige, automatisierte Bereitstellungen, es kann nicht für längere Zertifikatslaufzeiten geeignet sein or komplexe Unternehmensanforderungen das benötigt erweiterte Validierung (EV), Organisationsvalidierung (OV) oder erweiterte Support- und Berichtsfunktionen. 

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) 

Vorsicht: Seien Sie sich des Potenzials bewusst Lieferantenbindung und unerwartete ErneuerungskostenEinige Zertifizierungsstellen bieten niedrige Einstiegspreise, verlangen aber bei der Verlängerung oder beim Hinzufügen neuer SAN-Einträge deutlich höhere Gebühren. Überprüfen Sie vor der Vertragserfüllung immer das vollständige Preismodell und die Verlängerungsbedingungen. 

Warum es darauf ankommt: Die Skalierbarkeit kann durch die Preisgestaltung beeinträchtigt werden, insbesondere wenn viele Domänen 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. Manche schränken die Anforderungen ein oder erfordern eine andere Produktstufe. Prüfen Sie diese Funktion unbedingt, falls Ihr Anwendungsfall beides umfasst. 

Warum es darauf ankommt: Einige CAs benötigen möglicherweise spezielle Konfigurationen oder bieten eingeschränkte Unterstützung für interne Namen, IP-Adressen oder komplexe Wildcard-/SAN-Setups. Wenn Sie diese Einschränkungen kennen, können Sie Bereitstellungsprobleme vermeiden. 

Kundensupport und SLAs 

Bei der Auswertung von a CA, priorisieren Sie diejenigen, 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 es darauf ankommt: Bei Ausfällen oder Erneuerungen ist eine rechtzeitige Unterstützung unerlässlich. 

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 Zertifikatslebenszyklusverwaltung (CLM) Die Lösung automatisiert und optimiert den gesamten Prozess – von der Erkennung und Ausstellung bis hin zur Erneuerung und Sperrung. Unabhängig davon, ob Sie interne Dienste, Cloud-Workloads oder komplexe Multi-Domain-Umgebungen sichern, CertSecure Manager bietet: 

• 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 integriert sich nahtlos in große CA-Plattformen wie DigiCert, Sectigo und andere über ihre APIsEs unterstützt außerdem Clients, die auf dem ACME-Protokoll basieren (z. B. Let's Encrypt), und kann Verbindungen zu Infrastrukturtools wie Microsoft CA, AWS und anderen herstellen. Azure Key Vault. 

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.