Secure connection (TLS/HTTPS)

For secure operation of the BPC, only secure connections should be used if possible.

Knowledge of TLS in general and the configuration of Java-based applications with Truststore and Keystore is required for correct configuration.

HTTPS (Port 9200) has been used by default for communication with OpenSearch since BPC 4.1.9 or 4.2.0.

For the general network configuration of the BPC, please refer to Network.

In productive environments, at least the incoming connections should be secured by a separate certificate. This is described in the section Eingehende Verbindungen mit eigenem Zertifikat absichern.

Overview of the BPC network connections

These graphics show the network connections for the BPC in single node and cluster operation.

The network Ports used are always indicated after the colon on the connections. For example, the Port 8282 is addressed at TLS extern (:8282).

Network Ports can also be configured differently. See Network.
Overview of the network structure Single Node
Illustration 1. Overview of the network structure Single Node
Overview of the network structure Cluster
Illustration 2. Overview of the network structure Cluster

The network connections can be divided into external or incoming connections (see Eingehende Verbindungen mit eigenem Zertifikat absichern) and internal connections (Interne Verbindungen mit eigenem Zertifikat absichern). These can be configured separately.

General information on network configuration can be found at Network.

Keystores and truststores

Keystores and truststores are important files for the configuration of TLS.

The keystores contain non-public certificates (private key). These are used either as a server certificate to offer TLS/HTTPS connections or as a client certificate to authenticate against the server when using Mutual TLS authentication (mTLS). These certificates are sensitive information. They are therefore usually protected by passwords.

The trust stores contain public certificates (public key). This makes it possible to ensure the authenticity of the server when establishing a secure connection to a server. When using mTLS, the authenticity of the client that establishes the connection can be verified.

These two files are used in Karaf as well as in OpenSearch to secure various connections.

The command line tools openssl and keytool can be used to create certificates and work with the keystore/truststore files. This is much more convenient with the KeyStore Explorer.

Centralizing keystore and truststore files

It is recommended to store the keystore and truststore files outside of Karaf and OpenSearch in a central location. This makes future updates easier, as OpenSearch and Karaf can be updated without having to repeat the configuration of TLS.

Default location Karaf

INSTALLATIONSVERZEICHNIS/karaf/etc/virtimo/ssl

Default location OpenSearch

OPENSEARCH_CONFIG_VERZEICHNIS/virtimo/ssl

Recommended new location

INSTALLATIONSVERZEICHNIS/ssl

The bpc.env must be adapted so that Karaf finds the files and a suitable link is created for OpenSearch. The link for OpenSearch is unfortunately necessary as the process is not allowed to access files outside its folder.

  • Unix systems

  • Windows systems

bpc.env.sh
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 anlegen
cd OPENSEARCH_CONFIG_VERZEICHNIS/virtimo
ln -s ../../ssl ssl
bpc.env.cmd
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 anlegen
rmdir /s OPENSEARCH_CONFIG_VERZEICHNIS\virtimo\ssl
mklink /J OPENSEARCH_CONFIG_VERZEICHNIS\virtimo\ssl ssl

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

Please note that with this configuration OpenSearch and Karaf use the same keystore and truststore files. This means that all necessary certificates with the appropriate aliases that are required for both system components must be stored in these files.

Java truststore cacerts

Every Java installation contains a default truststore with the file name cacerts. This truststore contains all root CAs that the distributor of the Java installation considers relevant. Theoretically, all public certificates can also be stored there. However, we advise against this, as Java itself must also be updated regularly. In this case, the cacerts file from the old installation would have to be transferred or the new cacerts adapted. This is a potential risk of error and unnecessary effort.

Delivery state

The BPC is already equipped with preconfigured keystores (virtimo_keystore.jks) and truststores (virtimo_truststore.jks) in the delivery state. These contain self-signed certificates and are stored in OpenSearch (OPENSEARCH_CONFIG_VERZEICHNIS/virtimo/ssl) and Karaf (karaf/etc/virtimo/ssl). The files are identical in both folders, even if this is not absolutely necessary.

Script with which the default keystore and truststore were created 
#!/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

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

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

The default password for the keystore virtimo_keystore.jks is virtimo.

The following keys/certificates are in the keystore virtimo_keystore.jks.

Alias Password Purpose

karaf

virtimo

Server certificate for external connections (TLS extern (:8080))

opensearch_bpc

virtimo

Client certificate for the Karaf → OpenSearch connection (mTLS intern (:9200) and mTLS intern (:9203)).

See also Zertifikate für mTLS Authentifizierung mit OpenSearch.

opensearch_node

virtimo

Client certificate for the connection OpenSearch → OpenSearch (mTLS intern (:9300))

Keystore configuration in Karaf

In karaf/etc/org.ops4j.pax.web.cfg the keystore is referenced via the following settings.

Section of the keystore configuration from 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

The certificate required for TLS/HTTPS (TLS extern (:8282)) is also defined here.

Section of the TLS certificate configuration from 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

The setting org.ops4j.pax.web.ssl.key.alias was not set in earlier versions and is now mandatory.

For Karaf it is mandatory that the keystore password and the password for the ssl.key match. Otherwise there will be untraceable problems.

For access to the client certificate, for the connection to OpenSearch (mTLS intern (:9200) and mTLS intern (:9203)), further configuration parameters are available in the file karaf/etc/de.virtimo.bpc.core.cfg (see also BPC configuration file).

Section of the keystore configuration from 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 configuration in OpenSearch

In OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml, the keystore is referenced via the following settings:

Excerpt of the keystore configuration from OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml for mTLS intern (:9200) and 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
Excerpt of the keystore configuration from OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml for 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

Further information can be found in the official OpenSearch documentation.

Truststore virtimo_truststore.jks

The default password for the truststore virtimo_truststore.jks is virtimo.

The following keys/certificates are located in the truststore virtimo_truststore.jks.

Alias

Password

Purpose

root-ca

virtimo

Server certificate for external connections (TLS extern (:8080))

Is the trusted root certificate with which the other certificates were signed. It is required to run the OpenSearch security tools such as securityadmin.sh (see OpenSearch) and for the OpenSearch Cluster.

Truststore configuration in Karaf

In karaf/etc/org.ops4j.pax.web.cfg the truststore is referenced via the following settings:

Excerpt of the truststore configuration from 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 configuration in OpenSearch

In OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml, the truststore is referenced via the following settings:

Excerpt of the truststore configuration from OPENSEARCH_CONFIG_VERZEICHNIS/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 internal (: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 Delivery state 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 configuration in OpenSearch). Im Delivery state 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 Network). Diese sind im Diagramm(Overview of the BPC network connections) 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.

    Section of the TLS certificate configuration from 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 Network

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 configuration file)

    Section of the keystore configuration from 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_VERZEICHNIS/opensearch.yml den entsprechenden Alias und das zugehörige Passwort des hinzugefügten TLS-Zertifikates.

    Excerpt of the keystore configuration from OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml for mTLS intern (:9200) and 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_VERZEICHNIS/opensearch.yml den entsprechenden Alias und das zugehörige Passwort des hinzugefügten Client-Zertifikates.

    Excerpt of the keystore configuration from OPENSEARCH_CONFIG_VERZEICHNIS/opensearch.yml for 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_VERZEICHNIS/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_VERZEICHNIS/opensearch.yml das OpenSearch Security Plugin deaktivieren (die Einstellung gibt es bereits in der Datei).

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

  2. In der zentralen Konfigurationsdatei müssen Sie bei den OpenSearch-Hosts das Schema von https zu http ändern (Die Zeile sollte schon mit https vorhanden sein):

    bpc.env.sh
    export DE_VIRTIMO_BPC_CORE_DE_VIRTIMO_BPC_CORE_OPENSEARCH_HOSTS="http://localhost:$DE_VIRTIMO_BPC_CORE_DE_VIRTIMO_BPC_CORE_OPENSEARCH_PORT"
    bzw. bpc.env.cmd
    SET DE_VIRTIMO_BPC_CORE_DE_VIRTIMO_BPC_CORE_OPENSEARCH_HOSTS=https://localhost:%DE_VIRTIMO_BPC_CORE_DE_VIRTIMO_BPC_CORE_OPENSEARCH_PORT%

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 the example, OBF:1v2j1uum1xtv1zej1zer1xtn1uvk1v1v can be used as a synonym for password in the configuration.

It is possible that the Jetty version number in your installation is different. You can find this out on the Karaf console as follows:

feature:list | grep jetty

This is only an obfuscation/masking of the password, it is not an encryption.

Activate secure flag for cookies

The secure flag can be set for the BPC session cookie. If this is active, the browser only sends the session cookie to the server via secure connections. This increases security and prevents the session cookie from being read on the network. To activate the secure flag, please set the following value in the karaf/etc/de.virtimo.bpc.core.cfg file:

de.virtimo.bpc.core.cookieSecure = true

If the BPC is not provided via a secure connection, this option must not be activated. Otherwise, the client cannot authenticate itself after logging in.
Keywords:
Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen