Hallo Team,
folgendes Szenario:
- Conf1-Server: ISPConfig3 zur Verwaltung der Server
- Web1-Server: Haupt-Webserver
- Web2-Server: Backup-Weberver (automatisches rsync)
- ... diverse andere Server
Hinweis: Web2 ist als Mirror eingerichtet
Ich gehe unter Webseiten -> Domains -> wähle mir die gewünschte Domain aus und klicke mir ein SSL Zertifikat "create" (self signed certificate)
ISPConfig3 erzeugt anschließend per random generator auf beiden Maschinen unterschiedliche keys.
Schau ich mir erneut das Zertifikat an, lässt sich überhaupt nicht feststellen ob SSL Request/SSL Zertifikat von Web1 oder Web2 eingeblendet wird.
Ich nehme also den SSL Request, gehe zu meiner CA und lass dad Ding unterschreiben. Anschließend füge ich es per ISPConfig Webinterface wieder ein "Save".
Per Mail bekomme ich nun: "Webserver1 down"
Schau ich mir die error.log im /var/www/domain.tld/log auf Web1 an, steht:
OK, alles klar, Web1 ist down, Web2 hingegen geht ... also fix die Keys von Web2 auf Web1 per ssh kopiert ...
Es scheint so: .. Wenn ISPConfig3 - 3.0.4 nur als Config-Server läuft, er willkürlich von den managed Webservern die SSL Zertifikate im Interface einblendet, obwohl Web2 ganz klar im Slave/Mirror Client Modus läuft ...
Damit habe ich mir schon 3 Requests versemmelt und musste sie gegen Bezahlung revoken
Die Generierung der unterschiedlichen random keys auf den Webservern lassen sich nicht vermeiden, nur sollte ISPConfig3 ganz klar immer nur den primären Webserver nehmen/darstellen, ist in 3.0.5 Besserung in Sicht?
Ein Kunde könnte so ohne weiteres mit einer fehlerhaften SSL Cert. Config die Kiste lahmlegen ...
folgendes Szenario:
- Conf1-Server: ISPConfig3 zur Verwaltung der Server
- Web1-Server: Haupt-Webserver
- Web2-Server: Backup-Weberver (automatisches rsync)
- ... diverse andere Server
Hinweis: Web2 ist als Mirror eingerichtet
Ich gehe unter Webseiten -> Domains -> wähle mir die gewünschte Domain aus und klicke mir ein SSL Zertifikat "create" (self signed certificate)
ISPConfig3 erzeugt anschließend per random generator auf beiden Maschinen unterschiedliche keys.
Schau ich mir erneut das Zertifikat an, lässt sich überhaupt nicht feststellen ob SSL Request/SSL Zertifikat von Web1 oder Web2 eingeblendet wird.
Ich nehme also den SSL Request, gehe zu meiner CA und lass dad Ding unterschreiben. Anschließend füge ich es per ISPConfig Webinterface wieder ein "Save".
Per Mail bekomme ich nun: "Webserver1 down"
Schau ich mir die error.log im /var/www/domain.tld/log auf Web1 an, steht:
Code:
[Tue Oct 16 01:56:04 2012] [error] Unable to configure RSA server private key
[Tue Oct 16 01:56:04 2012] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
[Tue Oct 16 01:56:08 2012] [warn] RSA server certificate CommonName (CN) `www.domain.tld' does NOT match server name!?
[Tue Oct 16 01:56:08 2012] [error] Unable to configure RSA server private key
[Tue Oct 16 01:56:08 2012] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
[Tue Oct 16 02:03:31 2012] [warn] RSA server certificate CommonName (CN) `www.domain.tld' does NOT match server name!?OK, alles klar, Web1 ist down, Web2 hingegen geht ... also fix die Keys von Web2 auf Web1 per ssh kopiert ...
Es scheint so: .. Wenn ISPConfig3 - 3.0.4 nur als Config-Server läuft, er willkürlich von den managed Webservern die SSL Zertifikate im Interface einblendet, obwohl Web2 ganz klar im Slave/Mirror Client Modus läuft ...
Damit habe ich mir schon 3 Requests versemmelt und musste sie gegen Bezahlung revoken
Die Generierung der unterschiedlichen random keys auf den Webservern lassen sich nicht vermeiden, nur sollte ISPConfig3 ganz klar immer nur den primären Webserver nehmen/darstellen, ist in 3.0.5 Besserung in Sicht?
Ein Kunde könnte so ohne weiteres mit einer fehlerhaften SSL Cert. Config die Kiste lahmlegen ...
Zuletzt bearbeitet: