Konfigurowanie natywnego mTLS w Cassandra

Wprowadzenie

Różne komponenty Edge dla chmury prywatnej, takie jak procesory wiadomości, serwery zarządzania i routery, domyślnie łączą się z węzłami Cassandra za pomocą kanału w postaci zwykłego tekstu. Na takich kanałach dane przesyłane do i z Cassandry są przesyłane w formie niezaszyfrowanej. Apigee mTLS to funkcja oparta na siatce usług konsula, która zwiększa bezpieczeństwo komunikacji między komponentami w klastrze Edge for Private Cloud. Ta oferta Apigee zapewnia też zabezpieczenia TLS w kanale komunikacji między komponentami klienta a Cassandrą.

W tym artykule opisujemy nową alternatywną ofertę Apigee, w której komunikacja między komponentami klienta a Cassandrą w Edge for Private Cloud jest zabezpieczona za pomocą wzajemnego protokołu TLS (zwanego też dwukierunkowym protokołem TLS) przy użyciu funkcji natywnie dostępnych w Cassandrze bez korzystania z zewnętrznej siatki usług.

Natywna funkcja mTLS

Włączenie mTLS między komponentami Cassandra i klienta opisanymi w tym artykule opiera się na funkcjach TLS natywnie udostępnianych przez Apache Cassandra. Gdy ta opcja jest włączona, połączenia klientów z Cassandrą (na porcie transportu natywnego CQL 9042) wykonują dwukierunkowe uzgadnianie TLS z klientami, zanim zezwolą na nawiązanie połączeń. W przypadku tego dwukierunkowego połączenia TLS Cassandra pełni rolę serwera, a różni klienci łączący się z Cassandrą (np. edge-message-processor, narzędzie cqlsh itp.) pełnią rolę klientów.

W przypadku dwukierunkowego protokołu TLS (wzajemnego uwierzytelniania TLS lub mTLS) zarówno Cassandra, jak i klienci muszą mieć skonfigurowany własny magazyn kluczy. Magazyn kluczy każdego węzła Cassandra powinien zawierać jego własny klucz i certyfikat. Magazyn kluczy każdej aplikacji klienta powinien zawierać klucz i certyfikat tego klienta. Zarówno w przypadku Cassandry, jak i klientów należy dodać magazyn zaufanych certyfikatów zawierający certyfikaty i powiązany łańcuch drugiej strony. Magazyn zaufanych certyfikatów każdego węzła Cassandra powinien zawierać certyfikaty klientów, a magazyn zaufanych certyfikatów każdego klienta powinien zawierać certyfikaty wszystkich węzłów Cassandra. Więcej informacji o tym, jak działa dwukierunkowe uzgadnianie TLS, znajdziesz w artykule Apigee na temat dwukierunkowego protokołu TLS/SSL.

Łańcuch certyfikatów

W przypadku dwukierunkowego protokołu TLS certyfikaty serwera, certyfikaty klienta, łańcuchy certyfikatów, magazyny kluczy i magazyny zaufanych certyfikatów można tworzyć na różne sposoby. To samo dotyczy też Cassandra i natywnego mTLS klienta. Biorąc pod uwagę sposób, w jaki organizacje zwykle obsługują klastry Edge for Private Cloud, oraz liczbę unikalnych par połączeń klient-cassandra, które można ustanowić, Apigee zaleca przyjęcie następującego ogólnego podejścia do konfigurowania kluczy i certyfikatów dla tej funkcji. Istnieją inne metody, które są odpowiednie, ale ta poniżej prawdopodobnie zapewnia dobrą równowagę między bezpieczeństwem a kosztami utrzymania.

  1. Uzyskaj certyfikat główny i parę kluczy/certyfikatów pośrednich podpisanych przez certyfikat główny. Możesz już mieć takie klucze i certyfikaty. Jeśli nie, możesz utworzyć podpisane samodzielnie certyfikaty główne i pośrednie oraz klucze, wykonując czynności opisane w Dodatku 1.

  2. Użyj wspólnego klucza/certyfikatu pośredniego podanego powyżej, aby podpisać wszystkie klucze i certyfikaty specyficzne dla aplikacji (końcowe).

Wspólny klucz/certyfikat pośredni w 1 klastrze sprawia, że na każdym węźle Cassandra i węźle klienta jest skonfigurowany wspólny magazyn zaufanych certyfikatów (zawierający ten sam łańcuch certyfikatów głównych i pośrednich). Każdy węzeł Cassandra i aplikacja kliencka otrzymują własny, niepowtarzalny klucz liścia i certyfikat podpisany wspólnym kluczem/certyfikatem pośrednim.

  1. Rotacja certyfikatu liścia węzła Cassandra lub aplikacji klienckiej jest prosta.
  2. Rotacja certyfikatu pośredniego lub głównego jest nadal dość skomplikowaną operacją, ale częstotliwość takich rotacji będzie znacznie niższa niż w przypadku certyfikatów liścia.

Aby zdecydować, czy używać wspólnych certyfikatów głównych i pośrednich w różnych klastrach chmury prywatnej, skorzystaj z praktyk bezpieczeństwa obowiązujących w Twojej organizacji. Alternatywne konfiguracje certyfikatów znajdziesz w Dodatku 2.

W dalszej części tego artykułu znajdziesz szczegółowe informacje o powyższej metodzie projektowania kluczy i certyfikatów.

Ograniczenia i ostrzeżenia

Ta funkcja ma następujące ograniczenia:

  • Ta oferta natywnego mTLS między komponentami klienta a Cassandrą NIE jest zgodna z apigee-mtls. Jeśli korzystasz z tej funkcji, nie możesz używać apigee-mtls i na odwrót.
  • Włączenie mTLS między komponentami klienta a Cassandrą będzie miało pewien wpływ na wydajność połączeń między klientami a Cassandrą. Operacje takie jak uruchamianie klientów czy skalowanie połączeń z Cassandrą mogą być wolniejsze, ponieważ Cassandra i klienci muszą najpierw uzgodnić protokół TLS, zanim rozpoczną komunikację. Wpływ powinien być niewielki i zwykle niezauważalny.
  • W przypadku systemu Cassandra można opcjonalnie wymusić mTLS w przypadku połączeń przychodzących klientów. Wymuszanie można włączyć, ale musi być wyłączone podczas wykonywania zadań operacyjnych, takich jak uaktualnianie oprogramowania Apigee, włączanie i wyłączanie funkcji TLS oraz niektóre rodzaje rotacji certyfikatów. Więcej informacji znajdziesz w sekcji Operacje i konfiguracje.
  • Zarządzanie certyfikatami i ich utrzymywanie należy do klienta.
  • Wymiana certyfikatów ma różne niuanse. Więcej informacji znajdziesz w sekcji Rotacja certyfikatów.

Włączanie natywnego mTLS

Ogólnie włączenie natywnego mTLS to 3-etapowa procedura opisana poniżej:

  1. Uzyskaj certyfikat główny i parę kluczy/certyfikatów pośrednich.
  2. Utwórz parę klucza/certyfikatu węzła Cassandra, podpisz ją, zapisz w magazynie kluczy i skonfiguruj Cassandra pod kątem opcjonalnego mTLS. Powtórz te kroki dla każdego węzła Cassandra, po jednym na raz.
  3. Utwórz parę klucza/certyfikatu liścia 1 aplikacji klienckiej, podpisz ją, zapisz w magazynie kluczy i skonfiguruj aplikację kliencką pod kątem mTLS. Powtórz te kroki w przypadku każdej aplikacji klienckiej. Aplikacje klienckie:
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

Poniżej znajdziesz szczegółowe instrukcje:

Uzyskiwanie certyfikatów głównych i pośrednich

Uzyskaj certyfikat główny i parę kluczy/certyfikatów pośrednich podpisanych przez certyfikat główny. Użyj głównego i pośredniego certyfikatu podpisanego przez urząd certyfikacji Twojej organizacji lub utwórz certyfikaty z podpisem własnym. Przechowuj łańcuch certyfikatów głównych i pośrednich w magazynie zaufanych certyfikatów. Przydatne polecenia znajdziesz w Dodatku 1. W kolejnych poleceniach zakładamy, że masz dostęp do tych plików:

  • intermediate.key – plik klucza certyfikatu pośredniego do podpisywania certyfikatów wierzchołka ścieżki
  • intermediate-cert.pem – certyfikat pośredni

Konfigurowanie węzłów Cassandra

  1. Wybierz jeden węzeł Cassandra
  2. Wygeneruj parę klucza i certyfikatu liścia i podpisz ją certyfikatem pośrednim. Zapisz klucz i podpisany certyfikat w magazynie kluczy. Przykład poniżej: 
    
# 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

    Umieść pliki keystore i truststore w określonej lokalizacji na węźle i upewnij się, że są dostępne dla użytkownika apigee. 

    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. Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties. Dodaj do tego pliku te wiersze: 
    ### 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

    W przypadku systemów operacyjnych z włączonym standardem FIPS dodaj do pliku /opt/apigee/customer/application/cassandra.properties tę właściwość: 

    conf_cassandra_client_encryption_protocol=TLSv1.2

    Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on do niego dostęp do odczytu:

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Konfigurowanie i ponowne uruchamianie węzła Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. Powtórz powyższe kroki na każdym węźle Cassandra po kolei.

Konfigurowanie aplikacji klienckich

Ta sekcja dotyczy tych komponentów klienta, które łączą się z Cassandrą:

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

  1. Wybierz jeden komponent klienta
  2. Wygeneruj parę klucza i certyfikatu liścia i podpisz ją certyfikatem pośrednim. Zapisz klucz i podpisany certyfikat w magazynie kluczy. Przykład poniżej: 
    
# 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

    Umieść pliki keystore i truststore w określonej lokalizacji na węźle i upewnij się, że są dostępne dla użytkownika apigee.

    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. Tworzenie i edytowanie pliku konfiguracji na podstawie konfigurowanej aplikacji
    Aplikacja Plik konfiguracji
    Serwer zarządzania /opt/apigee/customer/application/management-server.properties
    Procesor zarządzający /opt/apigee/customer/application/message-processor.properties
    Router /opt/apigee/customer/application/router.properties

    Dodaj do pliku te konfiguracje: 

    ### 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

    Sprawdź, czy plik konfiguracji jest własnością użytkownika apigee i czy ma on uprawnienia do jego odczytu. 

    chown apigee:apigee configuration file

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

  4. Ponowne uruchamianie aplikacji klienckiej 
    # 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. Aby sprawdzić, czy protokół SSL został prawidłowo skonfigurowany w aplikacji klienckiej, poszukaj w odpowiednim dzienniku systemowym aplikacji logów podobnych do tych poniżej:

    Dodano opcje SSL do połączenia z Cassandrą

  6. Powtórz powyższe kroki w przypadku każdej aplikacji klienckiej po kolei.

Operacje i konfiguracje

Wymuszanie mTLS

Gdy mTLS nie jest wymuszane w Cassandrze, akceptuje ona połączenia w formie zwykłego tekstu od klientów lub klientów, z którymi może przeprowadzić dwukierunkowe uzgadnianie połączenia TLS. Aby egzekwowanie mTLS działało, należy najpierw skonfigurować mTLS w Cassandrze. Aby skonfigurować wymuszanie mTLS w systemie Cassandra, wykonaj te czynności:

  1. Wybierz jeden węzeł Cassandra
  2. Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties. Dodaj lub zmień w tym pliku tę właściwość: 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on uprawnienia do jego odczytu.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Konfigurowanie i ponowne uruchamianie węzła Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. Powtórz powyższe kroki na każdym węźle Cassandra po kolei.

Gdy w systemie Cassandra zostanie wymuszone mTLS, standardowe narzędzie do wykonywania zapytań Cassandra cqlsh nie będzie mogło połączyć się z Cassandrą bezpośrednio. Aby skonfigurować cqlsh pod kątem SSL, wygeneruj nowy klucz i certyfikat liścia (podobnie jak w przypadku aplikacji klienckich) i wykonaj te czynności:

  1. Tworzenie i edytowanie pliku $HOME/.cassandra/cqlshrc
  2. Dodaj do pliku te wiersze: 
    [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 – plik certyfikatu zawierający łańcuch certyfikatów głównych i pośrednich.
    • userkey – klucz klienta, który ma być używany przez cqlsh. Powinna to być para kluczy/certyfikatów liści, którą możesz wygenerować i podpisać za pomocą certyfikatu pośredniego.
    • usercert - certyfikat klienta, który ma być używany przez cqlsh. Powinien to być klucz/certyfikat liścia, który możesz wygenerować i podpisać za pomocą certyfikatu pośredniego.
  3. Uruchom polecenie cqlsh jak zwykle, podając argument --ssl. Na przykład: 
    $  /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>

Wyłączanie egzekwowania mTLS w systemie Cassandra

Aby wyłączyć wymuszanie mTLS w systemie Cassandra, wykonaj te czynności:

  1. Wybierz jeden węzeł Cassandra
  2. Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties. Dodaj lub zmień w tym pliku tę właściwość: 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

    Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on do niego dostęp do odczytu.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Konfigurowanie i ponowne uruchamianie węzła Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. Powtórz powyższe kroki na każdym węźle Cassandra po kolei.

Wyłącz natywny mTLS

Wyłączenie natywnego mTLS to proces wieloetapowy, podobny do włączania natywnego mTLS. Najważniejsze kroki:

  1. Wyłącz egzekwowanie mTLS w Cassandrze (jeśli jest egzekwowane).
  2. Wyłącz mTLS na wszystkich węzłach w tych aplikacjach klienckich:
    • edge-management-server
    • edge-message-processor
    • edge-router
    1. Utwórz i edytuj plik konfiguracji na podstawie aplikacji, którą konfigurujesz:
      Aplikacja Plik konfiguracji
      Serwer zarządzania /opt/apigee/customer/application/management-server.properties
      Procesor zarządzający /opt/apigee/customer/application/message-processor.properties
      Router /opt/apigee/customer/application/router.properties
    2. Dodaj lub edytuj te właściwości w pliku konfiguracji: 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. Sprawdź, czy plik konfiguracyjny jest własnością użytkownika apigee i czy może on go odczytać: 
      chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. Uruchom ponownie aplikację kliencką: 
      
# 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. Powtórz kroki od a do d w przypadku każdej aplikacji klienckiej, po kolei.
  3. Wyłącz mTLS na wszystkich węzłach Cassandra po kolei:
    1. Wybierz jeden węzeł Cassandra.
    2. Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties. Dodaj lub zmień w tym pliku tę właściwość: 
      ### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false

      Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on do niego dostęp do odczytu.

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    3. Konfigurowanie i ponowne uruchamianie węzła Cassandra
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. Powtórz kroki od a do c na każdym węźle Cassandra, po kolei.

Rotacje certyfikatów

Rotacja tylko w przypadku certyfikatów końcowych (z zachowaniem tych samych certyfikatów pośrednich i głównych)

Możesz wykonać czynności podobne do tych opisanych w sekcji Konfigurowanie aplikacji klienckich:

  1. Wygeneruj nowy klucz/certyfikat końcowy dla aplikacji, używając tego samego klucza/certyfikatu pośredniego.
  2. Skonfiguruj w aplikacji ścieżkę do nowego klucza/certyfikatu końcowego wraz z hasłem i typem magazynu kluczy.
  3. Uruchom ponownie aplikację
Rotacja certyfikatów głównych lub pośrednich

Jeśli planujesz wymianę certyfikatu pośredniego lub głównego, zalecamy przeprowadzenie tego procesu w kilku etapach:

  1. Wyłącz natywny protokół mTLS Cassandra w całym klastrze.
  2. Użyj nowych certyfikatów głównych i pośrednich, aby wygenerować nowe certyfikaty liści lub aplikacji.
  3. Wykonaj czynności, aby włączyć natywny protokół mTLS w Cassandrze za pomocą nowego zestawu kluczy i certyfikatów.

Ogólne operacje Apigee

Aby wykonywać ogólne operacje Apigee, takie jak uaktualnianie oprogramowania Apigee, dodawanie lub usuwanie węzłów Cassandra, dodawanie lub usuwanie centrów danych, włączanie lub wyłączanie uwierzytelniania Cassandra itp., upewnij się, że w Cassandrze nie jest wymuszane mTLS. Jeśli masz włączone wymuszanie mTLS, wyłącz je, zanim wykonasz te operacje.

Załącznik 1

Wykonaj czynności opisane w tym dodatku, aby wygenerować samodzielnie podpisaną parę kluczy/certyfikatów głównego i pośredniego oraz dodać ten łańcuch certyfikatów do magazynu zaufanych certyfikatów.

Generowanie samodzielnie podpisanych certyfikatów głównych i pośrednich

# 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

Generowanie magazynu zaufanych certyfikatów

# 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

Dodatek 2. Alternatywne konfiguracje łańcucha certyfikatów

W tym artykule zalecamy konkretną konfigurację łańcucha certyfikatów, która zapewnia równowagę między bezpieczeństwem a łatwością obsługi. Istnieją jednak alternatywne rozwiązania, które opisujemy poniżej. Większość zasad ogólnych ma zastosowanie również w przypadku innych metodologii, takich jak:

  1. Posiadanie bezpośrednich kluczy liści i certyfikatów dla każdego węzła Cassandra lub aplikacji klienckiej (bez żadnych głównych ani pośrednich certyfikatów podpisywania). Prawdopodobnie utrudni to wymianę certyfikatów.
  2. Posiadanie wielu zestawów certyfikatów głównych i pośrednich dla różnych przypadków użycia. Na przykład węzły Cassandra mają 1 zestaw certyfikatów głównych/pośrednich, za pomocą którego są podpisywane wszystkie certyfikaty liści Cassandra. Podobnie wszystkie aplikacje klienckie mogą mieć jeden osobny zestaw główny/pośredni do podpisywania certyfikatów liści aplikacji. Takie konfiguracje są możliwe, ale wymagają dodania łańcucha certyfikatów głównych lub pośrednich do odpowiedniego magazynu zaufanych certyfikatów. W tym przykładzie magazyny zaufanych certyfikatów Cassandra powinny zawierać certyfikaty główne i pośrednie klienta, a aplikacje klienckie powinny mieć w swoich magazynach zaufanych certyfikatów łańcuch certyfikatów głównych i pośrednich węzłów Cassandra.
  3. Podobnie jak powyżej możesz mieć wiele zestawów certyfikatów głównych i pośrednich dla różnych regionów, ale wszyscy klienci we wszystkich regionach i wszystkie serwery we wszystkich regionach muszą być informowani o wszystkich łańcuchach certyfikatów głównych i pośrednich przez dodanie ich wszystkich do skonfigurowanego magazynu zaufanych certyfikatów.