[toc]
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.
