Wie überprüft ein Enterprise-Linux-System mit OpenSSL 1.0.1+, ob der CN=hostnameWert im Zertifikat mit dem Server übereinstimmt, auf dem es sich befindet? Verwendet es eine einfache alte umgekehrte DNS-Suche nach der IP-Adresse des Adapters, der auf diese SSL-Webanwendung wartet? Verwendet es eine gethostname-Bibliotheksfunktion? Liest es die Datei /etc/hosts? Spielt nsswitch.conf eine Rolle?
Aktualisieren: Nachdem ich mit jemand anderem gesprochen habe, scheint es, dass dies alles auf der Browser-/Clientseite geschieht. Solange der Host-Teil der URL mit dem CN-Wert im für diese Anwendung installierten Zertifikat übereinstimmt, ist der Browser zufrieden, oder?
Antwort1
Ja, was Sie beschrieben haben, ist technisch korrekt, aber es steckt noch ein bisschen mehr dahinter. Der Browser bestimmt anhand einiger Indikatoren, ob der CN des Hosts korrekt ist.
Das wichtigste Anzeichen ist, dass der Host, der das SSL-Zertifikat für den HTTPS-Verkehr bereitstellt, von der richtigen Domäne aus bedient wird und dass auch die Signaturkette des Zertifikats basierend auf der Zertifizierungsstelle (CA, Certification Authority), die das Zertifikat ausgestellt und die Zertifikatskette signiert hat, korrekt ist.
Sie können openssl's verwenden s_client, um ein Gefühl für das Hin und Her zu bekommen, das Ihr Browser auch durchführen würde.
Beispiel
$ openssl s_client -connect encrypted.google.com:443 < /dev/null | head -10
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
...
DONE
Wenn Sie diesen Befehl verwenden, sehen Sie den CN, der beim Generieren der SSL-Zertifikate verwendet wurde:
$ openssl s_client -connect encrypted.google.com:443 < /dev/null|& grep "CN.*google"
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Der Browser bestätigt also, dass der Hostname, der dieses Zertifikat bereitstellt, in die Hierarchie des CN=...im Zertifikat enthaltenen Namens fällt.
SNI
Früher musste für jeden Hostnamen eines SSL-Servers, den Sie über HTTPS nutzen wollten, eine bestimmte IP-Adresse reserviert werden. Dank SNI (Server Name Indication) ist dies jedoch nicht mehr der Fall.
Auszug
Dies funktioniert sehr gut, wenn eine Site ein SSL-Zertifikat pro IP-Adresse installiert hat (früher war dies eine zwingende Voraussetzung). Mit Server Name Indication (SNI) kann ein Webserver mehrere SSL-Zertifikate auf derselben IP-Adresse installiert haben. SNI-fähige Browser geben während des ersten Handshake-Prozesses den Hostnamen des Servers an, den sie zu erreichen versuchen. Dadurch kann der Webserver das richtige SSL-Zertifikat für die Verbindung bestimmen.
Auch hier opensslkönnen Sie simulieren, was Ihr Browser in diesem Szenario tun würde:
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
Auszug
Die SSL-Aushandlung muss vor dem Senden der HTTP-Anforderung an den Remote-Server erfolgen. Das bedeutet, dass Browser und Server den Zertifikatsaustausch früher im Prozess durchführen müssen und der Browser keine Gelegenheit hätte, anzugeben, welche Site er erreichen möchte. SNI behebt dieses Problem, indem es während des SSL-Aushandlungsprozesses einen Austausch des Headertyps „Host:“ zulässt.