Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info
이 문서에서는 Cloud용 Edge와 Private Cloud 버전 4.18.01 이상의 Edge의 키 저장소와 신뢰 저장소를 만들고 수정하고 삭제하는 방법을 설명합니다.
Edge Cloud의 키 저장소/트러스트 저장소 및 가상 호스트 정보
Edge Cloud용 키 저장소/신뢰 저장소를 만드는 프로세스에서는 가상 호스트 사용에 관한 모든 규칙을 따라야 합니다. 예를 들어 클라우드의 가상 호스트를 사용하면 다음과 같습니다.
- 가상 호스트는 TLS를 사용해야 합니다.
- 가상 호스트는 포트 443만 사용할 수 있습니다.
- 서명된 TLS 인증서를 사용해야 합니다. 서명되지 않은 인증서는 클라우드의 가상 호스트와 함께 사용할 수 없습니다.
- TLS 인증서로 지정된 도메인 이름은 가상 호스트의 호스트 별칭과 일치해야 합니다.
자세히 알아보기:
Edge에서 키 저장소 및 트러스트 저장소 구현
TLS와 같은 공개 키 인프라를 사용하는 기능을 구성하려면 필요한 키와 디지털 인증서가 포함된 키 저장소와 트러스트 저장소를 만들어야 합니다.
Edge에서 키 저장소와 신뢰 저장소는 모두 하나 이상의 별칭을 포함하는 키 저장소 항목으로 표시됩니다. 즉, Edge의 키 저장소와 신뢰 저장소 간에는 구현 차이가 없습니다.
키 저장소와 트러스트 저장소의 차이점은 포함된 항목의 종류와 TLS 핸드셰이크에서 사용되는 방식에서 비롯됩니다.
- 키 저장소 - 하나 이상의 별칭을 포함하는 키 저장소 항목입니다. 각 별칭에는 인증서/키 쌍이 포함됩니다.
- 트러스트 저장소 - 하나 이상의 별칭을 포함하는 키 저장소 항목으로, 각 별칭에는 인증서만 포함됩니다.
가상 호스트 또는 대상 엔드포인트에 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 for Private Cloud 4.53.00 이상에서 PKCS12 키 저장소 사용
Edge for Private Cloud 4.53.00 이상을 사용하는 경우 PKCS12 키 저장소만 사용하여 키와 관련 인증서를 Apigee에 업로드해야 합니다. 기존 키와 인증서를 PKCS12/PFX 형식으로 변환하는 데 도움이 필요한 경우 인증서를 지원되는 형식으로 변환을 참고하세요.
별칭 구현 정보
Edge에서 키 저장소에는 하나 이상의 별칭이 포함되며 각 별칭에는 다음이 포함됩니다.
- PEM 또는 PKCS12/PFX 파일 형식의 TLS 인증서 - 인증 기관 (CA)에서 서명한 인증서, 마지막 인증서가 CA에서 서명한 인증서 체인이 포함된 파일 또는 자체 서명 인증서
- 비공개 키(PEM 또는 PKCS12/PFX 파일) Edge는 최대 2048비트의 키 크기를 지원합니다. 암호는 선택사항입니다.
Edge에서 트러스트 저장소에는 하나 이상의 별칭이 포함되며 각 별칭에는 다음이 포함됩니다.
- TLS 인증서(PEM 파일) - 인증 기관(CA)에서 서명한 인증서, 마지막 인증서가 CA에서 서명한 인증서 체인 또는 자체 서명 인증서
Edge는 키 저장소를 만들고, 별칭을 만들고, 인증서/키 쌍을 업로드하고, 인증서를 업데이트하는 데 사용하는 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 파일로 변환하지 않고도 키 저장소나 트러스트 저장소에서 사용할 수 있습니다.
인증서 체인 정보
인증서가 체인의 일부인 경우 인증서가 키 저장소에 사용되는지 아니면 트러스트 저장소에 사용되는지에 따라 다르게 처리합니다.
- 키 저장소 - 인증서가 체인의 일부인 경우 체인의 모든 인증서가 포함된 단일 파일을 만들어야 합니다. 인증서는 순서대로 있어야 하며 마지막 인증서는 루트 인증서 또는 루트 인증서로 서명된 중간 인증서여야 합니다.
- 트러스트 저장소 - 인증서가 체인의 일부인 경우 모든 인증서가 포함된 단일 파일을 만들어 해당 파일을 별칭으로 업로드하거나, 각 인증서에 서로 다른 별칭을 사용하여 체인의 모든 인증서를 트러스트 저장소에 업로드합니다. 단일 인증서로 업로드하는 경우 인증서가 순서대로 있어야 하며 마지막 인증서는 루트 인증서 또는 루트 인증서로 서명된 중간 인증서여야 합니다.
- 인증서가 여러 개 포함된 단일 파일을 만드는 경우 각 인증서 사이에 빈 줄을 삽입해야 합니다.
예를 들어 모든 인증서를 하나의 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 for Private Cloud 4.53.00 이상을 사용하는 경우 PKCS12 키 저장소만 사용하여 키와 관련 인증서를 Apigee에 업로드해야 합니다.
TLS 키 저장소 페이지 살펴보기
아래 설명에 따라 TLS 키 저장소 페이지에 액세스합니다.에지
Edge UI를 사용하여 TLS 키 저장소 페이지에 액세스하려면 다음 단계를 따르세요.
- 조직 관리자로 https://apigee.com/edge에 로그인합니다.
- 조직을 선택합니다.
- 관리 > 환경 > TLS 키 저장소를 선택합니다.
클래식 에지 (프라이빗 클라우드)
기본 Edge UI를 사용하여 TLS 키 저장소 페이지에 액세스하려면 다음 단계를 따르세요.
- 조직 관리자로
http://ms-ip:9000에 로그인합니다. 여기서 ms-ip는 관리 서버 노드의 IP 주소 또는 DNS 이름입니다. - 조직을 선택합니다.
- 관리 > 환경 구성 > TLS 키 저장소를 선택합니다.
TLS 키 저장소 페이지가 표시됩니다.

앞의 그림에 강조표시된 것처럼 TLS 키 저장소 페이지에서 다음을 수행할 수 있습니다.
- 환경 선택
- 키 저장소 및 별칭 만들기
- 키 저장소 테스트 및 삭제
- 별칭 보기 및 삭제
별칭 보기
별칭을 보려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 환경을 선택합니다(일반적으로
prod또는test). - 보려는 별칭과 연결된 행을 클릭합니다.
별칭 인증서 및 키의 세부정보가 표시됩니다.

만료일을 포함한 별칭에 관한 모든 정보를 확인할 수 있습니다. - 페이지 상단의 버튼을 사용하여 인증서를 관리하여 다음 작업을 할 수 있습니다.
- 인증서를 PEM 파일로 다운로드합니다.
- CSR을 생성합니다. 만료된 인증서가 있고 이를 갱신하려면 인증서 서명 요청 (CSR)을 다운로드하면 됩니다. 그런 다음 CSR을 CA에 전송하여 새 인증서를 가져옵니다.
- 인증서를 업데이트합니다. 주의: 현재 가상 호스트 또는 대상 서버/대상 엔드포인트에서 사용 중인 인증서를 업데이트하는 경우 Apigee Edge 지원팀에 문의하여 라우터와 메시지 프로세서를 다시 시작해야 합니다. 인증서를 업데이트하는 데 권장되는 방법은 다음과 같습니다.
- 새 키 저장소 또는 트러스트 저장소를 만듭니다.
- 새 인증서를 새 키 저장소 또는 트러스트 저장소에 추가합니다.
- 가상 호스트 또는 대상 서버/대상 엔드포인트에서 키 저장소 또는 트러스트 저장소에 대한 참조를 업데이트합니다. 자세한 내용은 Cloud용 TLS 인증서 업데이트를 참고하세요.
- 별칭을 삭제합니다. 참고: 별칭을 삭제했는데 현재 가상 호스트 또는 대상 엔드포인트에서 사용 중인 경우 가상 호스트 또는 대상 엔드포인트가 실패합니다.
키 저장소/트러스트 저장소 및 별칭 만들기
TLS 키 저장소 또는 TLS 트러스트 저장소로 사용할 키 저장소를 만들 수 있습니다. 키 저장소는 조직의 환경(예: 테스트 또는 프로덕션 환경)에 따라 다릅니다. 따라서 프로덕션 환경에 배포하기 전에 테스트 환경에서 키 저장소를 테스트하려면 두 환경에서 모두 키 저장소를 만들어야 합니다.
환경에서 키 저장소를 만들려면 키 저장소 이름만 지정하면 됩니다. 환경에서 이름이 지정된 키 저장소를 만든 후 별칭을 만들고 인증서/키 쌍(키 저장소)을 업로드하거나 인증서만 (트러스트 저장소) 별칭에 업로드할 수 있습니다.
키 저장소를 만들려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 환경을 선택합니다(일반적으로
prod또는test). - + 키 저장소를 클릭합니다.
- 키 저장소 이름을 지정합니다. 이름에는 영숫자 문자만 사용할 수 있습니다.
- 키 저장소 추가를 클릭합니다. 새 키 저장소가 목록에 표시됩니다.
- 다음 절차 중 하나를 사용하여 별칭을 추가합니다. 지원되는 인증서 파일 형식도 참고하세요.
인증서에서 별칭 만들기 (트러스트 저장소만 해당)
인증서에서 별칭을 만들려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 +를 클릭합니다.
- 별칭 이름을 지정합니다.
- 인증서 세부정보의 유형 드롭다운에서 인증서 전용을 선택합니다.
- 인증서 파일 옆에 있는 파일 선택을 클릭하고 인증서가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
- 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 선택적으로 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
- 저장을 선택하여 인증서를 업로드하고 별칭을 만듭니다.
JAR 파일에서 별칭 만들기(키 저장소만 해당)
JAR 파일에서 별칭을 만들려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 +를 클릭합니다.
- 별칭 이름을 지정합니다.
- '인증서 세부정보'의 '유형' 드롭다운에서 JAR 파일을 선택합니다.
- JAR 파일 옆에 있는 파일 선택을 클릭하고 인증서와 키가 포함된 JAR 파일로 이동한 후 열기를 클릭합니다.
- 키에 비밀번호가 있는 경우 비밀번호를 지정합니다. 키에 비밀번호가 없는 경우 이 필드를 비워 둡니다.
- 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 선택적으로 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
- 저장을 선택하여 키와 인증서를 업로드하고 별칭을 만듭니다.
인증서 및 키에서 별칭 만들기 (키 저장소만 해당)
인증서와 키에서 별칭을 만들려면 다음을 실행하세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 +를 클릭합니다.
- 별칭 이름을 지정합니다.
- '인증서 세부정보'의 '유형' 드롭다운에서 인증서 및 키를 선택합니다.
- 인증서 파일 옆에 있는 파일 선택을 클릭하고 인증서가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
- 키에 비밀번호가 있는 경우 키 비밀번호를 지정합니다. 키에 비밀번호가 없는 경우 이 필드를 비워 둡니다.
- 키 파일 옆에 있는 파일 선택을 클릭하고 키가 포함된 PEM 파일로 이동한 후 열기를 클릭합니다.
- 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 선택적으로 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
- 저장을 선택하여 키와 인증서를 업로드하고 별칭을 만듭니다.
PKCS12/PFX 파일에서 별칭 만들기 (키 저장소만 해당)
인증서와 키가 포함된 PKCS12 파일에서 별칭을 만들려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 +를 클릭합니다.
- 별칭 이름을 지정합니다.
- 인증서 세부정보에서 유형 드롭다운의 PKCS12/PFX를 선택합니다.
- PKCS12/PFX 옆에 있는 파일 선택을 클릭하고 키와 인증서가 포함된 파일로 이동한 후 열기를 클릭합니다.
- 키에 비밀번호가 있는 경우 PKCS12/PFX 파일의 비밀번호를 지정합니다. 키에 비밀번호가 없으면 이 필드를 비워 둡니다.
- 기본적으로 API는 인증서가 만료되지 않았는지 확인합니다. 선택적으로 만료된 인증서 허용을 선택하여 유효성 검사를 건너뜁니다.
- 저장을 선택하여 파일을 업로드하고 별칭을 만듭니다.
자체 서명 인증서에서 별칭 만들기 (키 저장소만 해당)
자체 서명 인증서를 사용하는 별칭을 만들려면 인증서를 만드는 데 필요한 정보가 포함된 양식을 작성합니다. 그러면 Edge에서 인증서와 비공개 키 쌍을 만들어 별칭에 업로드합니다.
자체 서명 인증서에서 별칭을 만들려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 키 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고 +를 클릭합니다.
- 별칭 이름을 지정합니다.
- 인증서 세부정보의 유형 드롭다운에서 자체 서명 인증서를 선택합니다.
- 아래 표를 사용하여 양식을 작성합니다.
- 저장을 선택하여 인증서와 비공개 키 쌍을 만들고 별칭에 업로드합니다.
생성된 인증서에는 다음과 같은 추가 필드가 표시됩니다.
- 발급자
인증서에 서명하고 인증서를 발급한 항목입니다. 자체 서명 인증서의 경우 인증서를 만들 때 지정한 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자(영문 기준)입니다. | 해당 사항 없음 | 아니요 |
| 국가 | 두 글자 국가 코드입니다. 예를 들어 인도는 IN, 미국은 US입니다. | 해당 사항 없음 | 아니요 |
| 대체 이름 |
대체 호스트 이름 목록입니다. 인증서의 주체에 추가 ID를 바인딩할 수 있습니다. 정의된 옵션에는 인터넷 전자 메일 주소, DNS 이름, IP 주소, 균일한 리소스 식별자 (URI)가 포함됩니다.
각 값의 최대 길이는 255자(영문 기준)입니다. 이름은 쉼표로 구분하거나 각 이름 뒤에 Enter 키를 눌러 구분할 수 있습니다. |
해당 사항 없음 | 아니요 |
키 저장소 또는 트러스트 저장소 테스트
Edge UI에서 트러스트 저장소와 키 저장소를 테스트하여 올바르게 구성되었는지 확인할 수 있습니다. 테스트 UI는 Edge에서 백엔드 서비스로의 TLS 요청을 검증합니다. 백엔드 서비스는 단방향 또는 양방향 TLS를 지원하도록 구성할 수 있습니다.
단방향 TLS를 테스트하려면 다음 단계를 따르세요.
- TLS 키 저장소 페이지에 액세스합니다.
- 환경을 선택합니다(일반적으로
prod또는test). - 테스트할 TLS 키 저장소 위에 커서를 이동하여 작업 메뉴를 표시하고 테스트를 클릭합니다. 다음과 같은 대화상자가 표시되고 신뢰 저장소의 이름이 표시됩니다.

- 백엔드 서비스의 호스트 이름을 입력합니다.
- TLS 포트 번호 (일반적으로 443)를 입력합니다.
- 필요한 경우 프로토콜 또는 암호를 지정합니다.
- 테스트를 선택합니다.
양방향 TLS를 테스트하려면 다음 단계를 따르세요.
- 원하는 신뢰 저장소에서 테스트 버튼을 선택합니다.
- 대화상자에서 SSL 테스트 유형을 양방향으로 선택합니다.
다음 대화상자가 표시됩니다.

- 양방향 TLS에 사용되는 키 저장소의 이름을 지정합니다.
- 인증서와 키가 포함된 키 저장소의 별칭 이름을 지정합니다.
- 백엔드 서비스의 호스트 이름을 입력합니다.
- TLS 포트 번호 (일반적으로 443)를 입력합니다.
- 필요한 경우 프로토콜 또는 암호를 지정합니다.
- 테스트를 선택합니다.
양방향 TLS의 트러스트 저장소에 인증서 추가
인바운드 연결(Edge로의 API 요청)에 양방향 TLS를 사용하는 경우 트러스트 저장소에는 Edge에 요청을 보낼 수 있는 각 클라이언트의 인증서 또는 CA 체인이 포함됩니다.
신뢰 저장소를 처음 구성할 때 알려진 클라이언트의 모든 인증서를 추가할 수 있습니다. 하지만 시간이 지남에 따라 새 클라이언트를 추가할 때 트러스트 저장소에 인증서를 추가할 수 있습니다.
양방향 TLS에 사용되는 트러스트 저장소에 새 인증서를 추가하려면 다음 단계를 따르세요.
- 가상 호스트에서 트러스트 저장소에 대한 참조를 사용하고 있는지 확인합니다.
- 위의 인증서에서 별칭 만들기 (트러스트 저장소만 해당)에 설명된 대로 트러스트 저장소에 새 인증서를 업로드합니다.
트러스트 저장소 참조를 업데이트하여 동일한 값으로 설정합니다. 이 업데이트로 인해 Edge가 트러스트 저장소와 새 인증서를 새로고침합니다.
자세한 내용은 참조 수정을 참고하세요.
키 저장소/트러스트 저장소 또는 별칭 삭제
키 저장소/트러스트 저장소 또는 별칭을 삭제할 때는 주의해야 합니다. 가상 호스트, 대상 엔드포인트 또는 대상 서버에서 사용 중인 키 저장소, 트러스트 저장소 또는 별칭을 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.
일반적으로 키 저장소/신뢰 저장소 또는 별칭을 삭제하는 데 사용하는 프로세스는 다음과 같습니다.
- 위에 설명된 대로 새 키 저장소/트러스트 저장소 또는 별칭을 만듭니다.
- 인바운드 연결(Edge로의 API 요청)의 경우 새 키 저장소와 키 별칭을 참조하도록 가상 호스트 구성을 업데이트합니다.
- 아웃바운드 연결(Apigee에서 백엔드 서버로)의 경우 다음을 충족해야 합니다.
- 이전 키 저장소 및 키 별칭을 참조한 API 프록시의 TargetEndpoint 구성을 업데이트하여 새 키 저장소 및 키 별칭을 참조합니다. TargetEndpoint가 TargetServer를 참조하는 경우 새 키 저장소와 키 별칭을 참조하도록 TargetServer 정의를 업데이트합니다.
- 키 저장소와 트러스트 저장소가 TargetEndpoint 정의에서 직접 참조되는 경우 프록시를 다시 배포해야 합니다. TargetEndpoint가 TargetServer 정의를 참조하고 TargetServer 정의가 키 저장소와 트러스트 저장소를 참조하는 경우 프록시를 다시 배포할 필요가 없습니다.
- API 프록시가 올바르게 작동하는지 확인합니다.
- 키 저장소/트러스트 저장소 또는 별칭을 삭제합니다.
키 저장소 삭제
목록에서 키 저장소 또는 신뢰 저장소 위로 커서를 이동하여 작업 메뉴를 표시하고
를 클릭하면 키 저장소 또는 신뢰 저장소를 삭제할 수 있습니다. 가상 호스트 또는 대상 엔드포인트/대상 서버에서 사용 중인 키 저장소 또는 트러스트 저장소를 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.
주의: 가상 호스트와 대상 엔드포인트/대상 서버를 변환하여 새 키 저장소를 사용하기 전에는 키 저장소를 삭제하면 안 됩니다.
별칭 삭제
목록에서 별칭 위로 커서를 이동하여 작업 메뉴를 표시하고
를 클릭하면 별칭을 삭제할 수 있습니다. 가상 호스트 또는 대상 엔드포인트/대상 서버에서 사용 중인 별칭을 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.
주의: 새 키 저장소와 별칭을 사용하도록 가상 호스트와 대상 엔드포인트/대상 서버를 변환할 때까지는 별칭을 삭제하면 안 됩니다.