Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Cassandra-natives mTLS konfigurieren

Einführung

Verschiedene Komponenten von Edge for Private Cloud wie Message Processor, Verwaltungsserver und Router stellen standardmäßig eine Verbindung über einen Klartextkanal zu Cassandra-Knoten her. Auf solchen Kanälen werden Daten zu und von Cassandra im Klartext übertragen. Apigee mTLS ist ein auf Consul Service Mesh basierendes Feature, das die Sicherheit der Kommunikation zwischen Komponenten im Edge for Private Cloud-Cluster erhöht. Dieses Angebot von Apigee fügt dem Kommunikationskanal zwischen Clientkomponenten und Cassandra auch TLS-Sicherheit hinzu.

Dieser Artikel behandelt ein neues alternatives Angebot von Apigee, bei dem die Kommunikation zwischen Clientkomponenten und Cassandra in Edge for Private Cloud über gegenseitiges TLS (auch 2-Wege-TLS genannt) gesichert wird. Dabei werden Funktionen verwendet, die in Cassandra nativ verfügbar sind, ohne dass ein externes Service Mesh erforderlich ist.

Natives mTLS-Feature

Die Aktivierung von mTLS zwischen Cassandra und Clientkomponenten, die in diesem Artikel beschrieben wird, basiert auf TLS-Funktionen, die von Apache Cassandra nativ bereitgestellt werden. Wenn diese Funktion aktiviert ist, führen Clientverbindungen zu Cassandra (auf dem nativen CQL-Transportport 9042) einen 2-Wege-TLS-Handshake mit Clients durch, bevor Verbindungen hergestellt werden können. Für diese 2-Wege-TLS-Verbindung fungiert Cassandra als Server und verschiedene Clients, die eine Verbindung zu Cassandra herstellen (z. B. Edge-Message-Processor, das cqlsh-Tool usw.), fungieren als Clients.

Für 2-Wege-TLS (oder gegenseitiges TLS oder mTLS) müssen sowohl Cassandra als auch die Clients mit einem eigenen Schlüsselspeicher eingerichtet werden. Der Schlüsselspeicher jedes Cassandra-Knotens sollte einen eigenen Schlüssel und ein eigenes Zertifikat enthalten. Der Schlüsselspeicher jeder Clientanwendung sollte den Schlüssel und das Zertifikat dieses bestimmten Clients enthalten. Sowohl in Cassandra als auch auf den Clients sollte ein Truststore mit den Zertifikaten und der zugehörigen Kette des Gegenparts hinzugefügt werden. Der Truststore jedes Cassandra-Knotens sollte Zertifikate von Clients enthalten und der Truststore jedes Clients sollte Zertifikate aller Cassandra-Knoten enthalten. Weitere Informationen zur Funktionsweise eines 2-Wege-TLS-Handshakes finden Sie im Apigee-Artikel Zwei-Wege-TLS/SSL.

Zertifikatsverkettung

Im Allgemeinen können Serverzertifikate, Clientzertifikate, Zertifikatsketten, Schlüsselspeicher und Truststores auf verschiedene Arten erstellt werden. Das gilt auch für natives mTLS für Cassandra und Clients. Unter Berücksichtigung der typischen Funktionsweise von Edge for Private Cloud-Clustern in Unternehmen und der Anzahl der eindeutigen Client-zu-Cassandra-Verbindungspaare, die hergestellt werden können, empfiehlt Apigee den folgenden allgemeinen Ansatz zum Konfigurieren von Schlüsseln und Zertifikaten für diese Funktion. Es gibt auch andere praktikable Methoden, aber die folgende Methode bietet wahrscheinlich ein gutes Gleichgewicht zwischen Sicherheit und Wartungsaufwand.

Beschaffen Sie ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatspaar, das vom Root-Zertifikat signiert wurde. Möglicherweise haben Sie bereits solche Schlüssel und Zertifikate. Andernfalls können Sie selbst signierte Root- und Zwischenzertifikate und ‑schlüssel erstellen. Die Schritte dazu finden Sie in Anhang 1.
Verwenden Sie den gemeinsamen Zwischenschlüssel und das gemeinsame Zwischenzertifikat von oben, um alle anwendungsspezifischen (Blatt-)Schlüssel und ‑Zertifikate zu signieren.

Wenn ein gemeinsamer Zwischenschlüssel und ein gemeinsames Zwischenzertifikat für einen Cluster verwendet werden, wird auf jedem Cassandra- und Clientknoten ein gemeinsamer Truststore konfiguriert, der dieselbe Root- und Zwischenzertifikatskette enthält. Jeder Cassandra-Knoten und jede Clientanwendung erhält einen eigenen eindeutigen Blattschlüssel und ein eigenes eindeutiges Blattzertifikat, die mit dem gemeinsamen Zwischenschlüssel und dem gemeinsamen Zwischenzertifikat signiert wurden.

Das Rotieren eines Blattzertifikats eines Cassandra-Knotens oder einer Clientanwendung ist einfach.
Das Rotieren eines Zwischen- oder Root-Zertifikats ist immer noch ein ziemlich komplexer Vorgang, aber die Häufigkeit solcher Rotationen ist viel geringer als die von untergeordneten Zertifikaten.

Entscheiden Sie anhand der Sicherheitspraktiken Ihres Unternehmens, ob Sie gemeinsame Root- und Zwischenzertifikate für verschiedene Private Cloud-Cluster verwenden möchten. In Anhang 2 finden Sie alternative Zertifikatskonfigurationen.

Die restlichen Schritte in diesem Artikel enthalten Details zur oben beschriebenen Methode zum Entwerfen von Schlüsseln und Zertifikaten.

Einschränkungen und Vorbehalte

Für diese Funktion gelten die folgenden Einschränkungen.

Dieses Angebot für natives mTLS zwischen Clientkomponenten und Cassandra ist NICHT mit apigee-mtls kompatibel. Wenn Sie diese Funktion verwenden, können Sie apigee-mtls nicht verwenden und umgekehrt.
Die Aktivierung von mTLS zwischen Clientkomponenten und Cassandra wirkt sich auf die Leistung der Verbindungen zwischen Clients und Cassandra aus. Vorgänge wie das Hochfahren von Clients oder das Skalieren von Cassandra-Verbindungen können langsamer sein, da Cassandra und Clients zuerst TLS aushandeln müssen, bevor sie mit der Kommunikation beginnen können. Die Auswirkungen sollten gering sein und in der Regel nicht bemerkbar sein.
In Cassandra kann mTLS optional für eingehende Clientverbindungen erzwungen werden. Die Erzwingung kann aktiviert werden, muss aber bei betrieblichen Aufgaben wie Upgrades der Apigee-Software, Aktivieren/Deaktivieren von TLS-Funktionen und bestimmten Arten von Zertifikatsrotationen deaktiviert werden. Weitere Informationen finden Sie im Abschnitt Vorgänge und Konfigurationen.
Der Kunde ist für die Verwaltung und Wartung von Zertifikaten verantwortlich.
Das Rotieren von Zertifikaten hat verschiedene Nuancen. Weitere Informationen finden Sie im Abschnitt Zertifikatsrotationen.

Natives mTLS aktivieren

Die Aktivierung von nativem mTLS ist ein dreistufiger Vorgang, wie unten beschrieben:

Beschaffen Sie ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatspaar.
Erstellen Sie ein Blattschlüssel-/Zertifikatspaar für einen Cassandra-Knoten, signieren Sie es, speichern Sie es in einem Schlüsselspeicher und konfigurieren Sie Cassandra für optionales mTLS. Wiederholen Sie die Schritte für jeden Cassandra-Knoten einzeln.
Erstellen Sie ein Blattschlüssel-/Zertifikatspaar für eine Clientanwendung, signieren Sie es, speichern Sie es in einem Schlüsselspeicher und konfigurieren Sie die Clientanwendung für mTLS. Wiederholen Sie die Schritte für jede Clientanwendung einzeln. Clientanwendungen:
1. edge-management-server
2. edge-message-processor
3. edge-router

Diese Schritte werden unten beschrieben:

Root- und Zwischenzertifikate beschaffen

Beschaffen Sie ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatspaar, das vom Root-Zertifikat signiert wurde. Verwenden Sie das von der Zertifizierungsstelle Ihres Unternehmens signierte Root- und Zwischenzertifikat oder erstellen Sie selbst signierte Zertifikate. Speichern Sie die Root- und Zwischenzertifikatskette in einem Truststore. In Anhang 1 finden Sie hilfreiche Befehle. Bei den nachfolgenden Befehlen wird davon ausgegangen, dass Sie Zugriff auf die folgenden Dateien haben:

intermediate.key : Schlüsseldatei für das Zwischenzertifikat zum Signieren von untergeordneten Zertifikaten
intermediate-cert.pem : Zwischenzertifikat

Cassandra-Knoten konfigurieren

Wählen Sie einen Cassandra-Knoten aus.

Generieren Sie ein Blattschlüssel-/Zertifikatspaar und signieren Sie es mit dem Zwischenzertifikat. Speichern Sie den Schlüssel und das signierte Zertifikat in einem Schlüsselspeicher. Beispiel:


# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

Platzieren Sie die Schlüsselspeicher- und Truststore-Dateien an einem bestimmten Ort auf dem Knoten und sorgen Sie dafür, dass sie für den Apigee-Nutzer zugänglich sind.

cp cass-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie dieser Datei den folgenden Inhalt hinzu:

### Enable Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=true

### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

### Keystore details
conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
conf_cassandra_client_encryption_keystore_password=keystorepass
conf_cassandra_server_encryption_store_type=PKCS12

### Whether to enable 2-way TLS (or mTLS) - true or false
conf_cassandra_client_encryption_require_client_auth=true

### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_client_encryption_truststore_password=trustpass
conf_cassandra_client_encryption_store_type=PKCS12

Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann:

chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

Konfigurieren Sie den Cassandra-Knoten und starten Sie ihn neu.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Wiederholen Sie die oben genannten Schritte für jeden Cassandra-Knoten einzeln.

Clientanwendungen konfigurieren

Dieser Abschnitt gilt für die folgenden Clientkomponenten, die eine Verbindung zu Cassandra herstellen:

edge-management-server
edge-message-processor
edge-router

Wählen Sie eine Clientkomponente aus.

Generieren Sie ein Blattschlüssel-/Zertifikatspaar und signieren Sie es mit dem Zwischenzertifikat. Speichern Sie den Schlüssel und das signierte Zertifikat in einem Schlüsselspeicher. Beispiel:


# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass

Platzieren Sie die Schlüsselspeicher- und Truststore-Dateien an einem bestimmten Ort auf dem Knoten und sorgen Sie dafür, dass sie für den Apigee-Nutzer zugänglich sind.

cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

Erstellen und bearbeiten Sie die Konfigurationsdatei basierend auf der Anwendung, die Sie konfigurieren.

Anwendung	Konfigurationsdatei
Verwaltungsserver	`/opt/apigee/customer/application/management-server.properties`
Verwaltungsprozessor	`/opt/apigee/customer/application/message-processor.properties`
Router	`/opt/apigee/customer/application/router.properties`

Fügen Sie der Datei die folgenden Konfigurationen hinzu:

### Enable TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=true
conf_cassandra_sslconfig.enable.mtls=true

### Keystore Details
conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
conf_cassandra_sslconfig.keystore.password=keystorepass
conf_cassandra_sslconfig.keystore.type=PKCS12

### Truststore Details
conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_sslconfig.truststore.password=trustpass
conf_cassandra_sslconfig.truststore.type=PKCS12

Achten Sie darauf, dass die Konfigurationsdatei dem Apigee-Nutzer gehört und von ihm gelesen werden kann.

chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

Starten Sie die Clientanwendung neu.

# Configure and restart service:
apigee-service component configure
apigee-service component restart
# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart

Sie können prüfen, ob SSL in der Clientanwendung korrekt konfiguriert wurde, indem Sie im Systemprotokoll der entsprechenden Anwendung nach Protokollen suchen, die den folgenden Zeilen ähneln:
SSL-Optionen zur Cassandra-Verbindung hinzugefügt
Wiederholen Sie die oben genannten Schritte für jede Clientanwendung einzeln.

Vorgänge und Konfigurationen

mTLS erzwingen

Wenn mTLS in Cassandra nicht erzwungen wird, akzeptiert Cassandra entweder Klartextverbindungen von Clients oder Clients, mit denen ein 2-Wege-TLS-Handshake erfolgreich durchgeführt werden kann. Damit die mTLS-Erzwingung funktioniert, muss mTLS zuerst in Cassandra konfiguriert werden. Sie können die mTLS-Erzwingung in Cassandra mit den folgenden Schritten festlegen:

Wählen Sie einen Cassandra-Knoten aus.
Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie dieser Datei die folgende Property hinzu oder bearbeiten Sie sie:
```
### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false
```
Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Konfigurieren Sie den Cassandra-Knoten und starten Sie ihn neu.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Wiederholen Sie die oben genannten Schritte für jeden Cassandra-Knoten einzeln.

Sobald mTLS in Cassandra erzwungen wird, kann das Standard-Cassandra-Abfragetool cqlsh keine direkte Verbindung zu Cassandra herstellen. Um cqlsh für SSL zu konfigurieren, generieren Sie einen neuen Blattschlüssel und ein neues Blattzertifikat (ähnlich dem Blattschlüssel und dem Blattzertifikat für Clientanwendungen) und gehen Sie so vor:

Erstellen oder bearbeiten Sie die Datei $HOME/.cassandra/cqlshrc.
Fügen Sie der Datei den folgenden Inhalt hinzu:
```
[ssl]
certfile = /home/admin-user/certs/inter-root.pem
validate = false
userkey = /home/admin-user/certs/cqlsh1.key
usercert = /home/admin-user/certs/cqlsh1-cert.pem
```
- certfile : Zertifikatsdatei mit der Root- und Zwischenzertifikatskette
- userkey : Clientschlüssel, der von cqlsh verwendet werden soll. Dies sollte ein Blattschlüssel-/Zertifikatspaar sein, das Sie mit dem Zwischenzertifikat generieren und signieren können.
- usercert : Clientzertifikat, das von cqlsh verwendet werden soll. Dies sollte ein Blattschlüssel-/Zertifikatspaar sein, das Sie mit dem Zwischenzertifikat generieren und signieren können.

Führen Sie den Befehl cqlsh wie gewohnt aus und geben Sie das Argument --ssl an. Beispiel:

$  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
Connected to Apigee at X.X.X.X:9042
[cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

Erzwingung von mTLS in Cassandra deaktivieren

So deaktivieren Sie die mTLS-Erzwingung in Cassandra:

Wählen Sie einen Cassandra-Knoten aus.
Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie dieser Datei die folgende Property hinzu oder bearbeiten Sie sie:
```
### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true
```
Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Konfigurieren Sie den Cassandra-Knoten und starten Sie ihn neu.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Wiederholen Sie die oben genannten Schritte für jeden Cassandra-Knoten einzeln.

Natives mTLS deaktivieren

Das Deaktivieren von nativem mTLS ist ein mehrstufiger Prozess, ähnlich dem Aktivieren von nativem mTLS. Die Schritte im Überblick:

Erzwingung von mTLS in Cassandra deaktivieren (falls erzwungen)

Deaktivieren Sie mTLS auf allen Knoten der folgenden Clientanwendungen einzeln:

edge-management-server
edge-message-processor
edge-router

Erstellen und bearbeiten Sie die Konfigurationsdatei basierend auf der Anwendung, die Sie konfigurieren:

Anwendung	Konfigurationsdatei
Verwaltungsserver	`/opt/apigee/customer/application/management-server.properties`
Verwaltungsprozessor	`/opt/apigee/customer/application/message-processor.properties`
Router	`/opt/apigee/customer/application/router.properties`

Fügen Sie der Konfigurationsdatei die folgenden Properties hinzu oder bearbeiten Sie sie:

### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false

Achten Sie darauf, dass die Konfigurationsdatei dem Apigee-Nutzer gehört und von ihm gelesen werden kann:

chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

Starten Sie die Clientanwendung neu:


# Configure and restart service:
apigee-service component configure
apigee-service component restart

# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart

Wiederholen Sie die Schritte a bis d für jede Clientanwendung einzeln.

Deaktivieren Sie mTLS auf allen Cassandra-Knoten einzeln:
1. Wählen Sie einen Cassandra-Knoten aus.
2. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie dieser Datei die folgende Property hinzu oder bearbeiten Sie sie:
```
### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false
```
  Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
3. Konfigurieren Sie den Cassandra-Knoten und starten Sie ihn neu.
4. Wiederholen Sie die Schritte a bis c für jeden Cassandra-Knoten einzeln.

Zertifikatsrotationen

Rotation nur für Blattzertifikate (mit denselben Zwischen- und Root-Zertifikaten)

Sie können ähnliche Schritte wie unter Clientanwendungen konfigurieren ausführen:

Generieren Sie einen neuen Blattschlüssel und ein neues Blattzertifikat für eine Anwendung mit demselben Zwischenschlüssel und demselben Zwischenzertifikat.
Konfigurieren Sie den Pfad zum neuen Blattschlüssel und zum neuen Blattzertifikat in der Anwendung sowie das Passwort und den Schlüsselspeichertyp.
Starten Sie die Anwendung neu.

Rotation für Root- oder Zwischenzertifikate

Wenn Sie entweder das Zwischen- oder das Root-Zertifikat rotieren möchten, empfiehlt es sich, dies in mehreren Schritten zu tun:

Deaktivieren Sie natives mTLS für Cassandra in Ihrem Cluster.
Verwenden Sie die neuen Root- und Zwischenzertifikate, um neue Blatt- oder Anwendungszertifikate zu generieren.
Folgen Sie der Anleitung, um natives mTLS für Cassandra zu aktivieren mit den neuen Schlüsseln und Zertifikaten.

Allgemeine Apigee-Vorgänge

Wenn Sie allgemeine Apigee-Vorgänge wie das Upgrade der Apigee-Software, das Hinzufügen oder Entfernen von Cassandra-Knoten, das Hinzufügen oder Entfernen von Rechenzentren oder das Aktivieren oder Deaktivieren der Cassandra-Authentifizierung ausführen möchten, achten Sie darauf, dass mTLS in Cassandra nicht erzwungen wird. Wenn Sie mTLS erzwungen haben, deaktivieren Sie die Erzwingung bevor Sie mit diesen Vorgängen fortfahren.

Anhang 1

Mit den Schritten in diesem Anhang können Sie ein selbst signiertes Root- und Zwischenschlüssel-/Zertifikatspaar generieren und diese Zertifikatskette einem Truststore hinzufügen.

Selbst signierte Root- und Zwischenzertifikate generieren

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

Truststore generieren

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

Anhang 2: Alternative Zertifikatsverkettungen

In diesem Artikel wird eine bestimmte Zertifikatsverkettung empfohlen, die ein Gleichgewicht zwischen Sicherheit und Bedienfreundlichkeit bietet. Es gibt jedoch Alternativen, die unten beschrieben werden. Die meisten allgemeinen Prinzipien gelten auch für andere Methoden, z. B.:

Direkte Blattschlüssel und ‑zertifikate für jeden Cassandra-Knoten oder jede Clientanwendung (ohne Root- oder Zwischenzertifikate zum Signieren). Dadurch wird die Zertifikatsrotation wahrscheinlich komplex.
Mehrere Root- und Zwischenzertifikatssätze für verschiedene Anwendungsfälle. Cassandra-Knoten haben beispielsweise einen Root-/Zwischenzertifikatssatz, mit dem alle untergeordneten Zertifikate von Cassandra signiert werden. Ebenso haben alle Clientanwendungen möglicherweise einen separaten Root-/Zwischenzertifikatssatz zum Signieren von Blattzertifikaten für Anwendungen. Solche Konfigurationen sind möglich, erfordern aber, dass die Root-/Zwischenzertifikatskette dem entsprechenden Truststore hinzugefügt wird. In diesem Beispiel sollten die Truststores von Cassandra Root-/Zwischenzertifikate des Clients enthalten und die Clientanwendungen sollten die Root-/Zwischenzertifikatskette der Cassandra-Knoten in ihrem Truststore haben.
Ähnlich wie oben können Sie mehrere Root- und Zwischenzertifikatssätze für verschiedene Regionen haben. Alle Clients in allen Regionen und alle Server in allen Regionen müssen jedoch über alle Root- und Zwischenzertifikatsketten informiert werden, indem Sie sie alle dem konfigurierten Truststore hinzufügen.