Dies ist eine alte Version des Dokuments!
Wenn Ihr PC eine verschlüsselte Verbindung über SSL bzw. TLS zu einem Server der Hochschule herstellt, überprüft Ihr PC, ob die Verbindung wirklich zum korrekten Server hergestellt wurde. Sie wollen schließlich nicht Ihre Zugangsdaten zu FHS-Diensten an irgendjemanden aushändigen, der sich lediglich als FHS ausgibt.
Für diese Überprüfung stellt jeder Server-Dienst ein Dienst-Zertifikat bereit. Dieses enthält den öffentlichen Schlüssel (public key) des Dienstes und ist von einer Zertifizierungsstelle (certification authority, CA) unterschrieben (signiert).
Damit die Unterschrift des CA unter dem Public Key überprüft werden kann, muss der öffentliche Schlüssel des CA auf Ihrem PC als vertrauenswürdige Stammzertifizierungsstelle (trusted CA) konfiguriert sein.
Nach der Installation aktueller Windows- und Linux-Installationen sind bereits einige vertrauenswürdige Stammzertifizierungsstellen vorkonfiguriert, hauptsächlich die für Updates benötigten.
Die Menge der vorkonfigurierten CAs unterscheidet sich, abhängig von der Windows-Version bzw. Linux-Distribution. Daher sind ggf. Anpassungen erforderlich.
Aus Kosten- und Aufwandsgründen verwenden einige Dienste der FHS selbst-signierte Zertifikate. Daher ist es sinnvoll, die CA-Zertifikate der FHS und die zugehörige CA-Kette zu importieren.
Hier finden Sie Zertifikate „Zertifikat der Deutschen Telekom Root CA 2“, „Zertifikat der DFN-PKI DFN-Verein PCA Global G01“ und Zertifikat der Fachhochschule Schmalkalden CA 1„.
Laden Sie alle drei Zertifikate herunter und speichern Sie sie im Verzeichnis C:\Temp (Windows) bzw. /tmp (Linux,Unix).
Zusätzlich wird das CA-Zertifikat für hochschulinterne Dienste benötigt. Speichern Sie auch iukca3.crt in C:\Temp bzw. /tmp ab.
Unter Windows können Zertifikate benutzerabhängig oder systemweit abgespeichert werden. Sinnvoll ist für die CA-Zertifikate die systemweite Speicherung, da der Vorgang sonst für jeden Benutzer durchgeführt werden muss.
Unter Cygwin stehen die Zertifikate nicht wie sonst unter Linux üblich im Verzeichnis /etc/openldap/cacerts bzw. /etc/pki/tls/certs sondern in /usr/ssl/certs. Starten Sie eine Cygwin Bash Shell als Administrator und verwenden Sie die nachfolgenden Kommandos. Die Zieldateinamen in den ln-Befehlen und im chmod-Befehl müssen ggf an die Hash-Werte angepasst werden, die von den openssl-Kommandos ausgegeben wurden:
cd /usr/ssl/certs cp /cygdrive/c/temp/telekom.crt telekom.crt cp /cygdrive/c/temp/dfn.crt dfn.crt cp /cygdrive/c/temp/cacert.crt fhs-ca.crt cp /cygdrive/c/temp/iukca3.crt iuk3ca.crt openssl x509 -subject_hash -noout -in telekom.crt openssl x509 -subject_hash -noout -in dfn.crt openssl x509 -subject_hash -noout -in fhs-ca.crt openssl x509 -subject_hash -noout -in iukca3.crt ln -s telekom.crt 812e17de.0 ln -s dfn.crt 6107e209.0 ln -s fhs-ca.crt 74f0e817.0 ln -s iukca3.crt 7a869ab8.0 chmod 644 812e17de.0 6107e209.0 74f0e817.0 7a869ab8.0
Achten Sie darauf, dass im Zieldateinamen der „ln -s“-Anweisung der Hexadezimalwert vor “.0„ der Wert ist, der von der „openssl x509“-Anweisung als Hashwert ausgegeben wurde. Mit älteren Versionen des Programmes OpenSSL erhalten Sie evtl. andere Hash-Werte.
Hier sind die aktuellen Werte vom 01.08.2012 angegeben. Die Werte können sich ändern, wenn die Zertifikate einmal erneuert werden.
Unter Linux (hier getestet mit Scientific Linux 6.1, sollte mit CentOS und Fedora Core gleichermaßen funktionieren) kopieren Sie zunächst die Zertifikate nach /etc/openldap/cacerts (für die Nutzung von LDAP über SSL) und nach /etc/pki/tls/certs (für andere Zwecke). Anschließend werden symbolische Links angelegt, damit die CA-Zertifikate passend zum Subject-Hash gefunden werden können.
cd /etc/openldap/cacerts cp /tmp/telekom.crt telekom.crt cp /tmp/dfn.crt dfn.crt cp /tmp/cacert.crt fhs-ca.crt cp /tmp/iukca3.crt iuk3ca.crt openssl x509 -subject_hash -noout -in telekom.crt openssl x509 -subject_hash -noout -in dfn.crt openssl x509 -subject_hash -noout -in fhs-ca.crt openssl x509 -subject_hash -noout -in iukca3.crt ln -s telekom.crt 812e17de.0 ln -s dfn.crt 6107e209.0 ln -s fhs-ca.crt 74f0e817.0 ln -s iukca3.crt 7a869ab8.0 chmod 644 812e17de.0 6107e209.0 74f0e817.0 7a869ab8.0 cd /etc/pki/tls/certs cp /tmp/telekom.crt telekom.crt cp /tmp/dfn.crt dfn.crt cp /tmp/cacert.crt fhs-ca.crt cp /tmp/iukca3.crt iuk3ca.crt ln -s telekom.crt 812e17de.0 ln -s dfn.crt 6107e209.0 ln -s fhs-ca.crt 74f0e817.0 ln -s iukca3.crt 7a869ab8.0 chmod 644 812e17de.0 6107e209.0 74f0e817.0 7a869ab8.0
Achten Sie darauf, dass im Zieldateinamen der „ln -s“-Anweisung der Hexadezimalwert vor “.0„ der Wert ist, der von der „openssl x509“-Anweisung als Hashwert ausgegeben wurde. Mit älteren Versionen des Programmes OpenSSL erhalten Sie evtl. andere Hash-Werte.
Hier sind die aktuellen Werte vom 01.08.2012 angegeben, ermittelt unter Scientific Linux 6.1. Die Werte können sich ändern, wenn die Zertifikate einmal erneuert werden.
Java verwendet nicht den systemweiten Zertifikatsspeicher, sondern einen eigenen Keystore. Sollen Java-Programme SSL-Verbindungen aufbauen (z.B. LDAP-Browser, die ldaps verwenden), müssen die benötigten CA-Zertifikate auch in diesem Keystore enthalten sein.
Der Keystore befindet sich in einer Datei cacerts innerhalb der Java-Directory-Struktur. Wurde z.B. Java JRE 1.7.0.51 nach /usr/local/jre1.7.0_51 installiert, ist das Java-Binary die Datei /usr/local/jre1.7.0_51/bin/java und der Keystore die Datei /usr/local/jre1.7.0_51/lib/security/cacerts.
Wird OpenJDK verwendet, ist das Java-Binary /usr/bin/java, der Keystore /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/jre/lib/security/cacerts ist ein symbolischer Link zu /etc/pki/java/cacerts.
In den nachfolgenden keytool-Befehlen muss der Name der Keystore-Datei angepasst werden.
Mit
keytool -list -keystore /usr/local/jre1.7.0_51/lib/security/cacerts
werden die Zertifikate im Java-Keystore angezeigt. Für jedes Zertifikat wird u.a. ein Kurzname (Alias) angezeigt sowie ein Fingerprint.
Wichtig: Verwenden Sie das keytool-Programm der jeweiligen Java-Version!
Mit
openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/telekom.crt openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/dfn.crt openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/fhs-ca.crt openssl x509 -noout -fingerprint -in /etc/pki/tls/certs/iukca3.crt
werden die Fingerprints der an der FHS benötigten Zertifikate angezeigt.
Ein Abgleich mit der Ausgabe des keytool-Befehles oben zeigt, welche Zertifikate bereits im Keystore enthalten sind und welche noch importiert werden müssen. Für JRE 1.7.0.51 ist das Telekom-Zertifikat bereits enthalten, die restlichen drei müssen noch importiert werden.
Mit
cp /usr/local/jre1.7.0_51/lib/security/cacerts /usr/local/jre1.7.0_51/lib/security/cacerts.backup keytool -import -trustcacerts -alias dfnpkica -file /etc/pki/tls/certs/dfn.crt -keystore /usr/local/jre1.7.0_51/lib/security/cacerts keytool -import -trustcacerts -alias fhsca -file /etc/pki/tls/certs/fhs-ca.crt -keystore /usr/local/jre1.7.0_51/lib/security/cacerts keytool -import -trustcacerts -alias iukca3 -file /etc/pki/tls/certs/iukca3.crt -keystore /usr/local/jre1.7.0_51/lib/security/cacerts
werden die Zertifikate in den Java-Keystore importiert (JRE 1.7.0.51).
Während des Importes wird nach einem Passwort für den Keystore gefragt. Standardmäßig ist dies „changeit“.
Das Zertifikat iukca3.crt ist selbst-signiert, keytool kann daher die Vertrauenskette nicht prüfen. Daher erscheint ein Prompt mit der Abfrage, ob der Import wirklich erfolgen soll. Hier mit „ja“ bestätigen.
Auf Windows-Systemen können Zertifikate in verschiedene Stores (Zertifikate-Kategorien) importiert werden:
Name (deutsch) | Name (englisch) | Name (Kommandozeile) | Verwendung |
---|---|---|---|
Eigene Zertifikate | Personal | MY | Zertifikate des Benutzers, Computers oder Dienstes, der Eigentümer besitzt sowohl den öffentlichen und auch den privaten Schlüssel |
Vertrauenswürdige Stammzertifizierungsstellen | Trusted Root Certification Authorities | ROOT | Vertrauenswürdige CAs, die nach der Windows-Installation vorinstalliert sind. Zusätzlich dazu werden noch Zertifikate aus „Organisationsvertrauen“ und „Drittanbieter-Stammzertifizierungsstellen“ hier eingeblendet. |
Organisationsvertrauen | Enterprise Trust | CA | Selbstsignierte CA-Zertifikate der eigenen Organisation. Die hier importierten CA-Zertifikate werden unter den „Vertrauenswürdigen Stammzertifizierungsstellen“ mit eingeblendet. |
Zwischenzertifizierungsstellen | Intermediate Certification Authorities | Sub-Authentifizierungsstellen | |
Active-Directory-Benutzerobjekt | Active Directory User Object | UserDS | |
Vertrauenswürdige Herausgeber | Trusted Publishers | TrustedPublisher | Softwarehersteller, die ihre Software signieren |
Nicht vertrauenswürdige Zertifikate | Untrusted Certificates | Disallowed | Zertifikate, denen nicht vertraut wird |
Drittanbieter-Stammzertifizierungsstellen | Third-Party Root Certification Authorities | Root-CAs, die weder zu MS, noch zur eigenen Organisation gehören und auch nicht als vertrauenswürdige Zertifikate vorinstalliert sind. Die hier importierten Zertifikate werden unter „Vertrauenswürdige Stammzertifizierungsstellen“ mit eingeblendet. | |
Vertrauenswürdige Personen | Trusted People | TrustedPeople | Selbst-signierte Zertifikate von Einzel-Personen |
Andere Personen | Other People | Zertifikate von Personen, die nicht als vertrauenswürdig angesehen werden | |
Zertifikatsregistrierungsanforderungen | Certificate Enrollment Requests | REQUEST | Zertifikatsanforderungen, Antwort steht noch aus |