Eine Anleitung zu dieser Frage gibt es auf dem Cisco-Webserver auf der Seite Configuring the SSL Services Module. Im Kapitel Manual Certificate Enrollment ist im „Example 4: Configuring Certificate Enrollment Using Cut-and-Paste (Three-Tier Certificate Authority)“ dokumentiert, wie Schlüssel und Request im IOS erzeugt werden und wie der Import einer mehrstufigen Zertifikatkette für Serverzertifikate auf der Kommandozeile zu konfigurieren ist. Ein weiteres Beispiel finden Sie unter ASA 8.x Manually Install 3rd Party Vendor Certificates for use with WebVPN Configuration Example.

Die Schlüssellänge des erzeugten Schlüssels muss auf 2048 Bit gesetzt werden, der Zertifikatname (SubjectDN) für den Request wird an entsprechender Stelle festgelegt mit dem Befehl

subject-name C=DE,ST=<Bundesland>,L=<Stadt>,O=<Einrichtung>,CN=fqdn.domain.tld, emailAddress=mail@domain.tld

Wenn Sie beim Beantragen eines Serverzertifikats über die Webschnittstelle der DFN-PKI die Fehlermeldung erhalten, dass der RSA Schlüssel mit 2047 Bit zu kurz ist, liegt das an einem Fehler im Betriebssystem des VPN Concentrators (Cisco Case-ID CSCsi97749). Es werden u.U. RSA Schlüssel der Länge 2047 Bit erstellt, die der Policy der DFN-PKI nicht genügen.

Für dieses Problem gibt es in Abhängigkeit vom Zweck des Zertifikats zwei Workarounds:

1. SSL Zertifikat für WebVPN oder für die Administrationsoberfläche des Cisco VPN 3xxx Concentrator.

Nutzen Sie OpenSSL, um den Schlüssel und den Request außerhalb der Cisco zu erzeugen (siehe Anleitung zur Nutzung von OpenSSL). Für den Import von Schlüssel und Zertifikat sind folgende Schritte notwendig:

• Umwandeln des privaten Schlüssels in das PKCS8-Format mit
  

openssl pkcs8 -in privkey.pem -topk8 -out privkey.pk8

• Zusammenführen von Serverzertifikat und privatem Schlüssel in einer Datei mit

cat privkey.pk8 server_cert.pem > server_cert_concentrator.pem

• Manuelles Importieren in den VPN Concentrator mit

Administration | Certificate Management | Install | SSL Certificate withPrivate Key  -> Filename: server_cert_concentrator.pem

Achten Sie auf das richtige Eingeben der Passphrase! Cisco gibt eine verwirrende Fehlermeldung („Parse error“), wenn man sich bei der Passphrase vertippt.

2. Identity Zertifikat zur Nutzung von IPSec.

Hierfür gibt es leider nicht die Möglichkeit des Imports von extern erzeugten Schlüsseln. Cisco beschreibt, dass man durch das temporäre Abschalten von vorhandenen SEPs das Gerät dazu zwingen kann, private Schlüssel in Software zu erzeugen. Die Software-Schlüsselerzeugung hat den Bug nicht, so dass hier immer 2048 Bit Schlüssel generiert werden. Nach der Schlüsselerzeugung kann das SEP wieder eingeschaltet werden. Zum Vorgehen siehe Cisco-Workaround

In Apache Tomcat können neben einem Java-KeyStore auch PKCS#12-Dateien für die Installation eines Serverzertifikats genutzt werden:

Erstellen Sie eine PKCS#12-Datei mit dem privaten und öffentlichen Schlüssel, dem Serverzertifikat, sowie der CA-Kette. Lesen Sie dazu bitte die Anleitung zur Nutzung von OpenSSL. Ändern Sie die Datei „server.xml“ im Verzeichnis „conf“ von Tomcat wie folgt:

    Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
       maxThreads="150" scheme="https" secure="true"
       clientAuth="false" sslProtocol="TLS"
       keystoreFile="server.p12"
       keystoreType="PKCS12"
       keystorePass="<Passwort der PKCS#12-Datei>"

Der VMware vCenter Server benötigt für Verwaltungsaufgaben mehrere Zertifikate. Von VMware existiert hierzu eine Anleitung, für deren Umsetzung in der DFN-PKI einige Punkte zu beachten sind:

1. Nach Anleitung soll zur eindeutigen Unterscheidung der Zertifikate für die verschiendenen Funktionen der Funktionsname in das OU-Feld des DN aufgenommen werden, also OU=InventoryService, OU=SSO, OU=UpdateManager, OU=vCenter, OU=WebClient bzw. OU=LogBrowser, damit der subjectDN der Zertifikate eindeutig wird. Für Zertifikate der DFN-PKI für den Einsatz in VMware-Installationen empfehlen wir ein Schema, das durch folgendes Beispiel illustriert wird:

/C=DE/ST=Muster-Bundesland/L=Muster-Stadt/O=Universitaet Muster-Stadt/OU=Rechenzentrum/OU=Virtualisierung/OU=InventoryService/CN=vcenter.example.org

Die OU-Attribute stellen hierbei nach Policy physikalische, abstrakte oder logische organisatorische Untereinheiten der im O-Attribut benannten Einrichtung dar.

2. Nach Anleitung soll im SubjectAltName ein Eintrag DNS=ShortServerName aufgeführt werden, der einen Host-Namen ohne weiteren qualifizierenden Domain-Namen repräsentiert.

Derartige Zertifikate gibt es in der DFN-PKI (wie in allen Browser-verankerten PKIs) nur noch mit einer Gültigkeit bis Oktober 2015. Ab Oktober 2015 können solche Zertifikate in der DFN-PKI gar nicht mehr ausgestellt werden.

Nach unserer Erfahrung funktioniert der vCenter Server auch mit Zertifikaten, die im SubjectAltName keinen Eintrag DNS=ShortServerName tragen.

3. Nach Anleitung soll im SubjectAltName ein Eintrag IP=ServerIPAddress aufgeführt werden, der die IP-Adresse des Servers enthält.

Wird hier eine IP-Adresse aus den für den allgemeinen Gebrauch reservierten IP-Adressen (10.0.0.0-10.255.255.255 (10/8 Prefix), 172.16.0.0-172.31.255.255 (172.16/12 Prefix) und 192.168.0.0-192.168.255.255 (192.168/16 Prefix) sowie den entsprechenden IPv6-Adressräumen) gewählt, so kann das Zertifikat von der DFN-PKI (wie bei allen Browser-verankerten PKIs) nur noch mit einer Gültigkeit bis Oktober 2015 ausgestellt werden. Ab Oktober 2015 können solche Zertifikate in der DFN-PKI gar nicht mehr ausgestellt werden.

4. Nach Anleitung sollen die keyUsages „digitalSignature“ und „keyEncipherment “ sowie die extendedKeyUsages „clientAuth“ und „serverAuth“ in das Zertifikat aufgenommen werden. Entgegen der Anleitung ist die keyUsage „nonRepudiation“ nach unserer Erfahrung nicht nötig. Das Zertifikatprofil „VoIP Server“ stellt diese Zertifikatsverwendungszwecke entsprechend zur Verfügung.