Results for tag "zertifikat"

2 Articles

Server Name Indication (SNI) unter Apache 2.0.63 (Windows)

Heute kam bei uns in der Firma wieder das Thema Zertifikate zu sprechen. Unsere momentane Umgebung auf dem auch dieser Blog gehostet ist, ist ein Windows-System, auf dem Apache 2.0.63 läuft. Einige der Subdomains sind über SSL zugänglich, allerdings besteht bei SSL das generelle Problem, dass pro IP-Adresse nur ein SSL-Zertifikat benutzt werden darf. Wenn man mehrere Subdomains als virtuelle Hosts betreibt (https://v1.ecw.de, https://v2.ecw.de u.s.w.) wird immer nur das Zertifikat des ersten VHosts benutzt (im Beispiel das Zertifikat von https://v1.ecw.de).

Seit einiger Zeit bietet das Unternehmen StartCom kostenlose Zertifikate an. Das CA-Zertifikat von StartCom ist in den aktuellen Browsern sowie im Zertifikate-Speicher von Windows verfügbar. Leider besteht nicht die Möglichkeit, ein kostenloses Wildcard-Zertifikat zu erhalten. StartCom teilt nur Zertifikate vom Typ C1 und nicht C2 kostenlos aus.

Mit dem Wildcard-Zertifikat wäre es möglich gewesen, dass alle VHosts unter https://*ecw.de sich ein Zertifikat teilen. Die andere Möglichkeit, für jede Domain ein eigenes Zertifikat einzurichten, entfällt aus den bereits genannten Gründen: pro IP nur ein Zertifikat.

Seit 2003 existiert die RFC 3456, in der Server Name Indication (SNI) definiert wird. Damit ist es möglich, pro IP-Adresse mehrere Zertifikate zu benutzen. Leider implementieren bis jetzt nur wenige Webserver SNI nativ.

Als ich im Internet nach dem Thema googelte, wurde ich in Wolfs Blog fündig. Er beschrieb die Implementierung und Kompilierung von SNI unter Apache 2.2.xx. Durch seine Ausführungen war ich mehr als motiviert und hatte nun den Plan, SNI unter Apache 2.0.63 und Windows zum Laufen zu bringen.

Durch meine letzten Tätigkeiten beim mod_auth_ldap-Patch hatte ich noch die Sourcen von Apache 2.0.63 auf der Festplatte und sammelte nun die benötigten Dateien zusammen:

Nachdem ich die beiden Backport-Patches in meine Sourcen eingespielt hatte, musste ich noch die Lib-Pfade für die OpenSSL-Dateien einpassen und außerdem das zlib-Verzeichnis inkludieren, da OpenSSL irgendwie auf zlib referenzierte.

Die Kompilierung verlief danach ohne Probleme und ich machte mich an das Deployen der Dateien. Wichtig dabei war, das auf dem Server folgende neue Dateien kamen:

  • openssl.exe aus Wolfs-SSL-Package nach Apache2/bin
  • libeay32.dll und ssleay32.dll aus Wolfs-SSL-Package nach Apache2/bin bzw. %SYSTEM32%
  • Release/libhttpd.dll aus dem Apache-Kompiliat nach Apache2/bin
  • modules/ssl/Release/mod_ssl.so nach Apache2/modules

Das Starten des Apaches schlug beim ersten Mal fehl, da ich die libhttpd.dll vergessen hatte zu kopieren. Diese wird aber benötigt, da der Backport von ap_vhost_iterate_given_conn auf diese Library abzielt.
Danach fuhr der Apache normal hoch, ich richtete nun in aller Kürze zwei Virtuelle Hosts in meiner httpd.conf ein und erzeugte zwei Self Signed Certificates. Das Ergebnis war mehr als erfreulich, denn soweit funktionierte alles.
Der nächste Schritt wird für mich sein, dass ich nun unsere Zertifikate von der StartCom-CA signieren lasse.

[download id=”2″]

CruiseControl / SVNBootstrapper: Server certificate verification failed: issuer not trusted

Heute habe ich endlich die Zeit gefunden, mich um unseren Buildserver zu kümmern.
Meine erste Aufgabe bestand darin, dass ich die kompletten Konfigurationsdateien so abstrahiert habe, dass die eine Projekt-Konfiguration letztendlich nur noch aus 10 Zeilen XML-Code besteht, in denen u.a. der Pfad zum SVN-Repository angegeben ist.
Dies funktionierte auch alles wunderbar, bis der SVNBootstrapper zum ersten Mal die Verbindung mit dem Repository aufnahm.

Im Log bekam ich folgenden Fehler zu sehen:

2009-09-28 14:15:20,739 [Thread-28] WARN  SVNBootstrapper  – svn: OPTIONS von ¯https://$host/svn/$project/trunk®: Server certificate verification failed: issuer is not trusted (https://$host)
2009-09-28 14:15:21,051 [Thread-27] INFO  Project          – Project $projectidle
2009-09-28 14:15:21,051 [Thread-27] INFO  ProjectController – $project Controller: build progress event: idle
2009-09-28 14:15:21,051 [Thread-27] ERROR Project          – exception attempting build in project $project
net.sourceforge.cruisecontrol.CruiseControlException: svn process exited with error code 1

Nach kurzer Recherche wurde ich fündig: Das Benutzerkonto, unter dem CruiseControl läuft, muss das Client-Zertifikat installieren. Dazu gibt es entweder die Möglichkeit, im Subversion-Konfigurationsverzeichnis die SSL-Settings anzupassen oder aber – einfacher – das Zertifikat im Zertifikate-Speicher zu installieren.
Wichtig ist dabei, dass CruiseControl unter einem lokalen Benutzer-Account als Dienst läuft und nicht als NetworkService oder Local System.
Unter dem Benutzer-Account unter dem CC läuft, muss man sich nun anmelden, Internet Explorer starten, auf die URL des WebDAV-Ordners gehen, das Zertifikat installieren und schließlich den CC-Dienst neu starten. Nun funktioniert alles wunderbar und das Projekt Build-Server geht langsam aber sicher dem Ende entgegen