Angenommen, die SAN-Eigenschaft (Subject Alternative Name) eines SSL-Zertifikats enthält zwei DNS-Namen

1. domain.tld
2. host.domain.tld

Der Common Name (CN) ist jedoch nur auf einen von beiden festgelegt : CN=domain.tld.

• Hat dieses Setup eine besondere Bedeutung oder irgendwelche [Nachteile] gegenüber dem Einstellen beider CNs?
• Was passiert auf der Serverseite, wenn der andere host.domain.tldangefordert wird?

BEARBEITEN:

Wie aus Eugenes Antwort kürzlich hervorgeht, dass sich das Verhalten je nach Implementierung unterscheidet, möchte ich genauer darauf eingehen : Wie geht OpenSSL 0.9.8b + mit dem gegebenen Szenario um?

Dies hängt von der Implementierung ab. Die allgemeine Regel lautet jedoch, dass die Domäne mit allen SANs und dem allgemeinen Namen verglichen wird. Wenn die Domain dort gefunden wird, ist das Zertifikat für die Verbindung in Ordnung.

In RFC 5280 , Abschnitt 4.1.2.6 heißt es: "Der Betreffname darf im Betrefffeld und / oder in der Erweiterung subjectAltName enthalten sein." Dies bedeutet, dass der Domänenname sowohl mit der SubjectAltName-Erweiterung als auch mit der Subject-Eigenschaft (nämlich dem Common Name-Parameter) des Zertifikats verglichen werden muss. Diese beiden Stellen ergänzen sich und duplizieren sie nicht. Und SubjectAltName ist ein geeigneter Ort, um zusätzliche Namen wie www .domain.com oder www2 einzufügen .domain.com einzufügen

Update: Gemäß RFC 6125 , veröffentlicht in '2011, muss der Validator zuerst das SAN überprüfen. Wenn SAN vorhanden ist, sollte CN nicht überprüft werden. Beachten Sie, dass der RFC 6125 relativ neu ist und es noch Zertifikate und Zertifizierungsstellen gibt, die Zertifikate ausstellen, einschließlich des "Haupt" -Domänennamens in CN und alternativer Domänennamen in SAN. Wenn Sie CN von der Validierung ausschließen, wenn SAN vorhanden ist, können Sie ein ansonsten gültiges Zertifikat verweigern.

Um absolut korrekt zu sein, sollten Sie alle Namen in das SAN-Feld eingeben.

Das CN-Feld sollte einen Betreffnamen enthalten, keinen Domainnamen, aber als Netscape dieses SSL-Ding herausfand, versäumte es, seinen größten Markt zu definieren. Es wurde einfach kein Zertifikatfeld für die Server-URL definiert.

Dies wurde gelöst, um die Domäne in das CN-Feld zu stellen, und heutzutage ist die Verwendung des CN-Feldes veraltet, wird aber immer noch häufig verwendet. Der CN kann nur einen Domainnamen enthalten.

Die allgemeinen Regeln hierfür: CN - Geben Sie hier Ihre Haupt-URL ein (aus Kompatibilitätsgründen). SAN - Geben Sie hier Ihre gesamte Domain ein. Wiederholen Sie den CN, da er dort nicht an der richtigen Stelle ist, aber dafür verwendet wird.

Wenn Sie eine korrekte Implementierung gefunden haben, lauten die Antworten auf Ihre Fragen wie folgt:

• Hat dieses Setup eine besondere Bedeutung oder irgendwelche [Nachteile] gegenüber dem Einstellen beider CNs? Sie können nicht beide CNs festlegen, da CN nur einen Namen enthalten kann. Sie können mit 2 einfachen CN-Zertifikaten anstelle eines CN + SAN-Zertifikats erstellen, benötigen dafür jedoch 2 IP-Adressen.

• Was passiert auf der Serverseite, wenn die andere, host.domain.tld, angefordert wird? Es spielt keine Rolle, was auf der Serverseite passiert.

Kurz gesagt: Wenn ein Browser-Client eine Verbindung zu diesem Server herstellt, sendet der Browser verschlüsselte Pakete, die mit dem öffentlichen Schlüssel des Servers verschlüsselt sind. Der Server entschlüsselt das Paket. Wenn der Server entschlüsseln kann, wurde es für den Server verschlüsselt.

Der Server kennt vor dem Entschlüsseln nichts vom Client, da nur die IP-Adresse über die Verbindung nicht verschlüsselt wird. Aus diesem Grund benötigen Sie 2 IPs für 2 Zertifikate. (Vergiss SNI, es gibt noch zu viel XP da draußen.)

Auf der Clientseite erhält der Browser den CN und dann das SAN, bis alle überprüft wurden. Wenn einer der Namen mit der Site übereinstimmt, wurde die URL-Überprüfung vom Browser durchgeführt. (Ich spreche nicht über die Zertifikatsüberprüfung, natürlich werden jedes Mal viele OCP-, CRL-, AIA-Anfragen und -Antworten im Internet gesendet.)

CABForum-Basisanforderungen

Ich sehe, dass noch niemand den Abschnitt in den Basisanforderungen erwähnt hat. Ich finde sie wichtig.

F: SSL - Wie arbeiten Common Names (CN) und Subject Alternative Names (SAN) zusammen?
EIN: Überhaupt nicht. Wenn es SANs gibt, kann CN ignoriert werden. - Zumindest wenn die Software, die die Überprüfung durchführt, die Grundanforderungen des CABForum sehr genau einhält.

(Das bedeutet also, dass ich Ihre Frage nicht mit "Bearbeiten" beantworten kann. Nur die ursprüngliche Frage.)

CABForum-Basisanforderungen, Version 1.2.5 (Stand: 2. April 2015), Seite 9-10 :

9.2.2 Unterscheidbare Namensfelder des Subjekts
a. Feld "Allgemeiner Name des Betreffs"
Zertifikatfeld: Betreff: commonName (OID 2.5.4.3)
Erforderlich / Optional: Veraltet (entmutigt, aber nicht verboten)
Inhalt: Falls vorhanden, MUSS dieses Feld eine einzelne IP-Adresse oder einen vollständig qualifizierten Domänennamen enthalten der in der Erweiterung subjectAltName des Zertifikats enthaltenen Werte (siehe Abschnitt 9.2.1).

EDIT: Links von @ Brunos Kommentar

RFC 2818: HTTP über TLS , 2000, Abschnitt 3.1: Serveridentität :

Wenn eine subjectAltName-Erweiterung vom Typ dNSName vorhanden ist, MUSS diese als Identität verwendet werden. Andernfalls MUSS das Feld (spezifischster) Common Name im Feld Subject des Zertifikats verwendet werden. Obwohl die Verwendung des allgemeinen Namens bereits üblich ist, wird sie nicht mehr empfohlen, und Zertifizierungsstellen werden aufgefordert, stattdessen den dNSName zu verwenden.

RFC 6125: Darstellung und Überprüfung der domänenbasierten Anwendungsdienstidentität in der Internet-Public-Key-Infrastruktur unter Verwendung von X.509 (PKIX) -Zertifikaten im Kontext der Transport Layer Security (TLS) , 2011, Abschnitt 6.4.4: Überprüfung allgemeiner Namen :

[...] Wenn und nur wenn die dargestellten Bezeichner keine DNS-ID, SRV-ID, URI-ID oder vom Client unterstützte anwendungsspezifische Bezeichnerarten enthalten, kann der Client als letzten Ausweg prüfen Eine Zeichenfolge, deren Form mit der eines vollständig qualifizierten DNS-Domänennamens in einem Feld "Allgemeiner Name" des Betrefffelds (dh einer CN-ID) übereinstimmt.