ISPConfig3 Designfehler? Apache SSL Multiserverumgebung

Brainfood

Member
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:

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 :mad:

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:

Till

Administrator
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?

Das sollte so sicherlich nicht sein. Hast Du es denn im Bugtracker gepostet?


Damit habe ich mir schon 3 Requests versemmelt und musste sie gegen Bezahlung revoken

OT: Bei was für einer SSL authority bist Du denn? Alle mir bekannten SSL authorities machen ein rekeying kostenlos.
 

Brainfood

Member
Bugreport ist draußen ...

StartSSL.com ...

Der Revoke war nötig, da ich nicht die Schlüssel direkt dort erstellt habe, sondern nur das fertige CSR unterzeichnen wollte ...

von derzeit 15 CSRs ... musste ich 3 revoken lassen ... da das ISPConfig Interface in dem Augenblick wohl den Inhalt vom Web2 darstellte, der automatisierte rsync von Web1 (mit ungültigen keys) anschließend jedoch die Web2 gültigen keys überschrieb und somit das ganze fertig importierte Cert. unbrauchbar wurde ...

PS: Die Kisten hängen im IPv4 sowie IPv6 Netzt, die /etc/hosts definiert aber klar nur die zuständigen Server mit IPv4-Adressen ... Das Problem muss irgendwo beim "auslesen" der Cert.Infos, von fremden Kisten, liegen (wenn ISPConfig CP und Web nicht auf der selben Maschine betrieben werden) ...
 
Zuletzt bearbeitet:

Werbung

Top