이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Private Cloud 버전 4.17.09 이하의 키 저장소와 트러스트 저장소 만들기

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

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

키 저장소 및 트러스트 저장소 정보

키 저장소 및 트러스트 저장소는 TLS 암호화에 사용되는 보안 인증서의 저장소를 정의합니다. 두 프로토콜의 주요 차이점은 TLS 핸드셰이크 프로세스에서 사용되는 위치입니다.

키 저장소에는 TLS 핸드셰이크 중에 항목을 식별하는 데 사용되는 TLS 인증서와 비공개 키가 포함되어 있습니다.

단방향 TLS에서 클라이언트가 서버의 TLS 엔드포인트에 연결하면 서버의 키 저장소는 서버의 인증서 (공개 인증서)를 클라이언트에 제공합니다. 그런 다음 클라이언트는 Symantec 또는 VeriSign과 같은 인증 기관 (CA)에서 인증서를 확인합니다.

양방향 TLS에서 클라이언트와 서버 모두 상호 인증에 사용되는 자체 인증서 및 비공개 키가 포함된 키 저장소를 유지합니다.
트러스트 저장소에는 TLS 핸드셰이크의 일부로 수신된 인증서를 확인하는 데 사용되는 인증서가 포함됩니다.

단방향 TLS에서는 유효한 CA에서 인증서에 서명한 경우 신뢰 저장소가 필요하지 않습니다. TLS 클라이언트가 수신한 인증서가 유효한 CA에서 서명한 경우 클라이언트는 CA에 인증서 인증을 요청합니다. TLS 클라이언트는 일반적으로 트러스트 저장소를 사용하여 TLS 서버에서 수신한 자체 서명 인증서 또는 신뢰할 수 있는 CA에서 서명하지 않은 인증서의 유효성을 검사합니다. 이 시나리오에서 클라이언트는 신뢰할 수 있는 인증서로 트러스트 저장소를 채웁니다. 그런 다음 클라이언트가 서버 인증서를 수신하면 수신 인증서가 트러스트 저장소의 인증서와 비교하여 검증됩니다.

예를 들어 TLS 클라이언트가 서버가 자체 서명된 인증서를 사용하는 TLS 서버에 연결합니다. 자체 서명된 인증서이므로 클라이언트는 CA를 사용하여 인증할 수 없습니다. 대신 클라이언트는 서버의 자체 서명 인증서를 트러스트 저장소에 미리 로드합니다. 그런 다음 클라이언트가 서버에 연결하려고 하면 클라이언트는 트러스트 저장소를 사용하여 서버에서 수신한 인증서를 확인합니다.

양방향 TLS의 경우 TLS 클라이언트와 TLS 서버 모두 트러스트 저장소를 사용할 수 있습니다. Edge가 TLS 서버 역할을 할 때 양방향 TLS를 실행할 때는 트러스트 저장소가 필요합니다.

인증서는 인증 기관 (CA)에서 발급하거나 개발자가 생성한 비공개 키로 자체 서명할 수 있습니다. CA에 액세스할 수 있는 경우 CA에서 제공하는 키 생성 및 인증서 발급 안내를 따르세요. CA에 액세스할 수 없는 경우 openssl과 같이 공개적으로 제공되는 여러 무료 도구 중 하나를 사용하여 자체 서명된 인증서를 생성할 수 있습니다.

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

Edge에서 키 저장소에는 하나 이상의 JAR 파일이 포함되며 JAR 파일에는 다음이 포함됩니다.

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

트러스트 저장소는 PEM 파일로 인증서만 포함하고 비공개 키는 포함하지 않는다는 점을 제외하고 키 저장소와 유사합니다.

인증서가 체인의 일부인 경우 키 저장소/트러스트 저장소에 체인의 모든 인증서가 개별 PEM 파일 또는 단일 파일로 포함되어야 합니다. 단일 파일을 사용하는 경우 인증서는 파일의 첫 번째 인증서가 TLS에 사용된 인증서이고 그 뒤에 인증서 체인이 CA 인증서까지 순서대로 이어지는 순서로 있어야 합니다. 파일의 각 인증서 사이에 빈 줄을 삽입해야 합니다.

Edge는 키 저장소 및 신뢰 저장소를 만드는 데 사용하는 API를 제공합니다. 실제 API는 동일합니다. 차이점은 키 저장소를 만들 때 인증서와 비공개 키가 포함된 JAR 파일을 전달한다는 점입니다. 트러스트스토어를 만들 때는 인증서만 PEM 파일로 전달합니다.

인증서 및 키 파일 형식 정보

이 문서의 예에서는 X.509 형식을 준수하는 PEM 파일로 정의된 TLS 인증서 및 키를 보여줍니다. 인증서 또는 비공개 키가 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-----

기존 키 저장소에 대한 세부정보 가져오기

List Keystores and Truststores API를 사용하여 환경에 기존 키 저장소가 있는지 확인합니다.

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Cloud 고객의 경우 테스트 환경과 프로덕션 환경 모두에서 무료 체험판 조직에 기본 키 저장소가 제공됩니다. 두 환경 모두에서 이 호출에 대해 다음과 같은 결과가 표시됩니다.

[ "freetrial" ]

이 기본 키 저장소를 사용하여 API를 테스트하고 API를 프로덕션으로 푸시할 수 있지만 일반적으로 프로덕션에 배포하기 전에 자체 인증서와 키가 포함된 자체 키 저장소를 만듭니다.

프라이빗 클라우드 고객의 경우 첫 번째 키 저장소를 만들 때까지 반환된 배열이 비어 있습니다.

키 저장소 또는 신뢰 저장소 가져오기 API를 사용하여 키 저장소의 콘텐츠를 확인합니다. 클라우드 고객의 경우 Apigee Edge에서 무료 체험 계정에 제공하는 기본 인증서인 단일 서버 TLS 인증서가 표시됩니다.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

응답은 다음과 같이 표시됩니다.

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Edge 관리 UI에서도 이 정보를 확인할 수 있습니다.

https://enterprise.apigee.com (클라우드) 또는 http://<ms-ip>:9000 (온프레미스)의 Edge 관리 UI에 로그인합니다. 여기서 <ms-ip>는 관리 서버 노드의 IP 주소입니다.
Edge 관리 UI 메뉴에서 관리 > TLS 인증서를 선택합니다.

TLS 인증서 세부정보 가져오기

키 저장소 또는 트러스트 저장소에서 인증서 세부정보 가져오기 API를 사용하여 만료일 및 발급자와 같은 키 저장소의 TLS 인증서에 관한 세부정보를 볼 수 있습니다. 먼저 관심 있는 인증서의 이름을 가져옵니다. 이 예에서는 'freetrial'이라는 키 저장소의 정보를 가져옵니다.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

샘플 응답:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

그런 다음 certs 속성의 값을 사용하여 인증서 세부정보를 가져옵니다.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

샘플 응답:

{
 "certInfo" : [ {
   "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
   "isValid" : "Yes",
   "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=&quot;GoDaddy.com, Inc.&quot;, L=Scottsdale, ST=Arizona, C=US",
   "subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
   "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
   "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
   "version" : 3
 } ],
 "name" : "example.apigee.net.crt"
}

Edge 관리 UI에서도 이 정보를 확인할 수 있습니다.

https://enterprise.apigee.com (클라우드) 또는 http://<ms-ip>:9000 (온프레미스)의 Edge 관리 UI에 로그인합니다. 여기서 <ms-ip>는 관리 서버 노드의 IP 주소입니다.
Edge 관리 UI 메뉴에서 관리 > TLS 인증서를 선택합니다.

Edge UI에서 Edge가 인증서가 만료될 예정임을 얼마나 일찍 표시할지 지정할 수 있습니다. 기본적으로 UI는 향후 10일 이내에 만료될 예정인 인증서를 강조 표시합니다.

키 저장소 만들기

키 저장소는 조직의 환경(예: 테스트 또는 프로덕션 환경)에 따라 다릅니다. 따라서 키 저장소를 프로덕션 환경에 배포하기 전에 테스트 환경에서 테스트하려면 두 환경 모두에서 키 저장소를 만들어야 합니다.

키 저장소를 만드는 과정은 두 단계로 이루어집니다.

인증서와 비공개 키가 포함된 JAR 파일을 만듭니다.
키 저장소를 만들고 JAR 파일을 업로드합니다.

인증서 및 비공개 키가 포함된 JAR 파일 만들기

비공개 키, 인증서, 매니페스트가 포함된 JAR 파일을 만듭니다. JAR 파일에는 다음 파일과 디렉터리가 포함되어야 합니다.

/META-INF/descriptor.properties
myCert.pem
myKey.pem

참고: 키 저장소 JAR에는 인증서를 하나만 포함할 수 있습니다. 인증서 체인이 있는 경우 체인의 모든 인증서를 단일 PEM 파일에 추가해야 합니다. 여기서 마지막 인증서는 CA가 서명하고 각 인증서는 새 줄로 구분됩니다. 인증서는 올바른 순서로 PEM 파일에 추가되어야 합니다. 즉, 다음과 같습니다.

cert -> intermediate cert(1) -> intermediate cert(2) -> … -> root

키 쌍과 인증서가 포함된 디렉터리에 /META-INF라는 디렉터리를 만듭니다. 그런 다음 /META-INF에 다음 콘텐츠가 포함된 descriptor.properties라는 파일을 만듭니다.

certFile={myCertificate}.pem
keyFile={myKey}.pem

키 쌍과 인증서가 포함된 JAR 파일을 생성합니다.

jar -cf myKeystore.jar myCert.pem myKey.pem

JAR 파일에 descriptor.properties를 추가합니다.

jar -uf myKeystore.jar META-INF/descriptor.properties

키 저장소 만들기 및 JAR 파일 업로드

환경에서 키 저장소를 만들려면 키 저장소 또는 트러스트 저장소 만들기 API에 키 저장소 이름만 지정하면 됩니다. 이름에는 영숫자 문자만 사용할 수 있습니다.

curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password

샘플 응답:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

환경에서 이름이 지정된 키 저장소를 만든 후 키 저장소에 JAR 파일 업로드 API를 사용하여 인증서와 비공개 키가 포함된 JAR 파일을 업로드할 수 있습니다.

curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password

여기서 -F 옵션은 JAR 파일의 경로를 지정합니다.

이 호출에서는 두 개의 쿼리 매개변수를 지정합니다.

alias - 키 저장소에서 인증서와 키를 식별합니다. 가상 호스트를 만들 때는 인증서와 키를 별칭 이름으로 참조합니다.
password - 비공개 키의 비밀번호입니다. 비공개 키에 비밀번호가 없는 경우 이 매개변수를 생략합니다.

키 저장소가 올바르게 업로드되었는지 확인합니다.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

샘플 응답:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

트러스트 저장소 만들기

트러스트 저장소를 만드는 데 사용하는 API는 키 저장소를 만드는 데 사용되는 API와 동일합니다. 유일한 차이점은 인증서 파일을 JAR 파일 대신 PEM 파일로 전달한다는 점입니다.

인증서가 체인의 일부인 경우 체인의 모든 인증서를 트러스트 저장소에 별도로 업로드하거나 모든 인증서가 포함된 단일 파일을 만들어 파일의 각 인증서 사이에 새 줄을 포함해야 합니다. 최종 인증서는 일반적으로 인증서 발급기관에서 서명합니다. 예를 들어 트러스트 저장소에서 클라이언트 인증서 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 확인에 실패합니다.

키 저장소를 만드는 데 사용하는 것과 동일한 API인 키 저장소 또는 트러스트 저장소 만들기를 사용하여 환경에 빈 트러스트 저장소를 만듭니다.

curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Truststore에 인증서 업로드 API를 사용하여 인증서를 PEM 파일로 트러스트 저장소에 업로드합니다.

curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password

여기서 -F 옵션은 PEM 파일의 경로를 지정합니다.

키 저장소 또는 트러스트 저장소 삭제

키 저장소 또는 신뢰 저장소 삭제 API를 사용하여 키 저장소 또는 신뢰 저장소를 삭제할 수 있습니다.

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

샘플 응답:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

가상 호스트 또는 대상 엔드포인트/대상/서버에서 사용 중인 키 저장소 또는 트러스트 저장소를 삭제하면 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 모든 API 호출이 실패합니다.