Erste Schritte und häufig gestellte Fragen
Was muss vorbereitet werden?
Zertifikat(e)
Um die Kommunikation zwischen den verschiedenen Komponenten von enaio® zu sichern, benötigt ein Kunde ein SSL-Zertifikat.
Es gibt zwei Wege, ein solches Zertifikat zu erhalten:
Erwerb von einer kommerziellen Zertifizierungsstelle.
Dies ist in der Regel für Produktivsysteme empfohlen.Erstellen eines selbstsignierten Zertifikats (sofern es die Unternehmensrichtlinien zulassen).
Diese Option erfordert etwas tiefer gehende Kenntnisse über die TLS-Zertifikate und die erforderlichen Werkzeuge.
Auf der Seite Beispiele für die Erstellung der selbstsignierten Zertifikate stellen wir als Beispiel einige Leitlinien für diese Option bereit.
Server-Informationen
Bei der Beantragung oder Erstellung von Zertifikaten ist es wichtig, den X509v3 Subject Alternative Name richtig zu definieren. Dazu wird eine Liste aller DNS-Namen und/oder IP-Adressen der Rechner benötigt, auf denen die Serverkomponenten installiert werden. Dazu gehören:
enaio® server
enaio® service-manager
enaio® gateway
enaio® documentviewer
enaio® appconnector.
Für den enaio® server müssen die IP-Adressen unbedingt eingetragen werden.
Windows-Zertifikatsspeicher
Wir empfehlen, alle benötigten Zertifikate in den Windows-Zertifikatsspeicher Lokaler Computer → Vertrauenswürdige Stammzertifikate zu speichern. Diese Option bietet die größte Flexibilität beim Rollout der Zertifikate, beim Ersetzen der abgelaufenen Zertifikate und bei der Installation der Hotfixes für die enaio-Komponenten, ohne dass die Zertifikate erneut in die JDK-Keystores importiert werden müssen.
Keytool und Keystore Explorer (Optional)
Falls Sie den Windows-Zertifikatspeicher nicht verwenden möchten: Bei einigen Konfigurationsschritten greifen wir auf das Java-Befehlszeilendienstprogramm Keytool zurück, das mit unseren Services als Teil des verwendeten JDK gebündelt wird und somit automatisch verfügbar ist. Obwohl es mit dem Befehlszeilendienstprogramm Keytool möglich ist, den Inhalt des Java KeyStore zu inspizieren, ist es manchmal einfacher, eine Open-Source-GUI zu verwenden: den KeyStore Explorer (https://keystore-explorer.org/). Dies ist jedoch nicht zwingend erforderlich.
Zertifikatsformate
Die folgenden Dateiformate werden in enaio® für die Handhabung der SSL-Zertifikate verwendet.
PEM
Das PEM-Format ist das häufigste Format, in dem Zertifizierungsstellen Zertifikate ausstellen. PEM-Zertifikate haben normalerweise Erweiterungen wie .pem, .crt, .cer und .key.
Es handelt sich um Base64-kodierte ASCII-Dateien. Serverzertifikate, Zwischenzertifikate und private Schlüssel können alle im PEM-Format gespeichert werden.
Für den Austausch von Zertifikaten mit privaten Schlüsseln wird jedoch das PKCS12-Format bevorzugt.
PKCS12
PKCS12 definiert ein Archivdateiformat zur Speicherung vieler Kryptographieobjekte in einer einzigen Datei.
Die Dateinamenerweiterung für PKCS12-Dateien ist .p12 oder .pfx. In diesem Format werden binäre Daten übertragen.
Es wird üblicherweise verwendet, um einen privaten Schlüssel mit seinem X.509-Zertifikat zu bündeln oder um alle Mitglieder einer Vertrauenskette zu bündeln.
Eine PKCS12-Datei kann verschlüsselt und signiert werden. Die internen Speicher, sogenannte SafeBags, können ebenfalls verschlüsselt und signiert werden.
Einige SafeBags sind vordefiniert, um Zertifikate, private Schlüssel und CRLs zu speichern. Ein weiterer SafeBag ist vorgesehen, um beliebige andere Daten zu speichern.
Das PKCS12-Format ist die bevorzugte Methode für den Transport von privaten Schlüsseln und ihren öffentlichen Zertifikatsketten.
Generell ist PKCS12 der beste Weg, um private Schlüssel zu transportieren und auszutauschen, da es eine stärkere Verschlüsselung für den privaten Schlüssel verwendet.
Anforderungen an SSL-Zertifikate
Das für jeden Server verwendete SSL-Zertifikat muss gültig sein. Das bedeutet, dass folgende Anforderungen erfüllt sind:
Die Zertifikatskette ist gültig.
Das Zertifikat verweist auf eine vertrauenswürdige Stammzertifizierungsstelle.
Das Zertifikat ist noch nicht abgelaufen und stammt nicht aus der Zukunft.
Das Zertifikat gibt an, dass es als TLS-Serverzertifikat verwendet werden soll (X509v3 Extended Key Usage: serverAuth).
Das Zertifikat gilt für den Hostnamen, mit dem Sie sich verbinden (X509v3 Subject Alternative Name: DNS und/oder IP-Adressen).
Jeder Rechner kann mit einem eigenen Zertifikat gesichert werden, aber für die einfachere Übersicht, Konfiguration und künftige Erneuerung empfehlen wir die Verwendung eines Wildcard-Zertifikats, insbesondere bei der Erstellung selbstsignierter Zertifikate.
Es gibt zwei Hauptvarianten der Verschlüsselung von Zertifikaten, die den Anforderungen des BSI entsprechen: RSA-Schlüssel und Schlüssel mit elliptischer Kurve (EC).
Bei RSA sollte die Schlüssellänge mindestens 3000 Bit betragen. In enaio® werden elliptische Kurven nur bis zum secp384r1 unterstützt, weil die längere secp521r1 noch nicht von Web-Browsern überall unterstützt wird.
Da alle kürzeren elliptischen Kurven nicht mehr sicher sind, bleibt secp384r1 als die einzige valide Option für EC-Schlüssel.
Die aktuelle BSI-Anforderungen finden Sie unter folgendem Link: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf
Erforderliche Dateien für die TLS-Konfiguration
Gleich ob die Zertifikate gekauft oder selbst signiert wurden, sollten die folgenden Dateien vor Beginn der TLS-Konfiguration vorbereitet werden, denn sie werden für den Konfigurationsprozess benötigt:
enaioCertificate.key
– privater Schlüssel des ZertifikatsenaioCertificate.crt
– das Zertifikat (öffentlicher Schlüssel)enaioCertificateWithKey.p12
– das Zertifikat einschließlich seines privaten Schlüssels im PKCS12-FormatenaioCertificateFullChainWithKey.pem
– das Zertifikat einschließlich seines privaten Schlüssels und der vollständigen Zertifikatskette im PEM-Format
Falls die selbstsignierten Zertifikate verwendet werden, benötigen Sie zusätzlich die folgende Datei:
CustomRootCA.crt
undCustomRootCA.p12
– benutzerdefinierte CA-Stammzertifikate im PEM- und PKCS12-Format.
Benutzerdefiniertes CA-Stammzertifikat
Bei Verwendung eines selbstsignierten Zertifikats anstelle eines kommerziellen Zertifikats muss das benutzerdefinierte CA-Stammzertifikat später in den Speicher der vertrauenswürdigen Stammzertifizierungsstellen auf allen Clients importiert werden. Je nach Fall entweder in den Windows-Zertifikatspeicher, den Java-Zertifikatspeicher oder die enaio®-Serverkonfigurationsdatei.
Aktuell muss bei Verwendung des Windows-Zertifikatspeicher zusätzlich das Zertifikat selber einschließlich seines privaten Schlüssels (enaioCertificateWithKey.p12
) in den Speicher der vertrauenswürdigen Stammzertifizierungsstellen auf allen Clients importiert werden, damit die enaio Services dieses validieren können.
Bitte beachten Sie, dass dies nicht nur für enaio® client und enaio® webclient gilt, sondern auch für die serviceübergreifende Kommunikation, da viele Komponenten je nach Kontext sowohl als Server als auch als Client arbeiten können. Andernfalls wird das selbstsignierte Zertifikat nicht als vertrauenswürdig eingestuft. Die Einzelheiten sind in den einzelnen Installationsschritten beschrieben.