9Zertifikate erstellen und verwalten

Es wird davon ausgegangen, dass der Leser über umfassende Kenntnisse über Zertifikate und Zertifikatserstellung sowie Verschlüsselung öffentlicher Schlüssel verfügt.

In diesem Kapitel wird die Erstellung von Zertifikaten mit OpenSSL beschrieben.

Wichtiger Hinweis: mdm erfordert zwei verschiedene Arten von Zertifikaten und Schlüsseln:

–Zertifikate und Schlüssel zur Sicherung der Kommunikation zwischen mdm Kompo­nenten

–Zertifikate und Schlüssel für die PKI

Die Erstellung von Zertifikaten und Schlüsseln für die SSL-Kommunikation wird in Kapitel 9.1 beschrieben. Die in einer PKI verwendeten Zertifikate und Schlüssel werden in Kapitel 9.2 beschrieben.

Schlüsselspeicher

Zertifikate und Schlüssel werden in speziellen Datenbanken gespeichert, den sogenannten Schlüsselspeichern. Ein Schlüsselspeicher ist eine Datei, die kodierte Zertifikate und Schlüssel enthält. Für den Zugriff auf die Informationen in einem Schlüsselspeicher ist ein Passphrase erforderlich. Schlüsselspeicher können verschiedene Formate aufweisen, üb­lich sind beispielsweise PKCS#12 oder das proprietäre Format Java KeyStore (JKS). Der Kodierungsalgorithmus kann normalerweise beim Anlegen des Schlüsselspeichers ausge­wählt werden. Empfohlen wird AES256.

Die OpenSSL-Konfigurationsdatei

OpenSSL verwendet Standardwerte, die in der Konfigurationsdatei openssl.cnf angegeben sind (in welchem Verzeichnis sich diese Datei befindet, hängt von Ihrer Verteilung ab, prü­fen Sie beispielsweise das Verzeichnis /usr/ssl oder /usr/lib/ssl).

Wenn Sie obligatorische Argumente eines Befehls auslassen, verwendet OpenSSL die in der Konfigurationsdatei definierten Standardeinstellungen. Nach Möglichkeit sind alle obli­gatorischen Argumente in den nachfolgenden Beispielbefehlen explizit angegeben, wenn Sie beispielsweise die Befehle wie nachfolgend beschrieben verwenden, werden die wich­tigen Informationen der Kommandozeile und nicht der Konfigurationsdatei entnommen. Wenn die Konfigurationsdatei für den jeweiligen Befehl benötigt wird, ist dies im Text aus­drücklich angeführt.

Weitere Informationen über Syntax und Inhalt der Konfigurationsdateien finden Sie in der Dokumentation von OpenSSL, vor allem im Handbuch auf den Seiten genrsa(1ssl), req(1ssl), ca(1ssl) und openssl(1ssl).

9.1Zertifikate und Schlüssel für SSL

Für die Einrichtung einer sicheren Verbindung zwischen Entitäten (z. B. ET1, ET2) werden normalerweise folgende Komponenten benötigt:

–ein privater Schlüssel für jede an der Kommunikation beteiligte Entität:

–ET1_key

–ET2_key

Der Begriff privater Schlüssel weist bereits darauf hin, dass diese Schlüssel vertraulich behandelt und an einem Ort abgelegt werden sollten, auf den nur der Administrator zu­greifen kann.

–und die entsprechenden Zertifikate:

–ET1_cert

–ET2_cert

Die Zertifikate enthalten unter anderem folgende Informationen

–den öffentlichen Schlüssel der Entität

–Informationen über die Entität, beispielsweise Name und/oder IP-Adresse

–weitere Informationen zum Zertifikat, z. B. beabsichtigte Verwendung

Das Zertifikat ist digital entweder mit dem privaten Schlüssel der jeweiligen Entität (selbstsigniert) oder mit einem CA-Schlüssel signiert.

Die Zertifikate sind öffentlich und können durch jeden Teilnehmer an der Kommunika­tion verteilt werden.

ET1 verwendet den in ET2_cert enthaltenen öffentlichen Schlüssel, um die an ET2 übermit­telten Daten zu verschlüsseln. Damit ist gewährleistet, dass nur ET2 die Daten entschlüs­seln kann. Wenn ET2_cert selbstsigniert ist, dann ist gewährleistet, dass der in ET2_cert ent­haltene öffentliche Schlüssel ET2_key entspricht. Wird ET2_cert durch eine CA signiert, dann ist gewährleistet, dass der in ET2_cert enthaltene öffentliche Schlüssel tatsächlich zu ET2 ge­hört (Authentifizierung).

Privaten Schlüssel erstellen

Zuerst ist mit dem folgendem Befehl ET_key zu erstellen:

openssl genrsa -aes256 -passout pass:yourSSLPW -out privkey.pem 2048

Erläuterung der Argumente

:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–privkey.pem

Diese Datei enthält den ET_key im PEM-Format. Der Schlüssel wird mit dem AES256-Algorithmus kodiert. Für den Zugriff auf den Schlüssel müssen Sie die oben angege­bene Passphrase kennen (im Beispiel: yourSSLPW). Verwenden Sie zum Kodieren des privaten Schlüssels ein eigenes sicheres Passwort.

Zertifikat erstellen

Das Zertifikat wird mit folgendem Befehl erstellt:

openssl req -batch -new -x509 -key privkey.pem -keyform PEM
-passin pass:yourSSLPW -sha256 -outform PEM -out serverCert.pem

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–serverCert.pem
Diese Datei enthält das selbstsignierte Zertifikat ET_cert.

Schlüsselspeicher anlegen

Die Schlüssel und Zertifikate müssen in den Schlüsselspeichern enthalten sein. Das Instal­lationsarchiv mdm-ca-1.11.x.zip enthält das (proprietäre) Java-Tool ImportKey im Ver­zeichnis demoCA, das für das Anlegen und Verwalten von Schlüsselspeichern verwendet werden kann. Kopieren Sie die Datei ImportKey.class in Ihr Arbeitsverzeichnis.

Zuerst muss ET_key in das Format PKCS#8 umgewandelt und sowohl ET_key als auch ET_cert in den Schlüsselspeicher übernommen werden. In diesem Beispiel wird das Java KeyStore Format JKS verwendet. Dies kann mit dem Tool ImportKey abgeschlossen werden. Import­Key akzeptiert nur den (nicht kodierten) Schlüssel am Standardeingang, daher kann die Ausgabe des Befehls pkcs8 wie folgt weitergereicht werden:

openssl pkcs8 -topk8 -in privkey.pem -passin pass:yourSSLPW 
-inform PEM -nocrypt -outform DER |java -cp . ImportKey 
-alias yourAlias -storetype JKS -keystore serverKeystore.jks 
-storepass pass:yourSSLPW -keypass pass:yourSSLPW 
-chain serverCert.pem

Erläuterung der openssl-Argumente:

Erläuterung der ImportKey-Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–serverKeyStore.jks

Dies ist der Schlüsselspeicher, der das Zertifikat und den privaten Schlüssel enthält.

Zertifikat importieren

Nach Anlegen des Schlüsselspeichers müssen zuweilen zusätzliche Zertifikate in den Schlüsselspeicher importiert werden. Dies kann mit dem folgenden Befehl erfolgen:

java -cp . ImportKey -alias yourAlias -storetype JKS
-file additionalCertificate.pem -storepass pass:yourSSLPW
-keystore serverKeystore.jks

Erläuterung der ImportKey-Argumente:

9.2Zertifikate und Schlüssel für eine PKI

Beim Ausrollen einer Private Key Infrastructure (PKI), das generell bei Verwendung des mdm CA beabsichtigt ist, sind zusätzlich zu den im vorherigen Abschnitt erwähnten Punk­ten weitere Voraussetzungen zu berücksichtigen. In diesem Kapitel werden zunächst die Grundlagen der PKI und anschließend die Verwendung von OpenSSL zum Ausrollen einer PKI erläutert.

Grundlagen PKI

Gründe für die Verwendung einer PKI können unter anderem sein:

–Authentifizierung

Bei der Kommunikation über Datennetzwerke kann die Entität auf der anderen Seite meist nicht „gesehen“ werden (Ausnahme: Videotelefonie), d. h. es besteht keine Si­cherheit darüber, dass die Entität auf der anderen Seite auch wirklich die ist, die sie zu sein vorgibt. Durch die Verwendung einer PKI ist die Authentizität der miteinander kom­munizierenden Entitäten gewährleistet.

–Vertraulichkeit der Daten

Aus diesem Grund werden Daten mittels VPN ausgetauscht: Die Datenpakete werden „in der Öffentlichkeit“ (Internet) verschickt, aber nicht befugte Entitäten erhalten keinen Zugriff auf die in den Paketen enthaltenen Informationen.

–Integrität der Daten

Die Sicherheit, dass die empfangenen Informationen den durch die andere Entität übermittelten Informationen entsprechen. Auf diese Weise wird verhindert, dass die In­formationen durch eine nicht teilnahmeberechtigte Entität „in der Mitte“ geändert wer­den.

Die Beschreibung aller für eine komplette PKI notwendigen Komponenten und Interaktio­nen würde den Rahmen des vorliegenden Dokuments sprengen, daher sollen hier nur die wichtigsten genannt werden:

–Zertifikate und private Schlüssel

Zertifikate sind ein Mittel einer PKI, um die Authentifizierung zu gewährleisten. Die Identität eines Zertifikatsinhabers wird durch eine CA anerkannt, die die Zertifikatanfor­derung des jeweiligen Inhabers signiert. Die Kodierung/Dekodierung der Daten erfolgt über öffentliche und private Schlüssel, sodass die Vertraulichkeit der Daten gewährlei­stet ist.

–Zertifizierungsstelle (CA)

Eine Zertifizierungsstelle ist eine Komponente in einer PKI, die die Authentizität der teil­nehmenden Entitäten durch Signieren von Zertifikatanfragen (d. h. die Ausstellung von Zertifikaten) gewährleistet. Normalerweise sind in einer PKI mehrere CAs in einer hier­archischen Struktur mit einer Root-CA an der Spitze organisiert.

–CRL Distribution Points (CDP)

Siehe folgenden Abschnitt Zertifikaterweiterungen.

–Miteinander kommunizierende Entitäten

Die Entitäten, die PKI verwenden, authentifizieren sich mit Zertifikaten und verwenden zum Kodieren/Dekodieren der ausgetauschten Daten den öffentlichen/privaten Schlüssel. Die Entitäten fordern die Zertifikate von der CA an. Normalerweise gehört auch eine Registration Authority (RA) zu einer PKI. Die RA ist für die erstmalige Regi­strierung von Entitäten zuständig, die die PKI verwenden möchten. Im mdm Verwen­dungs-Szenario ist keine RA notwendig.

Inhalte eines Zertifikats

Wie im vorherigen Kapitel erwähnt, enthält ein Zertifikat folgende Informationen:

–den öffentlichen Schlüssel der Entität

–Informationen über die Entität, beispielsweise Name und/oder IP-Adresse

–weitere Informationen z. B. zum Zertifikat und der Infrastruktur

In den folgenden Kapiteln werden die Inhalte genauer beschrieben.

Der Subject Distinguished Name

Der Subject Distinguished Name ist eine eindeutige Benennung des Zertifikats und dessen Inhaber. Er besteht aus mehreren Komponenten:

Entsprechend unseren Richtlinien sind nicht alle Komponenten obligatorisch, aber wenn die Erweiterung Subject Alternative Name nicht im Zertifikat enthalten ist, muss mindestens eine Komponente, die als Kennzeichnung dienen kann, angegeben werden. Dies ist nor­malerweise der Common Name (CN). Hinweis: die mdm CA kann aktuell Zertifikate mit der Erweiterung Subject Alternative Name nicht verarbeiten.

Zertifikaterweiterungen

In den sogenannten Erweiterungen oder Extensions sind Informationen über das Zertifikat oder die Infrastruktur enthalten. Im Grunde genommen kann jeder seine eigenen Erweite­rungen festlegen, aber Standarderweiterungen (X.509version3) sind in RFC 3280 Internet X.509 Public Key Infrastructure - Certificate and CRL Profile definiert. Nachfolgend sind die für die mdm CA wichtigen Erweiterungen kurz beschrieben:

–Critical Bit

Das Critical Bit ist keine Erweiterung, sondern wird verwendet, um die Verwendung von Erweiterungen im Zertifikat zu erzwingen. Das Critical Bit kann für jede Erweiterung im Zertifikat gesetzt werden. Anwendungen, die ein Zertifikat überprüfen, müssen eine Er­weiterung mit Critical Bit interpretieren können. Wenn die Anwendung die Erweiterung nicht interpretieren kann, muss das Zertifikat zurückgewiesen werden.

–Basic Constraints

Mit der Erweiterung Basic Constraints wird angezeigt, ob es sich bei einem Zertifikat um ein CA-Zertifikat handelt oder nicht. Basic Constraints besteht aus zwei Feldern:

–Feld cA vom Typ BOOLEAN und

–Feld pathLenConstraint (optional) vom Typ INTEGER

Bei CA-Zertifikaten muss das Feld cA auf true gesetzt sein. pathLenConstraint wird nur verwendet, wenn das Feld cA auf True gesetzt ist und die Nummer der zulässigen CA-Ebenen unter dem Zertifikat angibt. Basic Constraints sollte immer als kritisch gekenn­zeichnet sein.

Die Anforderungen hinsichtlich der Erweiterung Basis Constraints finden Sie in Kapitel 9.2.3.

–Key Usage

Key Usage kontrolliert die beabsichtigte Verwendung der Schlüssel eines Zertifikats. Ein Schlüssel kann verwendet werden, um Zertifikatssperrlisten (CRL) zu signieren, Daten zu verschlüsseln oder Zertifikate zu signieren.

Die Anforderungen hinsichtlich der Erweiterung Key Esage Constraints finden Sie in Kapitel 9.2.3.

–Subject Alternative Name

Mit der Erweiterung Subject Alternative Name können weitere Kennzeichen hinzuge­fügt werden. Subject Alternative Name kann zum Beispiel E-Mailadressen, Domainna­men usw. enthalten. Es kann auch als Ersatz für das Feld Subject verwendet werden, das in diesem Fall nicht frei bleiben darf. Hinweis: die mdm CA kann aktuell Zertifikate mit der Erweiterung Subject Alternative Name nicht verarbeiten.

–CRL Distribution Points (CDP)

Zertifikate können widerrufen werden, beispielsweise wenn ein privater Schlüssel be­schädigt oder nicht mehr gültig ist. Normalerweise muss die Anwendung die Gültigkeit eines Zertifikats durch Kontrolle des Gültigkeitszeitraums und/oder durch Abholen des Widerrufs von einem CRL-Verteilungspunkt (CDP) überprüfen. Zum Abholen der Infor­mationen kann entweder eine Certificate Revocation Lists (CRL) oder ein dezidiertes Protokoll wie OCSP verwendet werden. Das Zertifikat sollte jedoch Informationen dazu enthalten, welche CDP zu kontaktieren ist.

–Authority Information Access

Authority Information Access ist keine Standarderweiterung von X.509, sondern eine Erweiterung, die durch die Arbeitsgruppe PKIX definiert wurde (http://www.ietf.org/html.charters/pkix-charter.html). Authority Information Access ent­hält Informationen über die Ausgabe einer CA, beispielsweise Richtlinien, weitere Root-Zertifikate oder Informationen zum Abholen höherwertiger Zertifikate in der Kette, wenn nicht die gesamte Kette im Zertifikat enthalten ist.

Abhängig von den Einstellungen dieser Erweiterungen kann der Empfänger (nicht der Inhaber) eines Zertifikats die Kommunikation mit der Gegenstelle akzeptieren oder ver­weigern, sodass Missbrauch von Zertifikaten verhindert und eine höhere Sicherheits­stufe erreicht wird.

9.2.1CA-Zertifikate erstellen

Abhängig von der vorhandenen Infrastruktur benötigt die mdm CA folgende Zertifikate:

–Ein selbstsigniertes Root-Zertifikat (CA_rootCert) mit dem passenden privaten Schlüssel (CA_rootKey).

Wenn Sie über ein weiteres vorgeschaltetes (Root-) CA verfügen, besteht keine Not­wendigkeit zur Erstellung des Root-Zertifikats und des passenden privaten Schlüssels.

Das (selbstsignierte) Zertifikate wird an alle Entitäten verteilt, die an der Kommunika­tion teilnehmen. Es wird durch die Entitäten verwendet, um die Authentizität der Ge­genstelle und jedweder zwischengeschalteter CAs in der Zertifikatskette zu überprü­fen. Der private Schlüssel CA_rootKey wird zum Signieren des selbstsignierten Root-Zertifikats verwendet.

–Ein CA-Zertifikat (CA_cert) mit dem passenden privaten Schlüssel (CA_key). Mit diesem Zertifikat authentifiziert sich die CA selbst gegenüber anderen Entitäten. Dieses Zertifi­kat muss mit dem privaten Root-Key signiert werden, d. h. entweder mit CA_rootKey oder mit dem Schlüssel Ihrer bestehenden Root-CA. Mit dem privaten Schlüssel CA_key wird die vom mdm-Server übermittelte Zertifikatanfrage signiert, d. h. damit werden Zertifi­kate für die mGuards ausgegeben.

–Ein Template-Zertifikat (CA_templCert) das von der CA als Template bei der Ausgabe von End-Entitäts- (mGuard) Zertifikaten verwendet wird.

In Bild 9-1 ist die Zertifikathierarchie dargestellt:

Bild 9-1: mdm CA-Zertifikathierarchie

Im Folgenden wird angenommen, dass keine andere Root-CA vorhanden ist und dass die mdm CA als Root-CA verwendet wird.

Root-Zertifikat erstellen

Die folgenden OpenSSL-Befehle erfordern eine Eingabe von der OpenSSL-Konfigurations­datei openssl.cnf (in welchem Verzeichnis sich diese Datei befindet, hängt von Ihrer Vertei­lung ab, prüfen Sie beispielsweise das Verzeichnis /usr/ssl oder /usr/lib/ssl). Anstatt einer Änderung der Standard-Konfigurationsdatei Ihrer OpenSSL-Installation wird empfohlen, die im mdm CA-Installationsarchiv mdm-ca-1.11.x.zip abgelegten Beispiel-Konfigurations­dateien zu verwenden und an die jeweiligen Anforderungen anzupassen. Sie können OpenSSL anweisen, anstelle der Standard-Konfigurationsdatei die zur Verfügung gestell­ten Konfigurationsdateien zu verwenden.

OpenSSL-Konfigurationsdatei anpassen

Kopieren Sie die Datei rootCert.conf, die im Installationsarchiv
mdm-ca-1.11.x.zip zur Verfügung steht, in Ihr Arbeitsverzeichnis. Passen Sie den Bereich [ root_dn ] der Datei, in dem der Subject Distinguished Name Ihres Root-CA-Zertifikats enthalten ist, an:

[ root_dn ]

C= DE

O= Innominate Security Technologies AG

OU= Research & Development

CN= Test Root CA

Beachten Sie auch den Bereich [ root_ext ] der Konfigurationsdatei, der wichtig für die korrekte Erstellung des Root-Zertifikats ist (eine Erläuterung dazu finden Sie in Abschnitt Certificate extensions):

[ root_ext ]

keyUsage= cRLSign, keyCertSign

basicConstraints= critical, CA:true, pathlen:1

Privaten Schlüssel erstellen

Mit dem folgenden Befehl ist zunächst CA_rootKey zu erstellen:

openssl genrsa -aes256 -passout pass:rootPW
-out rootKey.pem 2048

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–rootKey.pem

Diese Datei enthält CA_rootKey im PEM format. Der Schlüssel wird mit dem AES256-Algorith­mus kodiert. Für den Zugriff auf den Schlüssel müssen Sie die oben angegebene Pas­sphrase kennen (im Beispiel: rootPW). Verwenden Sie zum Kodieren des privaten Schlüs­sels ein eigenes sicheres Passwort.

Root-Zertifikat erstellen

Der OpenSSL-Befehl zur Erstellung von CA_rootCert lautet:

openssl req -batch -new -config rootCert.conf -x509
-key rootKey.pem -keyform PEM -passin pass:rootPW -sha256 -days 5479 -outform PEM -out rootCert.pem

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–rootCert.pem
Diese Datei enthält das selbstsignierte Root-Zertifikat CA_rootCert.

CA-Zertifikat erstellen

Das zwischengeschaltete CA-Zertifikat CA_cert ist zwar nicht selbstsigniert, wird aber durch die Root-CA ausgegeben (signiert). Daher müssen Sie zuerst einen privaten Schlüssel er­stellen und eine entsprechende Zertifikatanforderung an die Root-CA „abschicken“. Die Root-CA gibt dann wiederum das CA_cert aus.

Zuerst muss die Konfigurationsdatei wie im vorhergehenden Abschnitt beschrieben an Ihre Bedürfnisse angepasst werden.

OpenSSL-Konfigurationsdatei und die Umgebung anpassen

Kopieren Sie die Datei caCert.conf, die im Installationsarchiv
mdm-ca-1.11.x.zip enthalten ist, in Ihr Arbeitsverzeichnis. Passen Sie den Bereich [ ca_dn ] der Datei, in dem der Subject Distinguished Name Ihres Root-CA-Zertifikats enthalten ist, an:

[ ca_dn ]

C= DE

O= Innominate Security Technologies AG

OU= Research & Development

CN= Test CA

Passen Sie ebenfalls die Einträge crlDistributionPoints und authorityInfoAc­cess des Bereichs [ ca_ext ] der Konfigurationsdatei an (Erläuterung siehe Abschnitt Cer­tificate extensions):

[ ca_ext ]

crlDistributionPoints=URI:http://ca.example.com/ca-ca.crl

authorityInfoAccess=OCSP;URI:http://ca.example.com/ocsp/ca-ca

Die Konfigurationsdatei enthält einige Parameter, die nicht in die Kommandozeile eingege­ben werden können. Diese Einträge geben Dateien an, die im Dateisystem vorhanden sein müssen. Daher sind diese Dateien zuerst manuell zu erstellen (die Dateinamen werden ebenfalls in der Datei caCert.con verwendet, benutzen Sie daher genau die gleichen Da­teinamen wie unten angegeben):

–Erstellen Sie in Ihrem Arbeitsverzeichnis ein Unterverzeichnis archive
(Linux: mkdir ./archive)

–Legen Sie im Unterverzeichnis archive eine Datei mit der Bezeichnung serial an, die die gültige Seriennummer für das Zertifikat enthält
(Linux: echo 1234 > archive/serial)

–Legen Sie eine leere Datei an, die als OpenSSL-Datenbank verwendet werden kann.
(Linux: touch archive/index.txt
Windows: copy NUL: archive/index.txt)

Privaten Schlüssel erstellen

Zuerst ist mit dem folgendem Befehl der private Schlüssel CA_key zu erstellen:

openssl genrsa -aes256 -passout pass:caPW -out caKey.pem 2048

Erläuterung der Argumente:

Mit diesem Befehl wird die Ausgabedatei erstellt:

–caKey.pem
Diese Datei enthält den CA_key im PEM-Format. Der Schlüssel wird mit dem AES256-Algorithmus kodiert. Für den Zugriff auf den Schlüssel müssen Sie die oben angegebe­ne Passphrase kennen (im Beispiel: caPW). Verwenden Sie zum Kodieren des priva­ten Schlüssels ein eigenes sicheres Passwort.

Zertifikatanfrage erstellen

Eine Zertifikatanfrage wird mit folgendem Befehl erstellt:

openssl req -batch -new -config caCert.conf
-key caKey.pem -keyform PEM -passin pass:caPW -sha256
-out caCertReq.pem -outform PEM

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–caCertReq.pem
Diese Datei enthält die Zertifikatanfrage.

CA-Zertifikat anfordern

Die Anfrage muss an die Root-CA übermittelt werden. Da die mdm CA im Beispiel die Root-CA ist, können Sie das Zertifikat mit folgendem Befehl ausgeben:

openssl ca -batch -config caCert.conf -days 3653
-in caCertReq.pem -cert rootCert.pem -keyfile rootKey.pem
-passin pass:rootPW -md sha256 -notext -out caCert.pem
-outdir .

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–caCert.pem
Diese Datei enthält CA_cert.

Zertifikatvorlage anlegen

Die CA dient der Ausgabe von Zertifikaten. Dazu benötigt die CA eine Anleitung zu den aus­zugebenden Zertifikaten, beispielsweise zu den benötigten Erweiterungen. Dazu kann der CA eine Zertifikatvorlage zur Verfügung gestellt werden (CA_templCert). CA_templCert ist ein von der CA ausgegebenes Zertifikat. Zur Ausgabe eines Zertifikats müssen Sie zunächst wie­der eine OpenSSL-Konfigurationsdatei anpassen.

OpenSSL-Konfigurationsdatei anpassen

Kopieren Sie die Datei templateCert.conf, die im Installationsarchiv
mdm-ca-1.11.x.zip enthalten ist, in Ihr Arbeitsverzeichnis. Passen Sie die Einträge crl­DistributionPoints und authorityInfoAccess des Bereichs [ template_ext ] der Konfigurationsdatei an (Erläuterung siehe Abschnitt Certificate extensions):

[ template_ext ]

crlDistributionPoints=URI:http://ca.example.com/ca-ee.crl

authorityInfoAccess=OCSP;URI:http://ca.example.com/ocsp/ca-ee

Privaten Schlüssel erstellen

Zuerst ist mit dem folgendem Befehl der private Schlüssel zu erstellen:

openssl genrsa -aes256 -passout pass:caPW -out templateKey.pem 2048

Erläuterung der Argumente:

Mit diesem Befehl wird die Ausgabedatei erstellt:

–templateKey.pem
Diese Datei enthält einen kodierten privaten Schlüssel.

Zertifikatanfrage erstellen

Eine Zertifikatanfrage wird mit folgendem Befehl erstellt:

openssl req -new -batch -config templateCert.conf
-key templateKey.pem -keyform PEM -passin pass:caPW
-sha256 -outform PEM -out templateCertReq.pem

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–templateCertReq.pem
Diese Datei enthält die Zertifikatanfrage.

Zertifikatvorlage anfordern

Die Anfrage muss an die (zwischengeschaltete) CA übermittelt werden. Sie können die Zer­tifikatanfrage mit dem folgenden Befehl signieren (das Zertifikat ausgeben):

openssl ca -batch -config templateCert.conf -days 1826
-md sha256 -in templateCertReq.pem -keyfile caKey.pem
-cert caCert.pem -passin pass:caPW -notext
-out templateCert.pem -outdir .

Erläuterung der Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–templateCert.pem
Diese Datei enthält CA_templCert. Die Datei sollte in ihr endgültiges Zielverzeichnis kopiert werden; der Speicherort ist in ca-preferences.xml im Knoten
                  certificateFactory » certTemplate zu konfigurieren.

9.2.2Schlüsselverzeichnisse erstellen

Nach Durchführung der in Kapitel 9.2.1 beschriebenen Schritte sollten Sie in Ihrem Arbeits­verzeichnis die folgenden Dateien vorfinden:

–templateCert.pem
Diese Datei enthält CA_templCert, signiert mit CA_key.

–caCert.pem
Diese Datei enthält CA_cert, signiert mit CA_rootKey.

–caKey.pem
Diese Datei enthält CA_key.

–rootCert.pem
Diese Datei enthält das selbstsignierte Root-Zertifikat CA_rootCert.

–rootKey.pem
Diese Datei enthält den kodierten privaten Schlüssel CA_rootKey.

Einige dieser Dateien müssen in den Schlüsselspeichern enthalten sein. Das Installations­archiv mdm-ca-1.11.x.zip enthält das (proprietäre) Java-Tool ImportKey im Verzeichnis de­moCA das für das Anlegen und Verwalten von Schlüsselspeichern verwendet werden kann. Kopieren Sie die Datei ImportKey.class in Ihr Arbeitsverzeichnis.

Zuerst müssen das zwischengeschaltete CA-Zertifikat und das Root-Zertifikat in einer Datei zusammengeführt werden (eine Zertifikatskette erstellt werden):

cat caCert.pem rootCert.pem > caCertWithChain.pem

Dann muss der Key caKey.perm in das Format PKCS#8 umgewandelt und sowohl CA_key als auch die Zertifikatskette müssen in einen PKC#12-Schlüsselspeicher übernommen werden. Dies kann mit dem Tool ImportKey abgeschlossen werden. ImportKey akzeptiert nur den (nicht kodierten) Schlüssel am Standardeingang, daher kann die Ausgabe des Be­fehls pkcs8 wie folgt weitergereicht werden:

openssl pkcs8 -topk8 -in caKey.pem -passin pass:caPW
-inform PEM -nocrypt -outform DER |
java -cp . ImportKey -alias ca -keystore ca-keystore.jks -storetype JKS -storepass pass:caPW -keypass pass:caPW
-chain caCertWithChain.pem

Erläuterung der openssl-Argumente:

Erläuterung der ImportKey-Argumente:

Mit dem Befehl oben wird die Ausgabedatei erstellt:

–ca-keystore.jks
Dies ist der Schlüsselspeicher für Ihre CA, der die Zertifikatskette und den privaten CA-Schlüssel enthält. Kopieren Sie den Schlüsselspeicher in sein endgültiges Zielver­zeichnis.

–Der Dateiname mit dem absoluten oder relativen Pfad dieses Schlüsselspeichers muss in der Datei ca-preferences.xml im Knoten certificateFactory » keyStore kon­figuriert werden.

–Das Passwort für den Zugriff auf den Schlüsselspeicher (im Beispiel caPW) muss in der Datei ca-preferences.xml im Knoten certificateFactory » keyStorePassword konfiguriert werden.

–Das Format dieses Schlüsselspeichers (Java KeyStore - JKS) muss in der Datei ca-preferences.xml im Knoten certificateFactory » keyStoreType konfiguriert wer­den.

–Das Passwort für den Zugriff auf den privaten Schlüssel (im Beispiel caPW) muss in der Datei ca-preferences.xml im Knoten certificateFactory » keyStorePassword konfiguriert werden.

–Der Alias (ca) des Schlüssels muss in der Datei ca-preferences.xml im Knoten certificateFactory » keyAlias konfiguriert werden.

9.2.3Anforderungen an Zertifikate

Für die einwandfreie Funktion der VPN-Zertifikate auch mit zukünftigen Versionen der mGuard-Firmware und des mdm müssen die Zertifikate folgende Anforderungen erfüllen:

1.Der private Schlüssel sollte eine Länge von mindestens 1024 Bit aufweisen. Phoenix Contact empfiehlt für die langfristige Sicherheit eine Schlüssellänge von 2048 Bit.

2.Alle Zertifikate müssen RFC 3280 entsprechen.

3.Alle Zertifikate müssen eine Basic Constraints-Erweiterung aufweisen, die als kritisch markiert ist und das Boolean-Feld cA muss auf true gesetzt sein.

4.Phoenix Contact empfiehlt dringend, das Feld pathLenConstraint in die Basic Cons­traints-Erweiterung aller Zertifikate einzubeziehen. Es muss auf eine Zahl unter der An­zahl der nachfolgenden Zertifikate gesetzt sein. Für ein typisches Szenario, bei dem eine Zertifikatskette aus einem Root-CA-Zertifikat, einem einzelnen zwischengeschal­tetem CA-Zertifikat und einem End-Entitäts-Zertifikat (VPN-Zertifikat in diesem Fall) be­steht, muss der pathLenConstraint eins (1) für das Root-CA-Zertifikat und Null für das zwischengeschaltete Zertifikat betragen.

5.Das Zertifikat des VPN-Templates muss über eine Basic Constraints-Erweiterung ver­fügen, die als kritisch markiert ist und das Boolean-Feld cA muss auf false gesetzt sein und ohne ein Feld pathLenConstraint.

6.Alle CA-Zertifikate müssen eine Key Usage-Erweiterung aufweisen, die als kritisch markiert ist und das Bit keyCertSign muss gesetzt sein. Es wird empfohlen, auch das Bit cRLSign zu setzen.

7.Das Zertifikat des VPN-Templates benötigt keine Key Usage-Erweiterung.

8.Ein zwischengeschaltetes CA-Zertifikat muss eine oder beide Erweiterungen CRL Dis­tribution Points und Authority Information Access enthalten, wenn Sperrinformationen online mit einer zukünftigen Version von mdm und der mGuard-Firmware weitergeleitet werden sollen. Die Erweiterung muss als nicht-kritisch gekennzeichnet sein. Die frühe­re Erweiterung wird benötigt, wenn die Zertifikatssperrlisten (CRLs) in Zukunft verwen­det werden sollen. Die letztere Erweiterung wird benötigt, wenn zukünftig die Verwendung des Online Certificate Status Protocol (OCSP, siehe RFC 2560) geplant ist. Jede der Erweiterungen darf nur HTTP-URLs enthalten.

9.Ein Template für ein VPN-Zertifikat sollte eine oder beide Erweiterungen CRL Distribu­tion Points und Authority Information Access wie oben beschrieben enthalten, wenn Sperrinformationen online weitergeleitet werden sollen. Alternativ kann der mdm-Ser­ver angewiesen werden, diese in die Zertifikatanfrage einzufügen, die an die mdm CA übermittelt wurde. Das letztere ist flexibler, weil auf diese Art der Speicherort der Sper­rinformationen (CRL) bzw. der Informationsdienst (OSCP) für Gerätegruppen und so­gar für einzelne Geräte eingerichtet werden.
Hinweis: Wenn das Template für das VPN-Zertifikat bereits eine dieser Erweiterungen enthält und der mdm angewiesen ist, dieses auch in die Zertifikatanforderung einzufü­gen, überschreibt die Erweiterung aus der Anfrage die im Template enthaltene Erwei­terung. Das ausgegebene Zertifikat enthält die aus der Anfrage kopierte Erweiterung.

10.Der Schlüsselspeicher muss die komplette Zertifikatskette bis einschließlich des Root-Zertifikats enthalten.