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

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

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

이 문서에서는 Private Cloud 버전 4.17.09 이하에서 Edge의 키 저장소와 트러스트 저장소를 생성, 수정, 삭제하는 방법을 설명합니다.

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

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

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

단방향 TLS에서는 클라이언트가 서버의 TLS 엔드포인트에 연결할 때 서버의 키 저장소가 서버의 인증서 (공개 인증서)를 클라이언트에 제공합니다. 그런 다음 클라이언트는 Symantec 또는 VeriSign과 같은 인증 기관 (CA)을 통해 인증서의 유효성을 검사합니다.

양방향 TLS에서는 클라이언트와 서버 모두 상호 인증에 사용되는 자체 인증서와 비공개 키가 있는 키 저장소를 유지합니다.
truststore에는 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 파일로 인증서만 포함하고 비공개 키는 없다는 점을 제외하면 키 저장소와 유사합니다.

인증서가 체인의 일부인 경우 키 저장소/truststore에는 체인의 모든 인증서가 개별 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

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

[ "freetrial" ]

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

Private Cloud 고객의 경우 첫 번째 키 저장소를 만들 때까지 반환된 배열은 비어 있습니다.

Get a Keystore or Truststore 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"
}

에지 관리 UI에서도 이 정보를 볼 수 있습니다.

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

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

Get Cert Details from a Keystore or Truststore 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"
}

에지 관리 UI에서도 이 정보를 볼 수 있습니다.

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

Edge UI에서는 Edge UI에서 인증서가 만료될 예정임을 미리 지정할 수 있습니다. 기본적으로 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 파일 업로드

환경에 키 저장소를 생성하려면 Create a Keystore or Truststore 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"
}

환경에서 이름이 지정된 키 저장소를 생성한 후 Upload a JAR file to a Keystore 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를 전달하면 요청이 성공합니다. 이는 client_cert_2가 트러스트 저장소에 존재하지 않지만 트러스트 저장소에 있는 인증서로 서명된 경우 Edge에서 TLS 확인을 성공하도록 허용하기 때문입니다. 트러스트 저장소에서 CA 인증서 ca_cert을 삭제하면 TLS 확인이 실패합니다.

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

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

Upload a Certificate to a 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 파일의 경로를 지정합니다.

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

Delete a Keystore or Truststore 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 호출이 실패합니다.