Sind SSL-Zertifikate an die IP-Adresse des Servers gebunden?


75

Wir haben zwei verschiedene LDAP-Anbieter an zwei verschiedenen Standorten.

Wenn ich meinen Laptop an einen Ort anschließe und vom Port (in Websphere 6.1) abrufe, um das SSL-Zertifikat des LDAP-Anbieters zu importieren, kann ich mich problemlos bei der jeweiligen LDAP authentifizieren. Wenn ich meinen Laptop in ein anderes Büro bringe (das standardmäßig den anderen ldap-Anbieter verwendet) und meinen Laptop anschließe, wird mein WAS auf meinem Laptop nicht gestartet, da dort "kein vertrauenswürdiges SSL-Zertifikat gefunden" steht.

Wenn ich erneut vom Port abrufe und das Zertifikat erneut importiere, funktioniert es erneut.

Beachten Sie, dass mein WAS immer versucht, eine Verbindung zu einem ldap herzustellen, es hat einfach keine Verwendung für das andere.

Wenn ich zum anderen Büro zurückkehre, wird der gleiche Fehler angezeigt, bis ich von diesem Ort aus erneut importiere. Der ldap-Verbindungspunkt lautet ldap.something.com:636 und kann an beiden Standorten mit demselben vollqualifizierten Domänennamen gepingt werden.

Beim Ping wird es jedoch in eine andere IP-Adresse in jedem Bürostandort aufgelöst. Warum sehe ich dieses Verhalten?

Sind SSL-Zertifikate irgendwie an eine bestimmte IP-Adresse gebunden?

Wenn ja, muss ich für jeden Bürostandort einen anderen Satz von Zertifikaten verwalten, oder?

Beachten Sie, dass es keine Möglichkeit gibt, die DNS-Server so anzupassen, dass der Hostname in dieselbe IP-Adresse aufgelöst wird, die ich überprüft habe.

Kann jemand einen Einblick geben?

Antworten:


69

SSL-Zertifikate sind an einen "allgemeinen Namen" gebunden, bei dem es sich normalerweise um einen vollständig qualifizierten Domänennamen handelt, der jedoch ein Platzhaltername (z. B. * .domain.com) oder sogar eine IP-Adresse sein kann, dies ist jedoch normalerweise nicht der Fall.

In Ihrem Fall greifen Sie über einen Hostnamen auf Ihren LDAP-Server zu, und es scheint, als hätten auf Ihren beiden LDAP-Servern unterschiedliche SSL-Zertifikate installiert. Können Sie die Details des SSL-Zertifikats anzeigen (oder herunterladen und anzeigen)? Jedes SSL-Zertifikat verfügt über eindeutige Seriennummern und Fingerabdrücke, die übereinstimmen müssen. Ich gehe davon aus, dass das Zertifikat abgelehnt wird, da diese Angaben nicht mit den Angaben in Ihrem Zertifikatspeicher übereinstimmen.

Ihre Lösung besteht darin, sicherzustellen, dass auf beiden LDAP-Servern dasselbe SSL-Zertifikat installiert ist.

Übrigens: Normalerweise können Sie DNS-Einträge auf Ihrer Workstation überschreiben, indem Sie eine lokale Hosts-Datei bearbeiten. Dies würde ich jedoch nicht empfehlen.


1
Wie kann ein SSL-Zertifikat für die IP-Adresse verwendet / registriert werden?
i486

5

Die meisten SSL-Zertifikate sind an den Hostnamen des Computers und nicht an die IP-Adresse gebunden.

Sie erhalten möglicherweise eine bessere Antwort, wenn Sie diese Frage auf serverfault.com stellen


5
Meinen Sie wirklich den Hostnamen oder den Domainnamen der Site, die bedient wird? Ein Server mit dem Hostnamen despairkann sowohl die foo.comals auch die bar.netWebsites hosten .
Dotancohen

17
Dies beantwortet die Frage nicht.
Pavlo

3
@Pavlo .. Nein, aber es stellt die Antwort richtig in Frage.
Gavin Jackson

5

Die SSL-Zertifikate werden eher an den Hostnamen als an die IP gebunden, wenn sie auf die Standardmethode eingerichtet werden. Daher funktioniert es eher an einem Standort als am anderen.

Selbst wenn die Server denselben Hostnamen verwenden, haben sie möglicherweise zwei verschiedene Zertifikate, und daher tritt bei WebSphere ein Problem mit der Vertrauenswürdigkeit von Zertifikaten auf, da das Zertifikat auf dem zweiten Server nicht erkannt werden kann, da es sich vom ersten unterscheidet.


2
Eine der Antworten des technischen Agenten des Hosting-Anbieters lautet: Das SSL ist an dieser bestimmten IP-Adresse signiert. Es muss erneut ausgestellt werden, wenn Sie die IP-Adresse der Site verschieben möchten, die das SSL verwendet.
Bimal Poudel
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.