Edge UI를 사용하여 키 저장소 및 트러스트 저장소 만들기

Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보

이 문서에서는 Cloud용 Edge 및 프라이빗 클라우드용 Edge 버전 4.18.01 이상에서 키 저장소와 신뢰 저장소를 만들고 수정하고 삭제하는 방법을 설명합니다.

Edge Cloud의 키 저장소/트러스트 저장소 및 가상 호스트 정보

Edge Cloud의 키 저장소/신뢰 저장소를 만드는 프로세스에서는 가상 호스트 사용에 관한 모든 규칙을 따라야 합니다. 예를 들어 Cloud의 가상 호스트를 사용하면 다음과 같은 이점이 있습니다.

  • 가상 호스트는 TLS를 사용해야 합니다.
  • 가상 호스트는 포트 443만 사용할 수 있습니다.
  • 서명된 TLS 인증서를 사용해야 합니다. 서명되지 않은 인증서는 Cloud의 가상 호스트에 사용할 수 없습니다.
  • TLS 인증서에 지정된 도메인 이름은 가상 호스트의 호스트 별칭과 일치해야 합니다.

자세히 알아보기:

Edge에서 키 저장소 및 트러스트 저장소 구현

TLS와 같이 공개 키 인프라를 사용하는 기능을 구성하려면 필요한 키와 디지털 인증서가 포함된 키 저장소와 트러스트 저장소를 만들어야 합니다.

Edge에서 키 저장소와 신뢰 저장소는 모두 하나 이상의 별칭이 포함된 키 저장소 항목으로 표시됩니다. 즉, Edge의 키 저장소와 신뢰 저장소 간에는 구현 차이가 없습니다.

키 저장소와 트러스트 저장소의 차이점은 키 저장소와 트러스트 저장소에 포함된 항목의 종류와 TLS 핸드셰이크에서 사용되는 방식에서 비롯됩니다.

  • 키 저장소 - 하나 이상의 별칭이 포함된 키 저장소 항목으로, 각 별칭에는 cert/key 쌍이 포함됩니다.
  • truststore - 하나 이상의 별칭이 포함된 키 저장소 항목으로, 각 별칭에는 인증서만 포함됩니다.

가상 호스트 또는 대상 엔드포인트에 TLS를 구성할 때 키 저장소와 신뢰 저장소는 TLS 핸드셰이킹 프로세스에서 서로 다른 역할을 합니다. 가상 호스트 또는 대상 엔드포인트를 구성할 때는 아래의 가상 호스트와 같이 <SSLInfo> 태그에서 키 저장소와 트러스트 저장소를 별도로 지정합니다.

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>apiTLS.myCompany.com</HostAlias> 
    </HostAliases> 
    <Interfaces/> 
    <Port>9006</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>false</ClientAuthEnabled> 
        <KeyStore>ref://keystoreref</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
    </SSLInfo>
</VirtualHost>

이 예에서는 가상 호스트가 TLS 키 저장소에 사용하는 키 저장소 및 별칭의 이름을 지정합니다. 참조를 사용하여 키 저장소 이름을 지정하면 나중에 인증서가 만료될 때 이를 변경할 수 있습니다. 별칭에는 가상 호스트에 액세스하는 TLS 클라이언트에 가상 호스트를 식별하는 데 사용되는 인증서/키 쌍이 포함됩니다. 이 예에서는 트러스트스토어가 필요하지 않습니다.

양방향 TLS 구성과 같이 트러스트 저장소가 필요한 경우 <TrustStore> 태그를 사용하여 트러스트 저장소를 지정합니다.

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>apiTLS.myCompany.com</HostAlias> 
    </HostAliases> 
    <Interfaces/> 
    <Port>9006</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://keystoreref</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://truststoreref</TrustStore>
    </SSLInfo>
</VirtualHost>

이 예에서 <TrustStore> 태그는 키 저장소만 참조하며 특정 별칭을 지정하지 않습니다. 키 저장소의 각 별칭에는 TLS 핸드셰이크 프로세스의 일부로 사용되는 인증서 또는 인증서 체인이 포함됩니다.

지원되는 인증서 형식

형식 API 및 UI 업로드 지원 Northbound 지원됨 확인 완료
PEM 예 예 예
* PKCS12 예 예 예
참고: Apigee는 내부적으로
PKCS12를 PEM으로 변환합니다.
* DER 아니요 아니요 예
* PKCS7 아니요 아니요 아니요

* 가능하면 PEM을 사용하는 것이 좋습니다.

프라이빗 클라우드용 Edge 4.53.00 이상에서 PKCS12 키 저장소 사용

프라이빗 클라우드용 Edge 4.53.00 이상을 사용하는 경우 PKCS12 키 저장소만 사용하여 키와 관련 인증서를 Apigee에 업로드해야 합니다. 기존 키와 인증서를 PKCS12/PFX 형식으로 변환하는 데 도움이 필요한 경우 인증서를 지원되는 형식으로 변환을 참고하세요.

별칭 구현 정보

Edge에서 키 저장소에는 하나 이상의 별칭이 포함되며 각 별칭에는 다음이 포함됩니다.

  • PEM 또는 PKCS12/PFX 파일로 된 TLS 인증서 - 인증 기관 (CA)에서 서명한 인증서, 마지막 인증서가 CA에서 서명한 인증서 체인이 포함된 파일 또는 자체 서명된 인증서
  • 비공개 키(PEM 또는 PKCS12/PFX 파일) Edge는 최대 2,048비트의 키 크기를 지원합니다. 암호는 선택사항입니다.

Edge에서 신뢰 저장소에는 하나 이상의 별칭이 포함되며 각 별칭에는 다음이 포함됩니다.

  • PEM 파일로 된 TLS 인증서 - 인증 기관(CA)에서 서명한 인증서, 마지막 인증서가 CA에서 서명한 인증서 체인 또는 자체 서명된 인증서

Edge는 키 저장소를 만들고, 별칭을 만들고, cert/key 쌍을 업로드하고, cert를 업데이트하는 데 사용하는 UI 및 API를 제공합니다. 트러스트스토어를 만드는 데 사용하는 UI 및 API는 키 저장소를 만드는 데 사용하는 것과 동일합니다. 차이점은 트러스트 스토어를 만들 때는 인증서만 포함된 별칭을 만드는 것입니다.

인증서 및 키 파일 형식 정보

인증서와 키를 PEM 파일 또는 PKCS12/PFX 파일로 나타낼 수 있습니다. PEM 파일은 X.509 형식을 준수합니다. 인증서 또는 비공개 키가 PEM 파일로 정의되지 않은 경우 openssl와 같은 유틸리티를 사용하여 PEM 파일로 변환할 수 있습니다.

하지만 많은 .crt 파일과 .key 파일이 이미 PEM 형식입니다. 이러한 파일이 텍스트 파일이며 다음으로 묶여 있는 경우:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

또는:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

그러면 파일이 PEM 형식과 호환되며 PEM 파일로 변환하지 않고도 키 저장소 또는 신뢰 저장소에서 사용할 수 있습니다.

인증서 체인 정보

인증서가 체인의 일부인 경우 인증서가 키 저장소에서 사용되는지 또는 트러스트 저장소에서 사용되는지에 따라 다르게 처리합니다.

  • Keystore - 인증서가 체인의 일부인 경우 체인의 모든 인증서가 포함된 단일 파일을 만들어야 합니다. 인증서는 순서대로 있어야 하며 마지막 인증서는 루트 인증서이거나 루트 인증서로 서명된 중간 인증서여야 합니다.
  • 트러스트 저장소 - 인증서가 체인의 일부인 경우 모든 인증서가 포함된 단일 파일을 만들어 해당 파일을 별칭으로 업로드하거나, 각 인증서에 서로 다른 별칭을 사용하여 체인의 모든 인증서를 트러스트 저장소에 업로드합니다. 인증서를 단일 인증서로 업로드하는 경우 인증서가 순서대로 있어야 하며 마지막 인증서는 루트 인증서 또는 루트 인증서로 서명된 중간 인증서여야 합니다.
  • 여러 인증서가 포함된 단일 파일을 만드는 경우 각 인증서 사이에 빈 줄을 삽입해야 합니다.

예를 들어 모든 인증서를 단일 PEM 파일로 결합할 수 있습니다. 인증서는 순서대로 있어야 하며 마지막 인증서는 루트 인증서이거나 루트 인증서로 서명된 중간 인증서여야 합니다.

-----BEGIN CERTIFICATE----- 
(Your Primary TLS certificate) 
-----END CERTIFICATE----- 

-----BEGIN CERTIFICATE----- 
(Intermediate certificate) 
-----END CERTIFICATE-----
 
-----BEGIN CERTIFICATE----- 
(Root certificate or intermediate certificate signed by a root certificate) 
-----END CERTIFICATE-----

인증서가 PKCS12/PFX 파일로 표시되는 경우 openssl 명령어를 사용하여 아래와 같이 인증서 체인에서 PKCS12/PFX 파일을 만들 수 있습니다.

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

트러스트 스토어에서 인증서 체인을 사용할 때 체인의 모든 인증서를 업로드하지 않아도 되는 경우가 있습니다. 예를 들어 클라이언트 인증서 client_cert_1와 클라이언트 인증서 발급자의 인증서 ca_cert를 업로드합니다.

양방향 TLS 인증 중에 서버가 TLS 핸드셰이크 프로세스의 일부로 클라이언트에 client_cert_1를 전송하면 클라이언트 인증이 성공합니다.

또는 동일한 인증서 ca_cert로 서명된 두 번째 인증서 client_cert_2가 있습니다. 하지만 client_cert_2는 트러스트 저장소에 업로드하지 않습니다. 트러스트 스토어에는 여전히 client_cert_1 및 ca_cert만 포함되어 있습니다.

서버가 TLS 핸드셰이크의 일부로 client_cert_2를 전달하면 요청이 성공합니다. 이는 Edge에서 client_cert_2가 트러스트 스토어에 없지만 트러스트 스토어에 있는 인증서로 서명된 경우 TLS 인증에 성공하도록 허용하기 때문입니다. 트러스트 스토어에서 CA 인증서 ca_cert를 삭제하면 TLS 확인에 실패합니다.

FIPS 고려사항

FIPS 지원 운영체제에서 프라이빗 클라우드용 Edge 4.53.00 이상을 사용하는 경우 PKCS12 키 저장소만 사용하여 키와 관련 인증서를 Apigee에 업로드해야 합니다.

TLS 키 저장소 페이지 살펴보기

아래 설명에 따라 TLS 키 저장소 페이지에 액세스합니다.

Edge

Edge UI를 사용하여 TLS 키 저장소 페이지에 액세스하려면 다음 단계를 따르세요.

  1. 조직 관리자로 https://apigee.com/edge에 로그인합니다.
  2. 조직을 선택합니다.
  3. 관리 > 환경 > TLS 키 저장소를 선택합니다.

기존 Edge (프라이빗 클라우드)

기존 Edge UI를 사용하여 TLS 키 저장소 페이지에 액세스하려면 다음 단계를 따르세요.

  1. 조직 관리자로 http://ms-ip:9000에 로그인합니다. 여기서 ms-ip는 관리 서버 노드의 IP 주소 또는 DNS 이름입니다.
  2. 조직을 선택합니다.
  3. 관리 > 환경 구성 > TLS 키 저장소를 선택합니다.

TLS 키 저장소 페이지가 표시됩니다.

앞의 그림에 강조표시된 것처럼 TLS 키 저장소 페이지에서 다음을 수행할 수 있습니다.

별칭 보기

별칭을 보려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 환경을 선택합니다(일반적으로 prod 또는 test).
  3. 보려는 별칭과 연결된 행을 클릭합니다.

    별칭 인증서 및 키의 세부정보가 표시됩니다.

    만료일을 비롯하여 별칭에 관한 모든 정보를 확인할 수 있습니다.

  4. 페이지 상단의 버튼을 사용하여 다음과 같이 인증서를 관리합니다.
    • 인증서를 PEM 파일로 다운로드합니다.
    • CSR을 생성합니다. 만료된 인증서를 갱신하려면 인증서 서명 요청 (CSR)을 다운로드하면 됩니다. 그런 다음 CSR을 CA로 전송하여 새 인증서를 가져옵니다.
    • 인증서를 업데이트합니다. 주의: 현재 가상 호스트 또는 대상 서버/대상 엔드포인트에서 사용 중인 인증서를 업데이트하는 경우 Apigee Edge 지원팀에 문의하여 라우터와 메시지 프로세서를 다시 시작해야 합니다. 인증서를 업데이트하는 권장 방법은 다음과 같습니다.
      1. 새 키 저장소 또는 트러스트 저장소를 만듭니다.
      2. 새 인증서를 새 키 저장소 또는 트러스트 저장소에 추가합니다.
      3. 가상 호스트 또는 대상 서버/대상 엔드포인트의 참조를 키 저장소 또는 트러스트 저장소로 업데이트합니다. 자세한 내용은 Cloud의 TLS 인증서 업데이트를 참고하세요.
      4. 별칭을 삭제합니다. 참고: 현재 가상 호스트 또는 대상 엔드포인트에서 사용 중인 별칭을 삭제하면 가상 호스트 또는 대상 엔드포인트가 실패합니다.

키 저장소/트러스트 저장소 및 별칭 만들기

TLS 키 저장소 또는 TLS 신뢰 저장소로 사용할 키 저장소를 만들 수 있습니다. 키 저장소는 테스트 또는 프로덕션 환경과 같이 조직의 특정 환경에만 적용됩니다. 따라서 키 저장소를 프로덕션 환경에 배포하기 전에 테스트 환경에서 테스트하려면 두 환경 모두에서 키 저장소를 만들어야 합니다.

환경에서 키 저장소를 만들려면 키 저장소 이름만 지정하면 됩니다. 환경에서 이름이 지정된 키 저장소를 만든 후 별칭을 만들고 인증서/키 쌍(키 저장소)을 업로드하거나 별칭에 인증서만 (트러스트 저장소) 업로드할 수 있습니다.

키 저장소를 만들려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 환경을 선택합니다(일반적으로 prod 또는 test).
  3. + 키 저장소를 클릭합니다.
  4. 키 저장소 이름을 지정합니다. 이름에는 영숫자 문자만 사용할 수 있습니다.
  5. 키 저장소 추가를 클릭합니다. 새 키 저장소가 목록에 표시됩니다.
  6. 다음 절차 중 하나를 사용하여 별칭을 추가합니다. 지원되는 인증서 파일 형식도 참고하세요.

인증서에서 별칭 만들기 (트러스트 저장소만 해당)

인증서에서 별칭을 만들려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 + 아이콘을 클릭합니다.
  3. 별칭 이름을 지정합니다.
  4. 인증서 세부정보에서 유형 드롭다운에서 인증서 전용을 선택합니다.
  5. 인증서 파일 옆에 있는 파일 선택을 클릭하고 인증서가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
  6. 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 원하는 경우 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
  7. 저장을 선택하여 인증서를 업로드하고 별칭을 만듭니다.

JAR 파일에서 별칭 만들기(키 저장소만 해당)

JAR 파일에서 별칭을 만들려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 + 아이콘을 클릭합니다.
  3. 별칭 이름을 지정합니다.
  4. 인증서 세부정보에서 유형 드롭다운에서 JAR 파일을 선택합니다.
  5. JAR 파일 옆에 있는 파일 선택을 클릭하고 인증서와 키가 포함된 JAR 파일로 이동한 다음 열기를 클릭합니다.
  6. 키에 비밀번호가 있는 경우 비밀번호를 지정합니다. 키에 비밀번호가 없는 경우 이 필드를 비워 둡니다.
  7. 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 원하는 경우 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
  8. 저장을 선택하여 키와 인증서를 업로드하고 별칭을 만듭니다.

인증서 및 키에서 별칭 만들기 (키 저장소만 해당)

인증서 및 키에서 별칭을 만들려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 + 아이콘을 클릭합니다.
  3. 별칭 이름을 지정합니다.
  4. 인증서 세부정보에서 유형 드롭다운에서 인증서 및 키를 선택합니다.
  5. 인증서 파일 옆에 있는 파일 선택을 클릭하고 인증서가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
  6. 키에 비밀번호가 있는 경우 키 비밀번호를 지정합니다. 키에 비밀번호가 없는 경우 이 필드를 비워 둡니다.
  7. 키 파일 옆에 있는 파일 선택을 클릭하고 키가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
  8. 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 원하는 경우 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
  9. 저장을 선택하여 키와 인증서를 업로드하고 별칭을 만듭니다.

PKCS12/PFX 파일에서 별칭 만들기 (키 저장소만 해당)

인증서와 키가 포함된 PKCS12 파일에서 별칭을 만들려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 + 아이콘을 클릭합니다.
  3. 별칭 이름을 지정합니다.
  4. 인증서 세부정보에서 유형 드롭다운에서 PKCS12/PFX를 선택합니다.
  5. PKCS12/PFX 옆에 있는 파일 선택을 클릭하고 키와 인증서가 포함된 파일로 이동한 후 열기를 클릭합니다.
  6. 키에 비밀번호가 있는 경우 PKCS12/PFX 파일의 비밀번호를 지정합니다. 키에 비밀번호가 없는 경우 이 입력란을 비워 둡니다.
  7. 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 원하는 경우 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
  8. 저장을 선택하여 파일을 업로드하고 별칭을 만듭니다.

자체 서명 인증서에서 별칭 만들기 (키 저장소만 해당)

자체 서명 인증서를 사용하는 별칭을 만들려면 인증서를 만드는 데 필요한 정보를 양식에 입력합니다. 그러면 Edge에서 인증서와 비공개 키 쌍을 만들고 별칭에 업로드합니다.

자체 서명 인증서로 별칭을 만드는 방법은 다음과 같습니다.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 + 아이콘을 클릭합니다.
  3. 별칭 이름을 지정합니다.
  4. 인증서 세부정보에서 유형 드롭다운에서 자체 서명 인증서를 선택합니다.
  5. 아래 표를 사용하여 양식을 작성합니다.
  6. 저장을 선택하여 인증서 및 비공개 키 쌍을 만들고 별칭에 업로드합니다.

생성된 인증서에는 다음과 같은 추가 필드가 표시됩니다.

  • 발급자
    인증서에 서명하고 발급한 법인입니다. 자체 서명 인증서의 경우 인증서를 만들 때 지정한 CN입니다.
  • 유효성
    인증서 유효 기간은 인증서 유효 기간 시작일과 인증서 유효 기간 종료일이라는 두 날짜로 표시됩니다. 둘 다 UTCTime 또는 GeneralizedTime 값으로 인코딩할 수 있습니다.

다음 표에서는 양식 필드를 설명합니다.

양식 입력란 설명 기본값 필수
별칭 이름 별칭 이름입니다. 최대 길이는 128자(영문 기준)입니다. 해당 사항 없음 예
키 크기 키 크기(비트)입니다. 기본값 및 최대값은 2,048비트입니다. 2048 아니요
서명 알고리즘 비공개 키를 생성하는 서명 알고리즘입니다. 유효한 값은 'SHA512withRSA', 'SHA384withRSA', 'SHA256withRSA' (기본값)입니다. SHA256withRSA 아니요
인증서 유효 기간(일) 인증서의 유효 기간(일)입니다. 0이 아닌 양의 값을 허용합니다. 365 아니요
공용이름 조직의 일반 이름(CN)은 인증서와 연결된 정규화된 도메인 이름을 식별합니다. 일반적으로 호스트와 도메인 이름으로 구성됩니다. 예를 들면 api.enterprise.apigee.com, www.apigee.com 등이 있습니다. 최대 길이는 64자(영문 기준)입니다.

인증서 유형에 따라 CN은 동일한 도메인 (예: example.com, www.example.com)에 속한 하나 이상의 호스트 이름, 와일드 카드 이름 (예: *.example.com) 또는 도메인 목록일 수 있습니다. 프로토콜 (http:// 또는 https://), 포트 번호 또는 리소스 경로는 포함하지 마세요.

요청 호스트 이름이 인증서 일반 이름 중 하나 이상과 일치하는 경우에만 인증서가 유효합니다.

 해당 사항 없음 예
이메일 이메일 주소 최대 길이는 255자(영문 기준)입니다. 해당 사항 없음 아니요
조직 단위 이름 조직팀 이름입니다. 최대 길이는 64자(영문 기준)입니다. 해당 사항 없음 아니요
조직 이름 조직 이름 최대 길이는 64자(영문 기준)입니다. 해당 사항 없음 아니요
지역 시/군/구 이름입니다. 최대 길이는 128자(영문 기준)입니다. 해당 사항 없음 아니요
주/도 주/도 이름 최대 길이는 128자(영문 기준)입니다. 해당 사항 없음 아니요
국가 2자리 국가 코드입니다. 예를 들어 인도의 경우 IN, 미국의 경우 US입니다. 해당 사항 없음 아니요
대체 이름 대체 호스트 이름 목록입니다. 인증서의 주체에 추가 ID를 바인딩할 수 있습니다. 정의된 옵션에는 인터넷 전자우편 주소, DNS 이름, IP 주소, 통합 리소스 식별자 (URI)가 포함됩니다.

각 값은 최대 255자(영문 기준)까지 가능합니다. 이름을 쉼표로 구분하거나 각 이름 뒤에 Enter 키를 눌러 구분할 수 있습니다.

 해당 사항 없음 아니요

키 저장소 또는 트러스트 저장소 테스트

Edge UI에서 트러스트 스토어와 키 저장소를 테스트하여 올바르게 구성되었는지 확인할 수 있습니다. 테스트 UI는 Edge에서 백엔드 서비스로의 TLS 요청을 확인합니다. 백엔드 서비스는 단방향 또는 양방향 TLS를 지원하도록 구성할 수 있습니다.

단방향 TLS를 테스트하려면 다음 단계를 따르세요.

  1. TLS 키 저장소 페이지에 액세스합니다.
  2. 환경을 선택합니다(일반적으로 prod 또는 test).
  3. 테스트하려는 TLS 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 테스트를 클릭합니다. 다음과 같은 대화상자가 표시되어 트러스트스토어의 이름을 보여줍니다.
  4. 백엔드 서비스의 호스트 이름을 입력합니다.
  5. TLS 포트 번호 (일반적으로 443)를 입력합니다.
  6. 원하는 경우 프로토콜 또는 암호화 알고리즘을 지정합니다.
  7. 테스트를 선택합니다.

양방향 TLS를 테스트하려면 다음 단계를 따르세요.

  1. 원하는 트러스트 스토어의 테스트 버튼을 선택합니다.
  2. 대화상자에서 SSL 테스트 유형으로 양방향을 선택합니다. 다음 대화상자가 표시됩니다.
  3. 양방향 TLS에 사용되는 키 저장소의 이름을 지정합니다.
  4. 인증서와 키가 포함된 키 저장소에서 별칭 이름을 지정합니다.
  5. 백엔드 서비스의 호스트 이름을 입력합니다.
  6. TLS 포트 번호 (일반적으로 443)를 입력합니다.
  7. 원하는 경우 프로토콜 또는 암호화 알고리즘을 지정합니다.
  8. 테스트를 선택합니다.

양방향 TLS의 트러스트 스토어에 인증서 추가

Edge에 대한 API 요청을 의미하는 인바운드 연결에 양방향 TLS를 사용하는 경우 트러스트스토어에는 Edge에 요청할 수 있는 각 클라이언트의 인증서 또는 CA 체인이 포함됩니다.

트러스트스토어를 처음 구성할 때 알려진 클라이언트의 모든 인증서를 추가할 수 있습니다. 하지만 시간이 지남에 따라 새 클라이언트를 추가할 때 트러스트 스토어에 추가 인증서를 추가하는 것이 좋습니다.

양방향 TLS에 사용되는 트러스트 저장소에 새 인증서를 추가하려면 다음 단계를 따르세요.

  1. 가상 호스트에서 트러스트 저장소에 대한 참조를 사용하고 있는지 확인합니다.
  2. 위의 인증서에서 별칭 만들기 (트러스트 저장소만 해당)에 설명된 대로 새 인증서를 트러스트 저장소에 업로드합니다.

  3. 트러스트 저장소 참조를 업데이트하여 동일한 값으로 설정합니다. 이 업데이트를 통해 Edge에서 트러스트 저장소와 새 인증서를 새로고침합니다.

    자세한 내용은 참조 수정을 참고하세요.

키 저장소/트러스트 저장소 또는 별칭 삭제

키 저장소/신뢰 저장소 또는 별칭을 삭제할 때는 주의해야 합니다. 가상 호스트, 대상 엔드포인트 또는 대상 서버에서 사용 중인 키 저장소, 트러스트 저장소 또는 별칭을 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.

일반적으로 키 저장소/신뢰 저장소 또는 별칭을 삭제하는 프로세스는 다음과 같습니다.

  1. 위에서 설명한 대로 새 키 저장소/트러스트 저장소 또는 별칭을 만듭니다.
  2. Edge에 대한 API 요청을 의미하는 인바운드 연결의 경우 새 키 저장소 및 키 별칭을 참조하도록 가상 호스트 구성을 업데이트합니다.
  3. Apigee에서 백엔드 서버로의 아웃바운드 연결의 경우 다음을 실행합니다.
    1. 이전 키 저장소 및 키 별칭을 참조하는 모든 API 프록시의 TargetEndpoint 구성을 새 키 저장소 및 키 별칭을 참조하도록 업데이트합니다. TargetEndpoint가 TargetServer를 참조하는 경우 새 키 저장소 및 키 별칭을 참조하도록 TargetServer 정의를 업데이트합니다.
    2. 키 저장소와 트러스트 저장소가 TargetEndpoint 정의에서 직접 참조되는 경우 프록시를 다시 배포해야 합니다. TargetEndpoint가 TargetServer 정의를 참조하고 TargetServer 정의가 키 저장소와 트러스트 저장소를 참조하는 경우 프록시를 다시 배포할 필요가 없습니다.
  4. API 프록시가 올바르게 작동하는지 확인합니다.
  5. 키 저장소/트러스트 저장소 또는 별칭을 삭제합니다.

키 저장소 삭제

목록에서 키 저장소 또는 신뢰 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 를 클릭하면 키 저장소 또는 신뢰 저장소를 삭제할 수 있습니다. 가상 호스트 또는 대상 엔드포인트/대상 서버에서 사용 중인 키 저장소 또는 트러스트 저장소를 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.

주의: 새 키 저장소를 사용하도록 가상 호스트와 대상 엔드포인트/대상 서버를 변환할 때까지는 키 저장소를 삭제하면 안 됩니다.

별칭 삭제

목록에서 별칭 위로 커서를 이동하여 작업 메뉴를 표시하고 를 클릭하여 별칭을 삭제할 수 있습니다. 가상 호스트 또는 대상 엔드포인트/대상 서버에서 사용 중인 별칭을 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.

주의: 새 키 저장소와 별칭을 사용하도록 가상 호스트와 대상 엔드포인트/대상 서버를 변환할 때까지는 별칭을 삭제하면 안 됩니다.