Cassandra-natives mTLS konfigurieren

Einführung

Verschiedene Komponenten von Edge for Private Cloud wie Message Processor, Verwaltungsserver und Router stellen standardmäßig über einen unverschlüsselten Kanal eine Verbindung zu Cassandra-Knoten her. Auf solchen Kanälen werden Daten zu und von Cassandra im Klartext übertragen. Apigee mTLS ist eine auf Consul Service Mesh basierende Funktion, die die Kommunikation zwischen Komponenten in Edge for Private Cloud-Clustern sicherer macht. Dieses Angebot von Apigee bietet auch TLS-Sicherheit für den Kommunikationskanal zwischen Clientkomponenten und Cassandra.

In diesem Artikel wird ein neues alternatives Angebot von Apigee beschrieben, bei dem die Kommunikation zwischen Clientkomponenten und Cassandra in Edge for Private Cloud über gegenseitiges TLS (auch als bidirektionales TLS bezeichnet) mit Funktionen gesichert wird, die nativ in Cassandra verfügbar sind, ohne dass ein externes Service Mesh verwendet wird.

Native mTLS-Funktion

Die Aktivierung von mTLS zwischen Cassandra und den in diesem Artikel beschriebenen Clientkomponenten basiert auf TLS-Funktionen, die nativ von Apache Cassandra bereitgestellt werden. Wenn diese Option aktiviert ist, wird bei Clientverbindungen zu Cassandra (über den nativen CQL-Transportport 9042) ein bidirektionaler TLS-Handshake mit Clients durchgeführt, bevor Verbindungen hergestellt werden dürfen. Für diese bidirektionale TLS-Verbindung fungiert Cassandra als Server und verschiedene Clients, die sich mit Cassandra verbinden (z. B. edge-message-processor, cqlsh-Tool usw.), als Clients.

Für die Zwei-Wege-TLS (auch gegenseitige TLS oder mTLS genannt) müssen sowohl Cassandra als auch die Clients mit einem eigenen Schlüsselspeicher eingerichtet werden. Der Keystore 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 des jeweiligen Clients enthalten. Ein Truststore mit den Zertifikaten und der zugehörigen Kette des Gegenübers sollte sowohl in Cassandra als auch auf den Clients 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 zum bidirektionalen TLS-Handshake finden Sie im Apigee-Artikel zu bidirektionaler TLS/SSL.

Verkettung von Zertifikaten

Im Allgemeinen können Serverzertifikate, Clientzertifikate, Zertifikatsketten, Keystores und Truststores für die bidirektionale TLS-Authentifizierung auf verschiedene Arten erstellt werden. Dasselbe gilt auch für Cassandra und clientseitiges natives mTLS. Unter Berücksichtigung der typischen Betriebsweise von Edge for Private Cloud-Clustern 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 Methoden, aber die unten beschriebene bietet wahrscheinlich ein gutes Gleichgewicht zwischen Sicherheit und Wartungsaufwand.

  1. Besorgen Sie ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatpaar, das vom Root-Zertifikat signiert wurde. Möglicherweise haben Sie solche Schlüssel und Zertifikate bereits. Andernfalls können Sie selbst signierte Root- und Zwischenzertifikate sowie Schlüssel anhand der Schritte in Anhang 1 erstellen.

  2. Verwenden Sie den oben genannten gemeinsamen Zwischenschlüssel bzw. das gemeinsame Zwischenzertifikat, um alle anwendungsspezifischen (Blatt-)Schlüssel und -Zertifikate zu signieren.

Wenn ein gemeinsamer Zwischenschlüssel bzw. ein gemeinsames Zwischenzertifikat für einen Cluster verwendet wird, wird auf jedem Cassandra- und Clientknoten ein gemeinsamer Truststore (mit derselben Stamm- und Zwischenzertifikatskette) konfiguriert. Jeder Cassandra-Knoten und jede Clientanwendung erhält einen eigenen eindeutigen Blatt-Schlüssel und ein Zertifikat, das mit dem gemeinsamen Zwischenschlüssel bzw. -zertifikat signiert ist.

  1. Das Rotieren eines Blattzertifikats eines Cassandra-Knotens oder einer Clientanwendung ist einfach.
  2. 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 Blattzertifikaten.

Anhand der Sicherheitsrichtlinien Ihrer Organisation können Sie entscheiden, ob Sie gemeinsame Stamm- und Zwischenzertifikate für verschiedene Private Cloud-Cluster verwenden möchten. Anhang 2 enthält alternative Zertifikatskonfigurationen.

In den verbleibenden Schritten dieses Artikels finden Sie Details zur oben beschriebenen Methode zum Entwerfen von Schlüsseln und Zertifikaten.

Einschränkungen und Vorbehalte

Für dieses Feature gelten die folgenden Einschränkungen.

  • Dieses Angebot von nativem mTLS zwischen Clientkomponenten und Cassandra ist NICHT mit apigee-mtls kompatibel. Wenn Sie dieses Feature verwenden, können Sie apigee-mtls nicht verwenden und umgekehrt.
  • Die Aktivierung von mTLS zwischen Clientkomponenten und Cassandra hat Auswirkungen auf die Leistung von Verbindungen, die zwischen Clients und Cassandra hergestellt werden. 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. Die Auswirkungen sollten gering und in der Regel nicht spürbar 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.
  • Die Verwaltung und Pflege von Zertifikaten liegt in der Verantwortung des Kunden.
  • Das Rotieren von Zertifikaten hat verschiedene Nuancen. Weitere Informationen finden Sie im Abschnitt Zertifikatsrotationen.

Native mTLS aktivieren

Die Aktivierung von nativem mTLS umfasst im Wesentlichen drei Schritte:

  1. Besorgen Sie sich ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatpaar.
  2. Erstellen Sie ein Blatt-Schlüssel-/Zertifikatpaar für einen Cassandra-Knoten, signieren Sie es, speichern Sie es in einem Keystore und konfigurieren Sie Cassandra für optionales mTLS. Wiederholen Sie die Schritte für jeden Cassandra-Knoten einzeln.
  3. Erstellen Sie ein untergeordnetes Schlüssel-/Zertifikatpaar 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 genauer beschrieben:

Root- und Zwischenzertifikate beschaffen

Besorgen Sie ein Root-Zertifikat und ein Zwischenschlüssel-/Zertifikatpaar, das vom Root-Zertifikat signiert wurde. Verwenden Sie das von der Zertifizierungsstelle Ihrer Organisation signierte Stamm- und Zwischenzertifikat oder erstellen Sie selbst signierte Zertifikate. Speichern Sie die Root- und Zwischenzertifikatskette in einem Truststore. Anhang 1 enthält 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 Endzertifikaten
  • intermediate-cert.pem: Zwischenzertifikat

Cassandra-Knoten konfigurieren

  1. Cassandra-Knoten auswählen
  2. Generieren Sie ein Blatt-Schlüssel- und 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 Keystore- und Truststore-Dateien an einem bestimmten Ort auf dem Knoten und sorgen Sie dafür, dass der Apigee-Nutzer darauf zugreifen kann. 

    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

  3. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie der 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

    Fügen Sie für FIPS-fähige Betriebssysteme der Datei /opt/apigee/customer/application/cassandra.properties außerdem die folgende Property hinzu: 

    conf_cassandra_client_encryption_protocol=TLSv1.2

    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
  4. Cassandra-Knoten konfigurieren und neu starten 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. 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

  1. Clientkomponente auswählen
  2. Generieren Sie ein Blatt-Schlüssel- und 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 Keystore- und Truststore-Dateien an einem bestimmten Ort auf dem Knoten und sorgen Sie dafür, dass der Apigee-Nutzer darauf zugreifen kann.

    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

  3. Konfigurationsdatei basierend auf der zu konfigurierenden Anwendung erstellen und bearbeiten
    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

    Prüfen Sie, ob 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

  4. Clientanwendung neu starten 
    # 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
  5. Sie können prüfen, ob SSL in der Clientanwendung richtig konfiguriert wurde, indem Sie im Systemlog der entsprechenden Anwendung nach Logs suchen, die den folgenden Zeilen ähneln:

    SSL-Optionen für Cassandra-Verbindung hinzugefügt

  6. 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 bidirektionaler TLS-Handshake erfolgreich durchgeführt werden kann. Damit die mTLS-Durchsetzung funktioniert, muss mTLS zuerst in Cassandra konfiguriert werden. So legen Sie die mTLS-Erzwingung in Cassandra fest:

  1. Cassandra-Knoten auswählen
  2. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie in dieser Datei das folgende Attribut hinzu oder bearbeiten Sie es: 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    Prüfen Sie, ob die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Cassandra-Knoten konfigurieren und neu starten 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. 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. So konfigurieren Sie cqlsh für SSL: Generieren Sie einen neuen Leaf-Schlüssel und ein neues Zertifikat (ähnlich wie bei Leaf-Schlüssel und Zertifikat für Clientanwendungen) und gehen Sie so vor:

  1. Datei $HOME/.cassandra/cqlshrc erstellen oder bearbeiten
  2. 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: Der Clientschlüssel, der von cqlsh verwendet werden soll. Dies sollte ein Blatt-Schlüssel-/Zertifikatpaar sein, das Sie mit dem Zwischenzertifikat generieren und signieren können.
    • usercert: Das von cqlsh zu verwendende Clientzertifikat. Dies sollte ein Endstellenschlüssel bzw. ‑zertifikat sein, das Sie mit dem Zwischenzertifikat generieren und signieren können.
  3. 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>

Durchsetzung von mTLS für Cassandra deaktivieren

So deaktivieren Sie die Erzwingung von mTLS in Cassandra:

  1. Cassandra-Knoten auswählen
  2. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties. Fügen Sie in dieser Datei das folgende Attribut hinzu oder bearbeiten Sie es: 
    ### 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
  3. Cassandra-Knoten konfigurieren und neu starten 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. Wiederholen Sie die oben genannten Schritte für jeden Cassandra-Knoten einzeln.

Native mTLS deaktivieren

Das Deaktivieren von nativem mTLS ist ein mehrstufiger Prozess, der dem Aktivieren von nativem mTLS ähnelt. Allgemeine Schritte:

  1. mTLS-Erzwingung in Cassandra deaktivieren (falls erzwungen)
  2. Deaktivieren Sie mTLS in allen Knoten der folgenden Clientanwendungen einzeln:
    • edge-management-server
    • edge-message-processor
    • Edge-Router
    1. 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
    2. Fügen Sie der Konfigurationsdatei die folgenden Attribute hinzu oder bearbeiten Sie sie: 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. Prüfen Sie, ob 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
    4. 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
    5. Wiederholen Sie die Schritte a bis d für jede Clientanwendung einzeln.
  3. 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 in dieser Datei das folgende Attribut hinzu oder bearbeiten Sie es: 
      ### 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. Cassandra-Knoten konfigurieren und neu starten
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. Wiederholen Sie die Schritte a bis c für jeden Cassandra-Knoten einzeln.

Zertifikatsrotationen

Rotation nur für Leaf-Zertifikate (Zwischen- und Root-Zertifikate bleiben gleich)

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

  1. Neuen Blattschlüssel bzw. neues Blattzertifikat für eine Anwendung mit demselben Zwischenschlüssel bzw. Zwischenzertifikat generieren
  2. Konfigurieren Sie den Pfad zum neuen Endstellenschlüssel bzw. ‑zertifikat in der Anwendung zusammen mit dem Passwort und dem Schlüsselspeichertyp.
  3. App neu starten
Rotation von Root- oder Zwischenzertifikaten

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

  1. Deaktivieren Sie das native mTLS von Cassandra in Ihrem Cluster.
  2. Verwenden Sie die neuen Root- und Zwischenzertifikate, um neue Leaf- oder Anwendungszertifikate zu generieren.
  3. Folgen Sie der Anleitung, um Cassandra-mTLS zu aktivieren. Verwenden Sie dazu die neuen Schlüssel und Zertifikate.

Allgemeine Apigee-Vorgänge

Wenn Sie allgemeine Apigee-Vorgänge wie das Aktualisieren 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, muss mTLS in Cassandra deaktiviert sein. Wenn Sie mTLS erzwingen, müssen Sie die Erzwingung deaktivieren, bevor Sie mit diesen Vorgängen fortfahren.

Anhang 1

Mit den Schritten in diesem Anhang können Sie ein selbstsigniertes Root- und Zwischenschlüssel-/Zertifikatpaar generieren und diese Zertifikatkette in einen Truststore einfü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 Einrichtung der Zertifikatskette

In diesem Artikel wird eine bestimmte Einrichtung der Zertifikatskette empfohlen, die ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit bietet. Es gibt jedoch Alternativen, die unten beschrieben werden. Die meisten allgemeinen Grundsätze gelten auch für andere Methoden, z. B.:

  1. Direkte Blatt-Schlüssel und ‑Zertifikate für jeden Cassandra-Knoten oder jede Clientanwendung (ohne Signatur-Root- oder Zwischenzertifikate). Dies macht die Zertifikatsrotation wahrscheinlich komplex.
  2. Mehrere Stamm- und Zwischenzertifikate für verschiedene Anwendungsfälle: Cassandra-Knoten haben beispielsweise einen Satz von Stamm-/Zwischenzertifikaten, mit dem alle Blattzertifikate von Cassandra signiert werden. Ebenso kann für alle Clientanwendungen ein separates Stamm-/Zwischenzertifikatset zum Signieren von Anwendungs-Leaf-Zertifikaten verwendet werden. Solche Setups sind möglich, erfordern jedoch, dass die Root-/Zwischenzertifikatskette dem entsprechenden Trust Store hinzugefügt wird. In diesem Beispiel sollten die Truststores von Cassandra Root-/Zwischenzertifikate des Clients enthalten und Clientanwendungen sollten die Root-/Zwischenzertifikatskette von Cassandra-Knoten in ihrem Truststore haben.
  3. Ähnlich wie oben können Sie mehrere Stamm- und Zwischenzertifikatsätze für verschiedene Regionen haben. Alle Clients und Server in allen Regionen müssen jedoch über alle Stamm- und Zwischenketten informiert werden, indem Sie alle im konfigurierten Truststore hinzufügen.