Sichere Verbindung (TLS/HTTPS)

Für einen sicheren Betrieb des BPC sollten möglichst nur gesicherte Verbindungen genutzt werden.

Für die korrekte Konfiguration sind Kenntnisse über TLS im Allgemeinen und der Konfiguration von Java basierten Anwendungen mit Truststore und Keystore nötig.

Zur Kommunikation mit OpenSearch wird seit BPC 4.1.9 bzw. 4.2.0 in der Voreinstellung HTTPS (Port 9200) verwendet.

Für die allgemeine Netzwerkkonfiguration des BPC sei auf Netzwerk verwiesen.

In produktiven Umgebungen sollten mindestens die eingehenden Verbindungen durch ein eigenes Zertifikat abgesichert werden. Dies ist im Abschnitt Eingehende Verbindungen mit eigenem Zertifikat absichern beschrieben.

Übersicht der BPC Netzwerkverbindungen

In diesen Grafiken sind die Netzwerkverbindungen für das BPC im Single Node und Cluster Betrieb zu sehen.

An den Verbindungen ist stets der verwendete Netzwerk-Port hinter dem Doppelpunkt angegeben. So wird zum Beispiel bei TLS extern (:8282) der Port 8282 angesprochen.

Netzwerk-Ports können auch abweichend konfiguriert werden. Siehe dazu Netzwerk.
Übersicht über die Netzwerkstruktur Single Node
Illustration 1. Übersicht über die Netzwerkstruktur Single Node
Übersicht über die Netzwerkstruktur Cluster
Illustration 2. Übersicht über die Netzwerkstruktur Cluster

Die Netzwerkverbindungen lassen sich in externe bzw. eingehende Verbindungen (siehe Eingehende Verbindungen mit eigenem Zertifikat absichern) und interne Verbindungen (Interne Verbindungen mit eigenem Zertifikat absichern) unterscheiden. Diese lassen sich getrennt voneinander konfigurieren.

Allgemeine Informationen zur Netzwerkkonfiguration finden Sie unter Netzwerk.

Keystores und Truststores

Keystores und Truststores sind wichtige Dateien, für die Konfiguration von TLS.

In den Keystores sind nicht öffentliche Zertifikate (Private Key) enthalten. Diese werden entweder als Server-Zertifikat genutzt, um TLS/HTTPS Verbindungen anzubieten oder als Client-Zertifikat, um sich bei Verwendung von Mutual TLS authentication (mTLS) gegenüber des Servers zu authentifizieren. Diese Zertifikate sind sensible Informationen. Daher sind sie in der Regel durch Passwörter geschützt.

In den Truststores sind öffentliche Zertifikate (Public Key) enthalten. Damit ist es möglich beim Aufbau einer gesicherten Verbindung gegen einen Server die Authentizität des Servers sicherzustellen. Bei der Verwendung von mTLS kann man die Authentizität des Clients verifizieren, der die Verbindung aufbaut.

Diese beiden Dateien werden im Karaf, wie auch im OpenSearch genutzt, um verschiedene Verbindungen abzusichern.

Für die Erstellung von Zertifikaten und dem Arbeiten mit den Keystore/Truststore-Dateien können die Kommandozeilentools openssl und keytool verwendet werden. Wesentlich komfortabler geht dies mit dem KeyStore Explorer.

Keystore und Truststore Dateien zentralisieren

Es wird empfohlen die Keystore- und Truststore-Dateien außerhalb vom Karaf und OpenSearch, an einer zentralen Stelle, abzulegen. Dies erleichtert zukünftige Updates, da so OpenSearch und Karaf aktualisiert werden können, ohne dass die Konfiguration von TLS wiederholt werden muss.

Standardort Karaf

INSTALLATIONSVERZEICHNIS/karaf/etc/virtimo/ssl

Standardort OpenSearch

INSTALLATIONSVERZEICHNIS/opensearch/config/virtimo/ssl

Empfohlener neuer Ort

INSTALLATIONSVERZEICHNIS/ssl

Die bpc.env ist so anzupassen, dass der Karaf die Dateien findet und für OpenSearch ein passender Link angelegt wird. Der Link für OpenSearch ist leider nötig, da der Prozess nicht auf Dateien außerhalb seines Ordners zugreifen darf.

bpc.env.sh (Linux)
export ORG_OPS4J_PAX_WEB_ORG_OPS4J_PAX_WEB_SSL_KEYSTORE=../ssl/virtimo_keystore.jks
export ORG_OPS4J_PAX_WEB_ORG_OPS4J_PAX_WEB_SSL_TRUSTSTORE=../ssl/virtimo_truststore.jks
Link unter Linux anlegen
cd opensearch/config/virtimo && ln -s ../../../ssl ssl
bpc.env.cmd (Windows)
SET ORG_OPS4J_PAX_WEB_ORG_OPS4J_PAX_WEB_SSL_KEYSTORE=../ssl/virtimo_keystore.jks
SET ORG_OPS4J_PAX_WEB_ORG_OPS4J_PAX_WEB_SSL_TRUSTSTORE=../ssl/virtimo_truststore.jks
Link unter Windows anlegen
rmdir /s opensearch\config\virtimo\ssl && mklink /J opensearch\config\virtimo\ssl ssl

Für die Erstellung des Symlinks unter Windows sind Administrator-Rechte nötig.

Beachten Sie, dass bei dieser Konfiguration OpenSearch und Karaf dieselben Keystore und Truststore Dateien nutzen. Das bedeutet, dass darin alle nötigen Zertifikate mit den passenden Aliases abgelegt sein müssen, die für beide Systemkomponenten nötig sind.

Java Truststore cacerts

Jede Java-Installation enthält einen Default Truststore mit dem Dateinamen cacerts. Dieser Truststore enthält alle root CAs, die der Distributor der Java-Installation für relevant hält. Theoretisch können alle öffentlichen Zertifikate auch nur dort abgelegt werden. Wir raten jedoch davon ab, da auch Java selbst regelmäßig aktualisiert werden muss. In diesem Fall müsste die cacerts Datei aus der alten Installation übernommen oder die neue cacerts angepasst werden. Dies ist ein potenzielles Fehlerrisiko und unnötiger Aufwand.

Auslieferungszustand

Das BPC wird im Auslieferungszustand bereits mit vorkonfigurierten Keystores (virtimo_keystore.jks) und Truststores (virtimo_truststore.jks) ausgestattet. Diese enthalten selbst signierte Zertifikate und sind im OpenSearch (opensearch/config/virtimo/ssl) und Karaf (karaf/etc/virtimo/ssl) hinterlegt. Die Dateien sind in beiden Ordnern identisch, auch wenn dies nicht zwingend nötig wäre.

Script mit dem der default Keystore und Truststore erstellt wurden 
#!/bin/sh

mkdir certs && cd certs

# ---------------------------------------------------------------------
# ROOT Zertifikat, hat eine Gültigkeitsdauer von 10 Jahren (~ 3650 Tage)
# ----------------------------------------------------------------------

openssl genrsa -out root-ca-key.pem 2048

openssl req \
  -new \
  -x509 \
  -sha256 \
  -key root-ca-key.pem \
  -subj "/DC=com/DC=example/O=Example Com Inc./OU=Example Com Inc. Root CA/CN=Example Com Inc. Root CA" \
  -addext "basicConstraints = critical,CA:TRUE" \
  -addext "keyUsage = critical, digitalSignature, keyCertSign, cRLSign" \
  -addext "subjectKeyIdentifier = hash" \
  -addext "authorityKeyIdentifier = keyid:always,issuer:always" \
  -days 3650 \
  -out root-ca.pem

#openssl pkcs12 -export \
#  -name root-ca \
#  -in root-ca.pem \
#  -inkey root-ca-key.pem \
#  -out root-ca.p12 \
#  -password pass:virtimo

keytool -import \
  -file root-ca.pem \
  -alias root-ca \
  -keystore virtimo_truststore.jks \
  -storepass virtimo \
  -noprompt

# -------------------------------------------------
# Für den Jetty/Karaf/PAX Web mit dem Alias 'karaf'
# -------------------------------------------------

openssl genrsa -out karaf-key-temp.pem 2048

openssl pkcs8 \
  -inform PEM \
  -outform PEM \
  -in karaf-key-temp.pem \
  -topk8 \
  -nocrypt \
  -v1 PBE-SHA1-3DES \
  -out karaf-key.pem

openssl req \
  -new \
  -key karaf-key.pem \
  -subj "/C=DE/L=Berlin/O=Virtimo AG/OU=karaf/CN=karaf.example.com" \
  -out karaf.csr

cat > karaf.extfile << EOF
subjectAltName = DNS:karaf.example.com, DNS:localhost, IP:::1, IP:127.0.0.1
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
basicConstraints = critical,CA:FALSE
EOF

openssl x509 \
  -req \
  -in karaf.csr \
  -out karaf.pem \
  -CA root-ca.pem \
  -CAkey root-ca-key.pem \
  -CAcreateserial \
  -days 3650 \
  -extfile karaf.extfile

openssl pkcs12 -export \
  -name karaf \
  -in karaf.pem \
  -inkey karaf-key.pem \
  -out karaf.p12 \
  -password pass:virtimo

keytool \
  -importkeystore \
  -destkeystore virtimo_keystore.jks \
  -deststoretype jks \
  -deststorepass virtimo \
  -srckeystore karaf.p12 \
  -srcstoretype pkcs12 \
  -srcstorepass virtimo \
  -alias karaf

rm karaf.csr
rm karaf.extfile

# -------------------------------------------------------
# Für den OpenSearch Node mit dem Alias 'opensearch_node'
# -------------------------------------------------------

openssl genrsa -out opensearch_node-key-temp.pem 2048

openssl pkcs8 \
  -inform PEM \
  -outform PEM \
  -in opensearch_node-key-temp.pem \
  -topk8 \
  -nocrypt \
  -v1 PBE-SHA1-3DES \
  -out opensearch_node-key.pem

openssl req \
  -new \
  -key opensearch_node-key.pem \
  -subj "/C=DE/L=Berlin/O=Virtimo AG/OU=node/CN=node-0.example.com" \
  -out opensearch_node.csr

cat > opensearch_node.extfile << EOF
subjectAltName = RID:1.2.3.4.5.5, DNS:node-0.example.com, DNS:localhost, IP:::1, IP:127.0.0.1
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
basicConstraints = critical,CA:FALSE
EOF

openssl x509 \
  -req \
  -in opensearch_node.csr \
  -out opensearch_node.pem \
  -CA root-ca.pem \
  -CAkey root-ca-key.pem \
  -CAcreateserial \
  -days 3650 \
  -extfile opensearch_node.extfile

openssl pkcs12 -export \
  -name opensearch_node \
  -in opensearch_node.pem \
  -inkey opensearch_node-key.pem \
  -out opensearch_node.p12 \
  -password pass:virtimo

keytool \
  -importkeystore \
  -destkeystore virtimo_keystore.jks \
  -deststoretype jks \
  -deststorepass virtimo \
  -srckeystore opensearch_node.p12 \
  -srcstoretype pkcs12 \
  -srcstorepass virtimo \
  -alias opensearch_node

rm opensearch_node.csr
rm opensearch_node.extfile

# ---------------------------------------------------------
# Für den OpenSearch ADMIN mit dem Alias 'opensearch_admin'
# ---------------------------------------------------------

openssl req \
  -new \
  -newkey rsa:2048 \
  -keyout opensearch_admin-key.pem \
  -out opensearch_admin.csr \
  -nodes \
  -subj "/C=DE/L=Berlin/O=Virtimo AG/OU=Dev/CN=opensearch_admin"

cat > opensearch_admin.extfile << EOF
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment
extendedKeyUsage = critical,clientAuth
authorityKeyIdentifier = keyid,issuer:always
subjectKeyIdentifier = hash
EOF

openssl x509 \
  -req \
  -in opensearch_admin.csr \
  -CA root-ca.pem \
  -CAkey root-ca-key.pem \
  -CAcreateserial \
  -out opensearch_admin.pem \
  -days 3650 \
  -extfile opensearch_admin.extfile

#openssl pkcs12 -export \
#  -name opensearch_admin \
#  -in opensearch_admin.pem \
#  -inkey opensearch_admin-key.pem \
#  -out opensearch_admin.p12 \
#  -password pass:virtimo

rm opensearch_admin.csr
rm opensearch_admin.extfile

# ----------------------------------------------------------------------------------------
# Für den OpenSearch BPC User mit dem Alias 'bpc'. Karaf / OpenSearch Client -> OpenSearch
# Unser OpenSearch ist so konfiguriert, dass der Wert aus CN (= bpc) der Username ist.
# ----------------------------------------------------------------------------------------

openssl req \
  -new \
  -newkey rsa:2048 \
  -keyout opensearch_bpc-key.pem \
  -out opensearch_bpc.csr \
  -nodes \
  -subj "/C=DE/L=Berlin/O=Virtimo AG/OU=client/CN=bpc"

cat > opensearch_bpc.extfile << EOF
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment
extendedKeyUsage = critical,clientAuth
authorityKeyIdentifier = keyid,issuer:always
subjectKeyIdentifier = hash
EOF

openssl x509 \
  -req \
  -in opensearch_bpc.csr \
  -CA root-ca.pem \
  -CAkey root-ca-key.pem \
  -CAcreateserial \
  -out opensearch_bpc.pem \
  -days 3650 \
  -extfile opensearch_bpc.extfile

openssl pkcs12 -export \
  -name opensearch_bpc \
  -in opensearch_bpc.pem \
  -inkey opensearch_bpc-key.pem \
  -out opensearch_bpc.p12 \
  -password pass:virtimo

keytool \
  -importkeystore \
  -destkeystore virtimo_keystore.jks \
  -deststoretype jks \
  -deststorepass virtimo \
  -srckeystore opensearch_bpc.p12 \
  -srcstoretype pkcs12 \
  -srcstorepass virtimo \
  -alias opensearch_bpc

rm opensearch_bpc.csr
rm opensearch_bpc.extfile

Keystore virtimo_keystore.jks

Das Standardpasswort für den Keystore virtimo_keystore.jks ist virtimo.

Folgende Keys/Zertifikate befinden sich im Keystore virtimo_keystore.jks.

Alias Passwort Verwendungszweck

karaf

virtimo

Server-Zertifikat für externe Verbindungen (TLS extern (:8080))

opensearch_bpc

virtimo

Client-Zertifikat für die Verbindung Karaf → OpenSearch (mTLS intern (:9200) und mTLS intern (:9203)).

Siehe auch Zertifikate für mTLS Authentifizierung mit OpenSearch.

opensearch_node

virtimo

Client-Zertifikat für die Verbindung OpenSearch → OpenSearch (mTLS intern (:9300))

Keystore Konfiguration im Karaf

In der karaf/etc/org.ops4j.pax.web.cfg wird der Keystore über folgende Einstellungen referenziert.

Ausschnitt der Keystore Konfiguration aus karaf/etc/org.ops4j.pax.web.cfg
org.ops4j.pax.web.ssl.keystore = ${karaf.etc}/virtimo/ssl/virtimo_keystore.jks
org.ops4j.pax.web.ssl.keystore.password = virtimo
org.ops4j.pax.web.ssl.keystore.type = JKS

Außerdem wird hier das Zertifikat definiert, das für TLS/HTTPS (TLS extern (:8282)) benötigt wird.

Ausschnitt der TLS-Zertifikats Konfiguration aus karaf/etc/org.ops4j.pax.web.cfg
# TLS Keys
org.ops4j.pax.web.ssl.key.alias = karaf
org.ops4j.pax.web.ssl.key.password = virtimo

Die Einstellung org.ops4j.pax.web.ssl.key.alias war in früheren Versionen nicht gesetzt und ist nun Pflicht.

Für Karaf ist es zwingend erforderlich, dass das Keystore Passwort und das Passwort für den ssl.key übereinstimmt. Andernfalls kommt es zu nicht nachvollziehbaren Problemen.

Für den Zugriff auf das Client-Zertifikat, für die Verbindung zum OpenSearch (mTLS intern (:9200) und mTLS intern (:9203)), sind weitere Konfigurationsparameter in der Datei karaf/etc/de.virtimo.bpc.core.cfg (siehe auch BPC Konfigurationsdatei) vorhanden.

Ausschnitt der Keystore Konfiguration aus karaf/etc/de.virtimo.bpc.core.cfg
de.virtimo.bpc.core.opensearch.privatekey.alias = opensearch_bpc
de.virtimo.bpc.core.opensearch.privatekey.password = virtimo

Keystore Konfiguration in OpenSearch

In der opensearch/config/opensearch.yml wird der Keystore über folgende Einstellungen referenziert:

Ausschnitt der Keystore Konfiguration aus opensearch/config/opensearch.yml für mTLS intern (:9200) und mTLS intern (:9203)
plugins.security.ssl.http.keystore_filepath: virtimo/ssl/virtimo_keystore.jks
plugins.security.ssl.http.keystore_password: virtimo
plugins.security.ssl.http.keystore_alias: opensearch_node
plugins.security.ssl.http.keystore_type: jks
plugins.security.ssl.http.keystore_keypassword: virtimo
Ausschnitt der Keystore Konfiguration aus opensearch/config/opensearch.yml für mTLS intern (:9300)
plugins.security.ssl.transport.keystore_filepath: virtimo/ssl/virtimo_keystore.jks
plugins.security.ssl.transport.keystore_password: virtimo
plugins.security.ssl.transport.keystore_alias: opensearch_node
plugins.security.ssl.transport.keystore_type: jks
plugins.security.ssl.transport.keystore_keypassword: virtimo

Weitere Informationen sind in der offiziellen OpenSearch Dokumentation zu finden.

Truststore virtimo_truststore.jks

Das Standardpasswort für den Truststore virtimo_truststore.jks ist virtimo.

Folgende Keys/Zertifikate befinden sich im Truststore virtimo_truststore.jks.

Alias

Passwort

Verwendungszweck

root-ca

virtimo

Server-Zertifikat für externe Verbindungen (TLS extern (:8080))

Ist das vertrauenswürdige Root-Zertifikat, mit dem die anderen Zertifikate signiert wurden. Es wird zur Ausführung der OpenSearch Security Tools wie dem securityadmin.sh benötigt (siehe OpenSearch) sowie beim OpenSearch Cluster.

Truststore Konfiguration in Karaf

In der karaf/etc/org.ops4j.pax.web.cfg wird der Truststore über folgende Einstellungen referenziert:

Ausschnitt der Truststore Konfiguration aus karaf/etc/org.ops4j.pax.web.cfg
org.ops4j.pax.web.ssl.truststore = ${karaf.etc}/virtimo/ssl/virtimo_truststore.jks
org.ops4j.pax.web.ssl.truststore.password = virtimo
org.ops4j.pax.web.ssl.truststore.type = JKS

Truststore Konfiguration in OpenSearch

In der opensearch/config/opensearch.yml wird der Truststore über folgende Einstellungen referenziert:

Ausschnitt der Truststore Konfiguration aus opensearch/config/opensearch.yml
# mTLS intern (:9200) / mTLS intern (:9203)
plugins.security.ssl.http.truststore_filepath: virtimo/ssl/virtimo_truststore.jks
plugins.security.ssl.http.truststore_password: virtimo
plugins.security.ssl.http.truststore_type: jks
# not set means all certificates in the truststore are trusted
# plugins.security.ssl.http.truststore_alias

# mTLS intern (:9300)
plugins.security.ssl.transport.truststore_filepath: virtimo/ssl/virtimo_truststore.jks
plugins.security.ssl.transport.truststore_password: virtimo
plugins.security.ssl.transport.truststore_type: jks
# not set means all certificates in the truststore are trusted
# plugins.security.ssl.transport.truststore_alias

Weitere Informationen sind in der offiziellen OpenSearch Dokumentation zu finden.

Aliase

Wenn Sie andere Aliase nutzen wollen, als sie im Auslieferungszustand genutzt werden (siehe Keystore Aliase und Truststore Aliase), beachten Sie unbedingt auch die entsprechenden Alias-Konfigurationen in OpenSearch (Truststore, Keystore) und Karaf (Truststore, Keystore).

Aliase im Truststore sind in der Regel nicht relevant, da alle Zertifikate als Vertrauenswürdig gelten. Im OpenSearch kann man dies jedoch auch auf einen Alias eingrenzen (Truststore Konfiguration in OpenSearch). Im Auslieferungszustand wird allen Zertifikaten im Truststore vertraut.

Eingehende Verbindungen mit eigenem Zertifikat absichern

Der Zugriff auf das BPC geht über die Systemkomponente Karaf und erfolgt auf dem Port 8282 (siehe auch Netzwerk). Diese sind im Diagramm(Übersicht der BPC Netzwerkverbindungen) als TLS extern (:8282) deklariert.

Netzwerk eingehende Verbindungen
Illustration 3. Netzwerk eingehende Verbindungen

Um ein eigenes Zertifikat zu hinterlegen, muss der default Keystore (Keystore virtimo_keystore.jks) angepasst oder ersetzt werden.

Sie benötigen:

  • TLS-Zertifikat unterschrieben vom Root-Zertifikat

Sie müssen folgende Punkte anpassen:

  • Fügen sie dem Keystore virtimo_keystore.jks im Karaf das TLS-Zertifikat hinzu

  • Konfigurieren Sie in der karaf/etc/org.ops4j.pax.web.cfg den Alias und das Passwort des TLS-Zertifikats.

    Ausschnitt der TLS-Zertifikats Konfiguration aus karaf/etc/org.ops4j.pax.web.cfg
    # TLS Keys
org.ops4j.pax.web.ssl.key.alias = karaf
org.ops4j.pax.web.ssl.key.password = virtimo

  • Starten Sie Karaf neu

Damit die Verbindung TLS extern (:8282) korrekt funktioniert, müssen alle Systeme die eine Verbindung aufbauen (Browser, Server, etc.) dem Root-Zertifikat vertrauen.

Sollten Sie den Keystore ersetzen, dann müssen Sie zusätzlich das Client-Zertifikat (Default Alias opensearch_bpc) hinzufügen. Siehe dazu auch Interne Verbindungen mit eigenem Zertifikat absichern.

Es ist zwingend erforderlich, dass das Keystore Passwort (org.ops4j.pax.web.ssl.keystore.password) mit dem Password des enthaltenen Zertifikats(org.ops4j.pax.web.ssl.key.alias) übereinstimmt. Andernfalls kommt es zu nicht nachvollziehbaren Problemen.

Achten Sie darauf, dass der HTTP Port (Default 8181) abgeschaltet wird, sobald die HTTPS Verbindung eingerichtet wurde. Siehe Netzwerk

Interne Verbindungen mit eigenem Zertifikat absichern

Für den Betrieb des BPC baut der Karaf eine gesicherte Verbindung zu OpenSearch (mTLS intern (:9200)) und eine Websocket Verbindung zum BPC OpenSearch Plugin (mTLS intern (:9203)) auf.

Sollten Sie das BPC im Cluster betreiben, dann bauen die OpenSearch Knoten ebenfalls Verbindungen untereinander auf (mTLS intern (:9300)).

Bei den internen Verbindungen kommt Mutual TLS authentication (mTLS) zum Einsatz. Das bedeutet, dass hier zusätzlich der Client, der die Verbindung aufbaut, ein Zertifikat zur Authentifizierung benötigt und der Server ein Zertifikat zur Verifikation des Client-Zertifikates. Das Client-Zertifikat wird im Keystore virtimo_keystore.jks hinterlegt. Das Zertifikat zum Verifizieren wird im Truststore virtimo_truststore.jks hinterlegt. Die betrifft Karaf bei der Verbindung zum OpenSearch (mTLS intern (:9200) und mTLS intern (:9203)) und OpenSearch bei der Verbindung mit anderen OpenSearch Knoten (mTLS intern (:9300)).

Netzwerk interne Verbindungen
Illustration 4. Netzwerk interne Verbindungen

Es gibt einiges zu beachten, wenn Sie die bestehenden Zertifikate durch eigene Zertifikate ersetzen wollen. Da mTLS zum Einsatz kommt, benötigen sie zum einen das Client-Zertifikat (siehe Zertifikate für mTLS Authentifizierung mit OpenSearch) und ein Zertifikat, mit dem das Client-Zertifikat verifiziert werden kann. Dies ist in der Regel direkt von der root CA (Certificate Authority) ausgestellt.

Sie benötigen:

  • Root-Zertifikat zum Validieren ausgestellter Zertifikate

  • Client-Zertifikat unterschrieben vom Root-Zertifikat

  • TLS-Zertifikat unterschrieben vom Root-Zertifikat

Sie müssen folgende Punkte anpassen:

  • Fügen sie dem Keystore virtimo_keystore.jks im Karaf das Client-Zertifikat hinzu

  • Fügen sie dem Keystore virtimo_keystore.jks im OpenSearch das TLS-Zertifikat hinzu

  • Fügen Sie im Truststore virtimo_truststore.jks von OpenSearch und Karaf das Root-Zertifikat zum Verifizieren des Client-Zertifikates hinzu.

  • Konfigurieren Sie in der Datei karaf/etc/de.virtimo.bpc.core.cfg den entsprechenden Alias und das zugehörige Passwort des hinzugefügten Client-Zertifikates (siehe auch BPC Konfigurationsdatei)

    Ausschnitt der Keystore Konfiguration aus karaf/etc/de.virtimo.bpc.core.cfg
    de.virtimo.bpc.core.opensearch.privatekey.alias = opensearch_bpc
de.virtimo.bpc.core.opensearch.privatekey.password = virtimo

  • Konfigurieren Sie in der Datei opensearch/config/opensearch.yml den entsprechenden Alias und das zugehörige Passwort des hinzugefügten TLS-Zertifikates.

    Ausschnitt der Keystore Konfiguration aus opensearch/config/opensearch.yml für mTLS intern (:9200) und mTLS intern (:9203)
    plugins.security.ssl.http.keystore_filepath: virtimo/ssl/virtimo_keystore.jks
plugins.security.ssl.http.keystore_password: virtimo
plugins.security.ssl.http.keystore_alias: opensearch_node
plugins.security.ssl.http.keystore_type: jks
plugins.security.ssl.http.keystore_keypassword: virtimo

  • Starten Sie Karaf und OpenSearch neu.

Sollten Sie ein OpenSearch Cluster verwenden, sollten Sie auch die Verbindung zwischen den Cluster Nodes (mTLS inter (:9300)) absichern. Wir gehen im folgenden davon aus, dass das gleiche Root-Zertifikat zum Einsatz kommt.

Sie benötigen:

  • Client-Zertifikat unterschrieben vom Root-Zertifikat

Sie müssen folgende Punkte anpassen:

  • Fügen sie dem Keystore virtimo_keystore.jks im OpenSearch das Client-Zertifikat hinzu

  • Konfigurieren Sie in der Datei opensearch/config/opensearch.yml den entsprechenden Alias und das zugehörige Passwort des hinzugefügten Client-Zertifikates.

    Ausschnitt der Keystore Konfiguration aus opensearch/config/opensearch.yml für mTLS intern (:9300)
    plugins.security.ssl.transport.keystore_filepath: virtimo/ssl/virtimo_keystore.jks
plugins.security.ssl.transport.keystore_password: virtimo
plugins.security.ssl.transport.keystore_alias: opensearch_node
plugins.security.ssl.transport.keystore_type: jks
plugins.security.ssl.transport.keystore_keypassword: virtimo

  • Starten Sie Karaf und OpenSearch neu.

Achten Sie immer auf die korrekte Angabe der verwendeten Aliase und Passwörter.

Zertifikate für mTLS Authentifizierung mit OpenSearch

In dem Zertifikateintrag steckt auch der Name des Benutzers drin, welcher auf OpenSearch zugreift.

Der Wert im Feld Antragsteller ist z.B. für das Zertifikat mit dem Alias opensearch_bpc auf CN=bpc,OU=client,O=Virtimo AG,L=Berlin,C=DE gesetzt. Dabei wird vom OpenSearch Security Plugin der CN-Wert (bpc) als Benutzer für die Zugriffe verwendet.

Der Benutzer bpc findet sich dementsprechend auch in OpenSearch wieder. In der Konfigurationsdatei opensearch/config/opensearch-security/roles_mapping.yml ist der Benutzer bpc der Rolle all_access zugeordnet.

Weitere Informationen finden Sie auch in der offiziellen OpenSearch Dokumentation.

Das OpenSearch Security Plugin stellt die Funktionalitäten zur Verfügung. Die umfangreichen Konfigurationsmöglichkeiten sind in der OpenSearch Security Dokumention nachzulesen.

Temporäres aktivieren von HTTP zwischen Karaf und OpenSearch

Um andere Probleme auszuschliessen, kann die Verbindung temporär wieder auf HTTP umgestellt werden. Hier die notwendigen Schritte für OpenSearch und Karaf. Nach den Anpassungen müssen beide Systeme neu gestartet werden.

  1. In der opensearch/config/opensearch.yml das OpenSearch Security Plugin deaktivieren (die Einstellung gibt es bereits in der Datei).

    opensearch/config/opensearch.yml
    plugins.security.disabled: true

  2. In der karaf/etc/de.virtimo.bpc.core.cfg das OpenSearch Schema von https zu http ändern.

    karaf/etc/de.virtimo.bpc.core.cfg
    de.virtimo.bpc.core.opensearch.scheme = http

Diese Einstellung sollte nur temporär zu Testzwecken genutzt werden. Die OpenSearch REST API biete in diesem Zustand uneingeschränkt administrativen Zugang für alle Aufrufer.

Zugriff auf OpenSearch per HTTPS testen

Wie Sie einen direkten Zugriff durchführen und damit Ihre Konfiguration testen können, ist auf der Seite OpenSearch beschrieben.

Passwörter Maskieren

Sie können die Passwörter für org.ops4j.pax.web.ssl.keystore.password und auch org.ops4j.pax.web.ssl.key.password auch als "obfuscated" Zeichenkette angeben. Dies hat den Vorteil, dass das Passwort nicht im Klartext vorliegt.

Um eine maskierte Form eines Passwortes zu erhalten, können Sie folgendes ausführen:

Beispiel: Verschleierung des Passwortes password
> java -cp INSTALLATIONSVERZEICHNIS/karaf/system/org/eclipse/jetty/jetty-util/9.4.22.v20191022/jetty-util-9.4.22.v20191022.jar org.eclipse.jetty.util.security.Password "password"

password
OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v
MD5:5f4dcc3b5aa765d61d8327deb882cf99

In dem Beispiel kann OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v synonym für password in die Konfiguration eingesetzt werden.

Es kann sein, dass die Jetty Versionsnummer in Ihrer Installation abweicht. Diese können Sie auf der Karaf-Konsole wie folgt in Erfahrung bringen:

feature:list | grep jetty

Es handelt sich nur um eine Verschleierung/Maskierung des Passworts, es handelt sich nicht um eine Verschlüsselung.

Secure Flag für Cookies aktivieren

Für den BPC Session Cookie kann das Secure Flag gesetzt werden. Wenn dies aktiv ist, schickt der Browser den Session-Cookie nur über gesicherte Verbindungen zum Server. Dies erhöht die Sicherheit und verhindert das mitlesen des Session-Cookies im Netzwerk. Zum Aktivieren des Secure Flags setzen Sie in der Datei karaf/etc/de.virtimo.bpc.core.cfg bitte folgenden Wert:

de.virtimo.bpc.core.cookieSecure = true

Sollte das BPC nicht über eine gesicherte Verbindung bereitgestellt werden, dann darf diese Option nicht aktiviert werden. Ansonsten kann sich der Client nach der Anmeldung nicht authentifizieren.
Keywords:
Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen