fabian-riedel
Anmeldungsdatum: 6. März 2010
Beiträge: 16
Wohnort: Ammerbuch-Entringen, Baden-Württemberg
|
Abend miteinander, ich habe gerade an meinen privaten Webserver, der bei mir im Netzwerk läuft mit dieser Anleitung Apache/SSL SSL aktiviert. Soweit so gut, der Server wird über https erreicht, nur behauptet er: The certificate is not valid for the name 192.168.0.2., dabei habe ich als Common Name eben diese IP angegeben. Wenn ich mir nun im Firefox das Zertifikat anschaue wird als CN allerdings "xubuntu" angegeben. (Mein Server läuft auf Xubuntu) → Screenshot der Tragödie Auch nach mehrmaligem Wiederholen. Wie bekomme ich den richtigen CN dort rein und ist es überhaupt richtig, dass dieser gleich meiner IP ist, wenn ich nur über die Adresse auf den Server zugreife. Liebe Grüße
- Bilder
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
fabian-riedel schrieb: ... ist es überhaupt richtig, dass dieser gleich meiner IP ist, wenn ich nur über die Adresse auf den Server zugreife.
Nein, denn wenn Du nicht "Host + Domain Name" als CN verwenden willst, dann solltest Du z. B. den Namen des Servers für CN verwenden und nicht die IP-Adresse.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
fabian-riedel schrieb: Wie bekomme ich den richtigen CN dort rein und ist es überhaupt richtig, dass dieser gleich meiner IP ist, wenn ich nur über die Adresse auf den Server zugreife.
Wie stellst du die Zertifikate denn aus? Ich habe mir mit meiner CA gerade ein Zertifikat für 192.168.0.1 ausgestellt, das hat funktioniert. Ich bin mir aber nicht ganz sicher, ob das ein guter Plan ist. Ich würde lieber einen korrekten Hostname als CN verwenden, anstatt der IP. IPs als CommonNames sind zwar nicht verboten, aber bad practice. Zusätzlich haben sich die Mitglieder des Certificate Authorities Browser Forum festgelegt, dass Zertifikate ohne FQDN ab 1. Oktober 2016 revoked werden [1] [2]. Das gilt zwar nur für öffentliche und nicht für self-signed CAs, ich weiß aber nicht, ob und wie lange die Browser solche Zertifikate noch akzeptieren. [1] https://de.godaddy.com/help/intranetnamen-und-ip-adressen-in-ssls-auslaufen-lassen-6935 [2] https://www.entrust.com/ssl-certificates-without-non-fqdns/
|
tskv
Anmeldungsdatum: 5. Oktober 2011
Beiträge: 149
Wohnort: Vaals
|
CN: *.mylocaldom.tld Ein Wildcard Zertifikat, welches alle Domains/Subdomains namentlich bedient. Für die komfortable Erstellung der Zertifikate via Gui: tinyca
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
tskv schrieb: CN: *.mylocaldom.tld Ein Wildcard Zertifikat, welches alle Domains/Subdomains namentlich bedient.
Falsch. Es ist ausschließlich für Subdomains von mylocaldom.tld gültig. Es ist weder für 192.168.0.2 gültig, noch für mylocaldom.tld selbst.
|
tskv
Anmeldungsdatum: 5. Oktober 2011
Beiträge: 149
Wohnort: Vaals
|
Ja, sorry. Das ist korrekt. Ich betreibe alle ssl-Sites (wie www.mydom.tld) als Subdomains. Käme denn ein Name-based virtual host auch mit einem Zertifikat klar, welches auf eine ip ausgestellt ist?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
tskv schrieb: Käme denn ein Name-based virtual host auch mit einem Zertifikat klar, welches auf eine ip ausgestellt ist?
Der Webserver kommt damit klar, denn ihm ist es egal, was im CommonName des Zertifikats steht. Serverseitig findet da keine Validierung statt. Die Frage ist, ob es ein Client akzpetiert, also Browser oder Tools wie curl. Aktuell ist das der Fall, man kann das also machen.
|
tskv
Anmeldungsdatum: 5. Oktober 2011
Beiträge: 149
Wohnort: Vaals
|
Cool, das eröffnet neue Möglichkeiten - vorausgesetzt, es funktioniert auch mit Mail Diensten. Wieder was gelernt. Danke für den Hinweis.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
tskv schrieb: Cool, das eröffnet neue Möglichkeiten - vorausgesetzt, es funktioniert auch mit Mail Diensten. Wieder was gelernt. Danke für den Hinweis.
Zum Testen.
|
tskv
Anmeldungsdatum: 5. Oktober 2011
Beiträge: 149
Wohnort: Vaals
|
Geht leider noch nicht. Mein Mailserver läuft (noch) im lokalen Netz. Zum Üben. EDIT: Habe etwas nachgelesen. Im LAN kann man Zertifikate mit IP Adresse nutzen. Öffentlich scheint es zu gehen, wird aber nicht angeraten.
The Certificate Authority/Browser Forum has decided that certificates that are issued to anything but a fully qualified domain name (FQDN), which IP addresses are not, will be revoked on October 1, 2016. This means that unless you use a self signed certificate, it will not be possible. Therefore, certificates with IP addresses will soon not be practical except for testing or personal use.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5323
|
tskv schrieb: EDIT: Habe etwas nachgelesen. Im LAN kann man Zertifikate mit IP Adresse nutzen. Öffentlich scheint es zu gehen, wird aber nicht angeraten.
Du kannst dir selbst Zertifikate mit beliebigen CNs anstellen. Solange diese aber von keiner anerkannten CA unterschrieben sind, vertraut diesen aber niemand (ausser dir selbst nach pruefung des fingerprints). Und eine CA wird dir kein Zertifikat mit IP unterschreiben, das sagt dein Zitat aus. Laut deinem Screenshot hast du das Zertifikat nicht auf die IP ausgestellt, sondern auf den Hostnamen des Servers. Zeige mal, wie du das Zertifikat erstellt hast.
|
tskv
Anmeldungsdatum: 5. Oktober 2011
Beiträge: 149
Wohnort: Vaals
|
Sorry, ich hatte mich in diesen Thread reingemogelt. Der Screenshot ist nicht von mir. Ich habe meine Zertifikate jetzt neu erstellt. Keine Wildcard mehr, sondern mittels Subject Alternative Name(s) sind alle benötigten Domains und Subdomains inkludiert. CN={FQDN}. Klappt wunderbar.
|