Wie viele andere wissenschaftliche Einrichtungen nutzen wir in der Foschungsgruppe Kooperationssysteme die Möglichkeit, unsere SSL-Serverzertifikate durch die Zertifizierungsstelle (CA) des Deutschen Forschungsnetzes (DFN) zertifizieren zu lassen. Die Zertifizierung findet durch die lokale Zwischenzertifizierungsstelle innerhalb der DFN Public Key Infrastruktur (PKI), unsere Universität der Bundeswehr München (UniBwM), statt . Großer Vorteil ist, dass die CA des DFN-Vereins („DFN-Verein PCA Global – G01″) als Root-Zertifikat das in gängigen Browsern enthaltene „Deutsche Telekom Root CA 2″ des T-TeleSec Trust Center der Deutschen Telekom AG für seine Zertifizierung verwendet. Somit wird der Zertifizierungspfad der ausgestellten Zertifikate ohne Zusatzinstallation eines Root-Zertifikats validiert.

Beantragen eines Serverzertifikats

Zur Zertifizierung lässt man sich unter ausführlicher Prüfung der persönlichen Daten und der Zugehörigkeit zur jeweils ausstellenden Einrichtung sowie der Sicherheit des zu zertifizierdenden Systems für einen ausgewählten Hostnamen ein Apache-taugliches PEM-Zertifikat generieren. Dabei handelt es sich um ein Base64-kodiertes X.509 Zertifikat im Format:

-----BEGIN CERTIFICATE-----

Zertifkatinhalt

-----END CERTIFICATE-----

Einbinden in die Apache-Konfiguration

Dieses Zertifikat kann anschließend in die Webserver-Konfiguration integriert werden. Bisher haben wir hierzu das Zertifikat sowie den von Apache benötigten privaten Schlüssel (Private Key) auf folgende einfache und der Standard-Dokumentation entsprechende Art in die Konfiguration des jeweiligen vHosts unter /etc/apache2/sites-enabled eingebunden:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/ZERTIFIKATSNAME.pem
SSLCertificateKeyFile /etc/ssl/private/PRIVATE_KEY.key

Hierzu ist natürlich das Apache2 SSL-Modul erforderlich, das sich bei Bedarf über

a2enmod ssl

aktivieren lässt.

Anschließend muss Apache neu gestartet werden:

/etc/init.d/apache2 restart

Probleme bei der bisherigen Nutzung

In gängigen Browsern, wie Firefox, Internet Explorer, Chrome oder Safari hatten wir damit nie Probleme und das Zertifikat wurde immer als gültig angezeigt. Dies ist darauf zurückzuführen, dass diese Browser beim Validieren des Zertifikats im lokalen Cache nach den verschiedenen in der Zertifikatskette enthaltenen Authority-Zertifikaten suchen und sie – sofern vorhanden – für die Validierung verwenden. Allerdings gelten in größeren Unternehmen oder bestimmten öffentlichen Einrichtungen häufig erhöhte Sicherheitsrichtlinien. Dort werden häufig Web-Proxies eingesetzt, die bei der Validierung des Zertifizierungspfades nicht auf einen lokalen Zertifikats-Cache zurückgreifen können (oder sollen), sondern für die alle Informationen direkt über den Webserver erreichbar sein müssen. In unserem Fall hat dies auf einigen Verwaltungsrechnern dazu geführt, dass bestimmte SSL-verschlüsselte Login-Seiten über den genutzten Web-Proxy nicht erreichbar waren, da die Verbindung als nicht sicher angezeigt wurde.

Zertifikat-Validierung mit openSSL

Grundsätzlich lassen sich ausgestellte Zertifikate mit dem Linux-Programm openSSL relativ einfach validieren. Hierzu verwendet man einfach den s_client mit der entsprechenden Adresse des Apache vHosts:

openssl s_client -connect vhost-adresse.de:443

Resultat sollte bei gültigen Zertifikaten ein

Verify return code: 0 (ok)

sein. In unserem Fall bekamen wir allerdings trotz der Gültigkeitsanzeige in Brwosern von openSSL ein

Verify return code: 21 (unable to verify the first certificate)

weshalb das Zertifikat auch vom Web-Proxy abgelehnt wurde.

Korrektur durch Einfügen eines SLCACertificateFile

Beseitigen ließ sich das Problem schließlich durch Nutzung eines SLCACertificateFile in der Apache-Konfiguration. Nachdem der Weg dorthin allerdings etwas steinig war, hier ein paar kurze Erläuterungen.

Zunächst muss das „Chain-File“ der jeweils genutzten DFN-Zwischenzertifizierungsstelle heruntergeladen werden, das die CA-Zertifikate aller Zwischenzertifizierungsstellen sowie der Root-CA in einem File enthält. Die jeweilige Datei ist auf den öffentlich zugänglichen Servern des DFN-Vereins verfügbar. In unserem Fall beispielsweise unter dem Link https://pki.pca.dfn.de/uni-bundeswehr-muenchen-ca/pub/cacert/chain.txt.

Diese Datei muss mit der Endung PEM (streng genommen spielt die Endung in Linux keine Rolle) in den Zertifikatsordner auf den Server (in Debian- und Ubuntu-basierten Distributionen i.d.R. /etc/ssl/certs) geladen und in der vHost-Konfiguration mittels SSLCertificateChainFile entsprechend ergänzt werden. Außerdem war es in unserem Fall erforderlich, Apache den Pfad, in dem die CA-Zertifikate zu finden sind, ebenfalls mitzuteilen:

SSLCertificateChainFile /etc/ssl/certs/CHAIN-FILE.pem
SSLCACertificatePath /etc/ssl/certs

Anschließend muss Apache wieder neu gestartet werden:

/etc/init.d/apache2 restart

Erneute Validierung

Interessant ist das Ergebnis der erneuten Validierung, denn hier liefert openSSL im Falle eines DFN-Zertifikats:

Verify return code: 19 (self signed certificate in certificate chain)

oder in anderen Worten, dass ein selbst-signiertes Zertifikat im Zertifizierungspfad gefunden wurde. Dies ist darauf zurückzuführen, dass das openssl nichts vom oben bereits erwähnten Root-CA-Zertifikat („Deutsche Telekom Root CA 2″) weiß. Durch Anhängen des CAfile-Parameters lässt sich das Zertifikat allerdings doch noch validieren:

openssl s_client -connect vhost-adresse.de:443 -CAfile /etc/ssl/certs/deutsche-telekom-root-ca2.pem

Das Resultat ist nun wie gewünscht ein

Verify return code: 0 (ok)

Auch von Clients, die den Web-Proxy nutzen, ließ sich die Seite damit problemlos validieren.