Hallo Allerseits!
Wir haben mehrere ISPC2 und ISPC3 Server am laufen. Bisher hatten wir die Kundenpräsenzen, welche ein Zertifikat benötigen auf den ISPC2's am laufen, was bis jetzt auch keinerlei Probleme bereitet hat.
Nun haben wir eine Kundenpräsenz aufgrund eines Relaunchs von einer ISPC2 Maschine auf eine ISPC3 umgezogen. Das hat (wie auch bei allen vorherigen "Umzügen") hervorragend funktioniert, bis auf die Sache mit dem SSL.
Ich habe die DNS Einträge entsprechend umgestellt. Anfragen kommen mit der richtigen IP auf der 3er Maschine an. Im http-Betrieb funktioniert alles bestens.
Ich habe nun versucht das Zertifikat umzuziehen, leider ohne Erfolg. Mein Vorgehen war alle Einträge (sofern möglich) genau so am 3er einzutragen wie beim 2er. Dabei habe ich die Einträge für SSL-Request und SSL Zertifikat per Copy&Paste übernommen. Die anderen Zeilen konnte ich nur zum Teil übernehmen, da es beim 3er nur "Lokalität" aber keinen "Ort" gibt und zudem bei Lokalität keine deutschen Sonderzeichen erlaubt sind, auf dem 2er jedoch ein "Ort" mit nem "ö" drin angegeben ist. Schlagt mich jetzt nicht, ich weis nicht wer von unseren Helden (evtl sogar ich) auf die dumme Idee mit dem Sonderzeichen gekommen ist. Eine "Haltbarkeitsdauer" für das Zertifikat kann ich beim 3er auch nicht mehr angeben. Für SSL-Bundle konnte ich gar nix angeben.
Ich habe dann gespeichert und brav ein paar Minuten auf die Job-Queue gewartet. Leider bekomme ich beim Aufruf im Browser nur ein
ssl_error_rx_record_too_long
gemeldet. Auch ein selbstsigniertes Zertifikat anzulegen gelingt mir zwar (delete/create certificate) aber ich bekomme selbes Ergebnis.
Es ist, wie gesagt das erste mal, dass ich auf nem ISPC3 eine Seite mit Zertifikat anlege, vllt ist der Fehler auch ganz woanders zu suchen, was ich jedoch nicht recht glauben kann.
Wäre nett wenn jemand einen Hinweis für mich hätte wo ich weiter graben soll/kann/darf..
Gruß,
Thomas
Nachtrag:
Ich habe noch etwas im Netz gestöbert und hab auf der Konsole folgendes probiert:
a2enmod ssl
->
Module ssl already enabled
a2ensite default-ssl
->
Enabling site default-ssl.
Run '/etc/init.d/apache2 reload' to activate new configuration!
/etc/init.d/apache2 reload
->
* Reloading web server config apache2
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.33:80 has no VirtualHosts
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.33:443 has no VirtualHosts
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.37:443 has no VirtualHosts
...done.
Die 33er Adresse ist die Default Adresse, die 37er die der Kundenpräsenz, welche SSL bekommen soll.
Wenn ich nun die Kundenpräsenz via https aufrufe bekomme ich ein "It works"... Der SSL Fehler ist zwar weg, aber das Ergebnis immer noch nicht das gewünschte.
Wir haben mehrere ISPC2 und ISPC3 Server am laufen. Bisher hatten wir die Kundenpräsenzen, welche ein Zertifikat benötigen auf den ISPC2's am laufen, was bis jetzt auch keinerlei Probleme bereitet hat.
Nun haben wir eine Kundenpräsenz aufgrund eines Relaunchs von einer ISPC2 Maschine auf eine ISPC3 umgezogen. Das hat (wie auch bei allen vorherigen "Umzügen") hervorragend funktioniert, bis auf die Sache mit dem SSL.
Ich habe die DNS Einträge entsprechend umgestellt. Anfragen kommen mit der richtigen IP auf der 3er Maschine an. Im http-Betrieb funktioniert alles bestens.
Ich habe nun versucht das Zertifikat umzuziehen, leider ohne Erfolg. Mein Vorgehen war alle Einträge (sofern möglich) genau so am 3er einzutragen wie beim 2er. Dabei habe ich die Einträge für SSL-Request und SSL Zertifikat per Copy&Paste übernommen. Die anderen Zeilen konnte ich nur zum Teil übernehmen, da es beim 3er nur "Lokalität" aber keinen "Ort" gibt und zudem bei Lokalität keine deutschen Sonderzeichen erlaubt sind, auf dem 2er jedoch ein "Ort" mit nem "ö" drin angegeben ist. Schlagt mich jetzt nicht, ich weis nicht wer von unseren Helden (evtl sogar ich) auf die dumme Idee mit dem Sonderzeichen gekommen ist. Eine "Haltbarkeitsdauer" für das Zertifikat kann ich beim 3er auch nicht mehr angeben. Für SSL-Bundle konnte ich gar nix angeben.
Ich habe dann gespeichert und brav ein paar Minuten auf die Job-Queue gewartet. Leider bekomme ich beim Aufruf im Browser nur ein
ssl_error_rx_record_too_long
gemeldet. Auch ein selbstsigniertes Zertifikat anzulegen gelingt mir zwar (delete/create certificate) aber ich bekomme selbes Ergebnis.
Es ist, wie gesagt das erste mal, dass ich auf nem ISPC3 eine Seite mit Zertifikat anlege, vllt ist der Fehler auch ganz woanders zu suchen, was ich jedoch nicht recht glauben kann.
Wäre nett wenn jemand einen Hinweis für mich hätte wo ich weiter graben soll/kann/darf..
Gruß,
Thomas
Nachtrag:
Ich habe noch etwas im Netz gestöbert und hab auf der Konsole folgendes probiert:
a2enmod ssl
->
Module ssl already enabled
a2ensite default-ssl
->
Enabling site default-ssl.
Run '/etc/init.d/apache2 reload' to activate new configuration!
/etc/init.d/apache2 reload
->
* Reloading web server config apache2
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.33:80 has no VirtualHosts
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.33:443 has no VirtualHosts
[Tue Jul 31 04:11:20 2012] [warn] NameVirtualHost xxx.xxx.153.37:443 has no VirtualHosts
...done.
Die 33er Adresse ist die Default Adresse, die 37er die der Kundenpräsenz, welche SSL bekommen soll.
Wenn ich nun die Kundenpräsenz via https aufrufe bekomme ich ein "It works"... Der SSL Fehler ist zwar weg, aber das Ergebnis immer noch nicht das gewünschte.
Zuletzt bearbeitet: