Cassandra 네이티브 mTLS 구성

소개

메시지 프로세서, 관리 서버, 라우터와 같은 프라이빗 클라우드용 Edge의 다양한 구성요소는 기본적으로 일반 텍스트 채널을 통해 Cassandra 노드에 연결됩니다. 이러한 채널에서는 Cassandra와의 데이터 통신이 명확하게 이루어집니다. Apigee mTLS는 consul 서비스 메시 기반 기능으로, Private Cloud용 Edge 클러스터의 구성요소 간 통신에 보안을 추가합니다. Apigee의 이 제품은 클라이언트 구성요소와 Cassandra 간의 통신 채널에 TLS 보안도 추가합니다.

이 도움말에서는 외부 서비스 메시를 사용하지 않고 Cassandra에서 기본적으로 제공되는 기능을 사용하여 비공개 클라우드용 Edge의 클라이언트 구성요소와 Cassandra 간 통신이 상호 TLS (양방향 TLS)를 통해 보호되는 Apigee의 새로운 대체 제품을 다룹니다.

네이티브 mTLS 기능

이 도움말에 설명된 Cassandra와 클라이언트 구성요소 간 mTLS를 사용 설정하는 것은 Apache Cassandra에서 기본적으로 제공하는 TLS 기능을 기반으로 합니다. 사용 설정하면 Cassandra (CQL 네이티브 전송 포트 9042)에 대한 클라이언트 연결이 연결이 설정되기 전에 클라이언트와 양방향 TLS 핸드셰이크를 실행합니다. 이 양방향 TLS 연결의 목적을 위해 Cassandra는 서버 역할을 하고 Cassandra에 연결하는 다양한 클라이언트 (예: edge-message-processor, cqlsh 도구 등)는 클라이언트 역할을 합니다.

양방향 TLS (또는 상호 TLS 또는 mTLS)의 경우 Cassandra와 클라이언트가 모두 자체 키 저장소로 설정되어야 합니다. 각 Cassandra 노드의 키 저장소에는 자체 키와 인증서가 포함되어야 합니다. 각 클라이언트 애플리케이션의 키 저장소에는 해당 클라이언트의 키와 인증서가 포함되어야 합니다. 인증서와 상대방의 연결된 체인이 포함된 신뢰 저장소를 Cassandra와 클라이언트 모두에 추가해야 합니다. 각 Cassandra 노드의 트러스트 저장소에는 클라이언트의 인증서가 포함되어야 하고 각 클라이언트의 트러스트 저장소에는 모든 Cassandra 노드의 인증서가 포함되어야 합니다. 양방향 TLS 핸드셰이크의 일반적인 작동 방식에 대한 자세한 내용은 Apigee의 양방향 TLS/SSL 도움말을 참고하세요.

인증서 체인

일반적으로 양방향 TLS에서는 서버 인증서, 클라이언트 인증서, 인증서 체인, 키 저장소, 신뢰 저장소를 다양한 방법으로 만들 수 있습니다. Cassandra 및 클라이언트 네이티브 mTLS의 경우도 마찬가지입니다. 일반적으로 조직에서 Private Cloud용 Edge 클러스터를 운영하는 방식과 설정할 수 있는 고유한 클라이언트-Cassandra 연결 쌍의 수를 고려할 때 Apigee에서는 이 기능의 키와 인증서를 구성할 때 다음 일반적인 접근 방식을 따르는 것이 좋습니다. 사용 가능한 다른 방법도 있지만 아래 방법이 보안과 유지관리 오버헤드 간의 균형을 잘 유지할 수 있습니다.

  1. 루트 인증서와 루트에서 서명한 중간 키/인증서 쌍을 조달합니다. 이러한 키와 인증서를 이미 보유하고 있을 수도 있습니다. 그렇지 않은 경우 부록 1의 단계를 사용하여 자체 서명된 루트 및 중간 인증서와 키를 만들 수 있습니다.

  2. 위의 공통 중간 키/인증서를 사용하여 모든 애플리케이션별 (리프) 키와 인증서에 서명합니다.

하나의 클러스터에서 공통 중간 키/인증서를 사용하면 동일한 루트 및 중간 인증서 체인이 포함된 공통 신뢰 저장소가 모든 Cassandra 및 클라이언트 노드에 구성됩니다. 모든 Cassandra 노드와 클라이언트 애플리케이션은 공통 중간 키/인증서로 서명된 고유한 리프 키와 인증서를 가져옵니다.

  1. Cassandra 노드 또는 클라이언트 애플리케이션의 리프 인증서를 순환하는 것은 간단합니다.
  2. 중간 또는 루트 인증서를 순환하는 것은 여전히 상당히 복잡한 작업이지만 이러한 순환 빈도는 리프 인증서의 빈도보다 훨씬 낮습니다.

조직의 보안 관행에 따라 여러 비공개 클라우드 클러스터에서 공통 루트 및 중간 인증서를 사용할지 결정합니다. 대체 인증서 설정은 부록 2를 참고하세요.

이 도움말의 나머지 단계에서는 키와 인증서를 설계하는 위의 방법론에 관한 세부정보를 제공합니다.

제한사항 및 주의사항

이 기능에는 다음 제한사항이 적용됩니다.

  • 클라이언트 구성요소와 Cassandra 간의 기본 mTLS는 apigee-mtls와 호환되지 않습니다. 이 기능을 사용하는 경우 apigee-mtls를 사용할 수 없으며 그 반대의 경우도 마찬가지입니다.
  • 클라이언트 구성요소와 Cassandra 간에 mTLS를 사용 설정하면 클라이언트와 Cassandra 간에 설정되는 연결에 약간의 성능 영향이 있습니다. Cassandra와 클라이언트가 통신을 시작하기 전에 먼저 TLS를 협상해야 하므로 클라이언트 부팅이나 Cassandra 연결 확장과 같은 작업이 더 느릴 수 있습니다. 영향은 미미하며 일반적으로 눈에 띄지 않습니다.
  • Cassandra에서는 인바운드 클라이언트 연결에 mTLS를 선택적으로 적용할 수 있습니다. 시행을 사용 설정할 수 있지만 Apigee 소프트웨어 업그레이드, TLS 기능 사용 설정/중지, 특정 유형의 인증서 순환과 같은 운영 작업 중에는 사용 중지해야 합니다. 자세한 내용은 작업 및 구성 섹션을 참고하세요.
  • 인증서를 관리하고 유지하는 것은 고객의 책임입니다.
  • 인증서 순환에는 다양한 뉘앙스가 있습니다. 자세한 내용은 인증서 순환 섹션을 참고하세요.

네이티브 mTLS 사용 설정

개략적으로 네이티브 mTLS를 사용 설정하는 것은 아래 설명된 대로 3단계 절차입니다.

  1. 루트 인증서와 중간 키/인증서 쌍을 조달합니다.
  2. Cassandra 노드 1개의 리프 키/인증서 쌍을 만들고 서명하고 키 저장소에 저장하고 선택적 mTLS를 위해 Cassandra를 구성합니다. Cassandra 노드마다 한 번에 단계를 반복합니다.
  3. 클라이언트 애플리케이션 1개의 리프 키/인증서 쌍을 만들고 서명하고 키 저장소에 저장하고 mTLS용 클라이언트 애플리케이션을 구성합니다. 각 클라이언트 애플리케이션에서 한 번에 하나씩 단계를 반복합니다. 클라이언트 애플리케이션:
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

이 단계는 아래에 자세히 설명되어 있습니다.

루트 및 중간 인증서 획득

루트 인증서와 루트에서 서명한 중간 키/인증서 쌍을 조달합니다. 조직의 CA 서명 루트 및 중간 인증서를 사용하거나 자체 서명된 인증서를 만듭니다. 루트 및 중간 인증서 체인을 신뢰 저장소에 저장합니다. 유용한 명령어는 부록 1을 참고하세요. 후속 명령어는 다음 파일에 액세스할 수 있다고 가정합니다.

  • intermediate.key - 리프 인증서 서명을 위한 중간 인증서의 키 파일
  • intermediate-cert.pem: 중간 인증서

Cassandra 노드 구성

  1. Cassandra 노드 하나 선택
  2. 리프 키와 인증서 쌍을 생성하고 중간 인증서로 서명합니다. 키와 서명된 인증서를 키 저장소에 저장합니다. 예를 들어 다음과 같습니다. 
    
# 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

    키 저장소 및 신뢰 저장소 파일을 노드의 특정 위치에 배치하고 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. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에 다음 콘텐츠를 추가합니다. 
    ### 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

    또한 FIPS 지원 운영체제의 경우 /opt/apigee/customer/application/cassandra.properties 파일에 다음 속성을 추가합니다. 

    conf_cassandra_client_encryption_protocol=TLSv1.2

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Cassandra 노드 구성 및 다시 시작 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. 각 Cassandra 노드에서 위 단계를 한 번에 하나씩 반복합니다.

클라이언트 애플리케이션 구성

이 섹션은 Cassandra에 연결되는 다음 클라이언트 구성요소에 적용됩니다.

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

  1. 클라이언트 구성요소 하나 선택
  2. 리프 키와 인증서 쌍을 생성하고 중간 인증서로 서명합니다. 키와 서명된 인증서를 키 저장소에 저장합니다. 예를 들어 다음과 같습니다. 
    
# 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

    키 저장소 및 신뢰 저장소 파일을 노드의 특정 위치에 배치하고 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. 구성하는 애플리케이션에 따라 구성 파일 만들기 및 수정
    애플리케이션 구성 파일
    관리 서버 /opt/apigee/customer/application/management-server.properties
    관리 프로세서 /opt/apigee/customer/application/message-processor.properties
    라우터 /opt/apigee/customer/application/router.properties

    파일에 다음 구성을 추가합니다. 

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

    구성 파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인 

    chown apigee:apigee configuration file

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

  4. 클라이언트 애플리케이션 다시 시작 
    # 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. 적절한 애플리케이션의 시스템 로그에서 아래 줄을 따라 로그를 찾아 클라이언트 애플리케이션에서 SSL이 올바르게 구성되었는지 확인할 수 있습니다.

    cassandra 연결에 SSL 옵션 추가

  6. 각 클라이언트 애플리케이션에서 위의 단계를 한 번에 하나씩 반복합니다.

작업 및 구성

mTLS 시행

Cassandra에서 mTLS가 적용되지 않으면 Cassandra는 클라이언트의 일반 텍스트 연결 또는 양방향 TLS 핸드셰이크를 성공적으로 실행할 수 있는 클라이언트를 허용합니다. mTLS 강제 적용이 작동하려면 먼저 Cassandra에서 mTLS를 구성해야 합니다. 다음 단계에 따라 Cassandra에서 mTLS 적용을 설정할 수 있습니다.

  1. Cassandra 노드 하나 선택
  2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에서 다음 속성을 추가하거나 수정합니다. 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Cassandra 노드 구성 및 다시 시작 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. 각 Cassandra 노드에서 위 단계를 한 번에 하나씩 반복합니다.

Cassandra에서 mTLS가 적용되면 표준 Cassandra 쿼리 도구인 cqlsh가 Cassandra에 직접 연결할 수 없습니다. SSL용 cqlsh를 구성하려면 새 리프 키와 인증서 (클라이언트 애플리케이션의 리프 키 및 인증서와 유사)를 생성하고 다음 단계를 따르세요.

  1. $HOME/.cassandra/cqlshrc 파일 만들기 또는 수정
  2. 파일에 다음 내용을 추가합니다. 
    [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 - 루트 및 중간 인증서 체인이 포함된 인증서 파일
    • userkey - cqlsh에서 사용할 클라이언트 키입니다. 이는 중간 인증서로 생성하고 서명할 수 있는 리프 키/인증서 쌍이어야 합니다.
    • usercert - cqlsh에서 사용할 클라이언트 인증서입니다. 이는 중간 인증서로 생성하고 서명할 수 있는 리프 키/인증서여야 합니다.
  3. --ssl 인수를 제공하면서 평소와 같이 cqlsh 명령어를 실행합니다. 예를 들어 다음과 같습니다. 
    $  /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>

Cassandra에서 mTLS 적용 사용 중지

Cassandra에서 mTLS 적용을 사용 중지하려면 다음 단계를 따르세요.

  1. Cassandra 노드 하나 선택
  2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에서 다음 속성을 추가하거나 수정합니다. 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

    파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Cassandra 노드 구성 및 다시 시작 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. 각 Cassandra 노드에서 위 단계를 한 번에 하나씩 반복합니다.

네이티브 mTLS 사용 중지

네이티브 mTLS를 사용 중지하는 것은 네이티브 mTLS를 사용 설정하는 것과 마찬가지로 여러 단계로 이루어진 프로세스입니다. 대략적인 단계는 다음과 같습니다.

  1. Cassandra에서 mTLS 적용 사용 중지 (적용된 경우)
  2. 다음 클라이언트 애플리케이션의 모든 노드에서 mTLS를 하나씩 사용 중지합니다.
    • edge-management-server
    • edge-message-processor
    • edge-router
    1. 구성하려는 애플리케이션에 따라 구성 파일을 만들고 수정합니다.
      애플리케이션 구성 파일
      관리 서버 /opt/apigee/customer/application/management-server.properties
      관리 프로세서 /opt/apigee/customer/application/message-processor.properties
      라우터 /opt/apigee/customer/application/router.properties
    2. 구성 파일에서 다음 속성을 추가하거나 수정합니다. 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. 구성 파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인합니다. 
      chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. 클라이언트 애플리케이션을 다시 시작합니다. 
      
# 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. 각 클라이언트 애플리케이션에서 #a~ #d 단계를 한 번에 하나씩 반복합니다.
  3. 모든 Cassandra 노드에서 mTLS를 하나씩 사용 중지합니다.
    1. Cassandra 노드 하나를 선택합니다.
    2. /opt/apigee/customer/application/cassandra.properties 파일을 만들거나 수정합니다. 이 파일에서 다음 속성을 추가하거나 수정합니다. 
      ### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false

      파일이 apigee 사용자가 소유하고 읽을 수 있는지 확인

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    3. Cassandra 노드 구성 및 다시 시작
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. 각 Cassandra 노드에서 한 번에 하나씩 #a~ #c 단계를 반복합니다.

인증서 순환

리프 인증서만 순환 (동일한 중간 및 루트 인증서 유지)

클라이언트 애플리케이션 구성과 유사한 단계를 따를 수 있습니다.

  1. 동일한 중간 키/인증서를 사용하여 애플리케이션의 새 리프 키/인증서 생성
  2. 애플리케이션에서 새 리프 키/인증서의 경로를 비밀번호 및 키 저장소 유형과 함께 구성합니다.
  3. 애플리케이션 다시 시작
루트 또는 중간 인증서 순환

중간 인증서 또는 루트 인증서를 순환하려는 경우 다음 다단계 프로세스를 따르는 것이 좋습니다.

  1. 클러스터에서 Cassandra 네이티브 mTLS를 사용 중지합니다.
  2. 새 루트 및 중간 인증서를 사용하여 새 리프 또는 애플리케이션 인증서를 생성합니다.
  3. 새 키 및 인증서 세트를 사용하여 Cassandra 네이티브 mTLS를 사용 설정하는 단계를 따릅니다.

일반 Apigee 작업

Apigee 소프트웨어 업그레이드, Cassandra 노드 추가 또는 삭제, 데이터 센터 추가 또는 삭제, Cassandra 인증 사용 설정 또는 중지 등 일반적인 Apigee 작업을 실행하려면 Cassandra에서 mTLS가 적용되지 않아야 합니다. mTLS를 적용한 경우 이러한 작업을 진행하기 전에 적용을 사용 중지하세요.

부록 1

이 부록의 단계에 따라 자체 서명된 루트 및 중간 키/인증서 쌍을 생성하고 이 인증서 체인을 트러스트 저장소에 추가할 수 있습니다.

자체 서명 루트 및 중간 인증서 생성

# 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

트러스트 저장소 생성

# 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

부록 2: 대체 인증서 체인 설정

이 도움말에서는 보안과 운영 편의성의 균형을 맞추는 특정 인증서 체인 설정을 권장하지만, 대체 방법이 있으며 아래에 설명되어 있습니다. 대부분의 일반 원칙은 다음과 같은 다른 방법론에도 적용됩니다.

  1. 서명 루트 또는 중간 인증서 없이 모든 Cassandra 노드 또는 클라이언트 애플리케이션에 직접 리프 키와 인증서가 있음 이렇게 하면 인증서 교체가 복잡해질 수 있습니다.
  2. 다양한 사용 사례에 여러 루트 및 중간 세트가 있음 예를 들어 Cassandra 노드에는 Cassandra의 모든 리프 인증서가 서명되는 1개의 루트/중간 인증서 세트가 있습니다. 마찬가지로 모든 클라이언트 애플리케이션에는 애플리케이션 리프 인증서에 서명하기 위한 별도의 루트/중간 세트가 하나 있을 수 있습니다. 이러한 설정은 가능하지만 적절한 트러스트 저장소에 루트/중간 인증서 체인을 추가해야 합니다. 이 예에서 Cassandra의 트러스트 저장소에는 클라이언트의 루트/중간 인증서가 포함되어야 하고 클라이언트 애플리케이션의 트러스트 저장소에는 Cassandra 노드의 루트/중간 체인이 있어야 합니다.
  3. 위와 마찬가지로 여러 리전에 여러 루트 및 중간 인증서 세트가 있을 수 있지만, 구성된 신뢰 저장소에 모든 루트 및 중간 체인을 추가하여 모든 리전의 모든 클라이언트와 모든 리전의 모든 서버가 모든 루트 및 중간 체인을 인식하도록 해야 합니다.