<ph type="x-smartling-placeholder"></ph>
현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보
이 문서에서는 Edge용 키 저장소 및 트러스트 저장소를 생성, 수정, 삭제하는 방법을 설명합니다. 4.18.01 이상 버전의 클라우드 및 Edge용 비공개 클라우드용
를 통해 개인정보처리방침을 정의할 수 있습니다.소개
TLS와 같이 공개 키 인프라를 사용하는 기능을 구성하려면 다음을 수행해야 합니다. 필요한 키와 디지털 인증서를 제공하는 키 저장소와 트러스트 저장소를 만듭니다.
키 저장소, truststore, 별칭에 관한 소개는 키 저장소 및 트러스트 저장소.
키 저장소 만들기
키 저장소는 조직의 환경에 따라 다릅니다(예: 테스트 또는 프로덕션). 환경입니다 따라서 코드를 배포하기 전에 테스트 환경에서 키 저장소를 테스트하려는 경우 프로덕션 환경에 연결하려면 두 환경 모두에서 만들어야 합니다.
환경에서 키 저장소를 생성하려면 다음 안내를 따르세요.
- 이 섹션의 API 호출을 사용하여 키 저장소를 생성합니다.
- 별칭을 만들고 인증서/키 쌍을 별칭에 업로드합니다. 인증서를 업로드하는 방법과 키는 인증서/키 쌍의 형식을 기반으로 합니다. 다음 섹션에서는 업로드하는 방법을 설명합니다. 각 인증서/키 쌍의 유형을 포함합니다.
키 저장소를 생성하려면 키 저장소 이름을 Create a Keystore 또는 Truststore API로도 사용할 수 있습니다. 키 저장소 이름에는 영숫자 문자만 포함할 수 있습니다.
curl -X POST -u orgAdminEmail:password -H "Content-Type: text/xml" \ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores \ -d '<KeyStore name="myKeystore"/>'
샘플 응답:
{ "certs" : [ ], "keys" : [ ], "name" : "myKeystore" }
인증서와 키를 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
그런 다음 descriptor.properties라는 파일을
/META-INF
:
certFile={myCertificate}.pem keyFile={myKey}.pem
키 쌍과 인증서가 포함된 JAR 파일을 생성합니다.
jar -cf myKeystore.jar myCert.pem myKey.pem
descriptor.properties
추가 대상
JAR 파일에 추가합니다.
jar -uf myKeystore.jar META-INF/descriptor.properties
이제 JAR 또는 PKCS 파일에서 별칭을 만듭니다 API.
curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F file="@myKeystore.jar" -F password={key_pword} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=keycertjar"
여기서 -F 옵션은 JAR 파일의 경로를 지정합니다.
이 호출에서는 다음을 지정합니다.
alias_name
- 다음의 인증서 및 키를 식별합니다. 저장할 수 있습니다 가상 호스트를 만들 때 가상 호스트를 통해 인증서와 키를 별칭 이름입니다.key_pword
- 비공개 키의 비밀번호입니다. 생략 이 매개변수를 지정합니다.
키 저장소가 제대로 업로드되었는지 확인합니다.
curl -u orgAdminEmail:password -X GET\ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}
샘플 응답:
{ "certs" : [ "myCertificate" ], "keys" : [ "myKey" ], "name" : "myKeystore" }
인증서와 키를 PEM 파일로 업로드하세요.
인증서 및 키 PEM 파일 API에서 별칭을 만듭니다.
curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F keyFile="@server.key" -F certFile="@signed.crt" \ -F password={key_pword} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=keycertfile"
여기서 -F
옵션은 PEM 파일의 경로를 지정합니다.
이 호출에서는 다음을 지정합니다.
alias_name
- 다음의 인증서 및 키를 식별합니다. 저장할 수 있습니다 가상 호스트를 만들 때 가상 호스트를 통해 인증서와 키를 별칭 이름입니다.key_pword
- 비공개 키의 비밀번호입니다. 생략 이 매개변수를 지정합니다.
키 저장소가 제대로 업로드되었는지 확인합니다.
curl -u orgAdminEmail:password -X GET\ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}
샘플 응답:
{ "certs" : [ "myCertificate" ], "keys" : [ "myKey" ], "name" : "myKeystore" }
인증서와 키를 PKCS12/PFX로 업로드 파일
JAR 또는 PKCS 파일에서 별칭을 만듭니다 API.
curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" \ -F file="@myKeystore.p12" -F password={key_pword} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=pkcs12"
여기서 -F
옵션은 P12 파일의 경로를 지정합니다.
이 호출에서는 다음을 지정합니다.
alias_name
- 다음의 인증서 및 키를 식별합니다. 저장할 수 있습니다 가상 호스트를 만들 때 가상 호스트를 통해 인증서와 키를 별칭 이름입니다.key_pword
- 비공개 키의 비밀번호입니다. 생략 이 매개변수를 지정합니다.
키 저장소가 제대로 업로드되었는지 확인합니다.
curl -u orgAdminEmail:password -X GET\ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}
샘플 응답:
{ "certs" : [ "myCertificate" ], "keys" : [ "myKey" ], "name" : "myKeystore" }
자체 서명 인증서 만들기 및 업로드 열쇠
자체 서명된 인증서를 생성하여 자체 서명 인증서를 생성 API를 생성하여 별칭을 만듭니다. 키를 사용하여 별칭에 업로드할 수 있습니다. 다음 호출은 자체 서명 인증서를 만듭니다 이 호출을 수정하여 정보를 추가할 수 있습니다.
curl -u orgAdminEmail:password -X POST --header "Content-Type: application/json" \ -d "{ "alias": "selfsigned", "subject": { "commonName": "mycert" } }" \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?format=selfsignedcert"
응답은 다음과 같이 표시됩니다.
{ "alias": "selfsigned", "certsInfo": { "certInfo": [ { "basicConstraints": "CA:FALSE", "expiryDate": 1491497204000, "isValid": "Yes", "issuer": "CN=mycert", "publicKey": "RSA Public Key, 2048 bits", "serialNumber": "00:d1:b4:78:e1", "sigAlgName": "SHA256withRSA", "subject": "CN=mycert", "subjectAlternativeNames": [], "validFrom": 1459961204000, "version": 3 } ], "certName": "selfsigned-cert" }, "keyName": "selfsigned" }
트러스트 저장소 만들기
트러스트 저장소를 생성하는 데 사용하는 API는 키 저장소를 생성하는 데 사용하는 API와 동일합니다. 이 유일한 차이점은 인증서 파일만 PEM 파일로 트러스트 저장소에 업로드한다는 것입니다.
인증서가 체인의 일부인 경우 체인의 모든 인증서를 별도로 업로드해야 합니다. 모든 인증서가 포함된 단일 파일을 만듭니다. 빈 한 줄에 하나씩 입력합니다.
체인의 일부가 아닌 자체 서명 인증서를 여러 개 업로드하려면 다음을 사용합니다. 동일한 기법: 신뢰하려는 인증서가 여러 개 있는 경우 단일 파일로 업로드합니다.
최종 인증서는 일반적으로 인증서 발급기관에서 서명합니다. 예를 들어 트러스트 저장소, 클라이언트 인증서,client_cert_1, 클라이언트 인증서 발급기관의 ca_cert를 입력합니다.
양방향 TLS 인증 시 서버에서 client_cert_1을 TLS 핸드셰이크 프로세스의 일부로 클라이언트에 전달합니다.
또는 동일한 인증서인 ca_cert로 서명된 두 번째 인증서 client_cert_2가 있습니다. 하지만 client_cert_2를 truststore에 업로드하지는 않습니다. 트러스트 저장소에는 여전히 client_cert_1 및 ca_cert입니다.
서버가 TLS 핸드셰이크의 일부로 client_cert_2를 전달하면 요청이 성공합니다. 이것은 왜냐하면 Edge는 client_cert_2가 truststore에 있는 인증서로 서명되었습니다. CA를 삭제하는 경우 인증서, ca_cert를 제출하면 TLS 확인이 실패합니다.
Create a Keystore 또는 Truststore로 키 저장소를 만들 때 사용하는 것과 동일한 API입니다.
curl -u orgAdminEmail:password -X POST -H "Content-Type: text/xml" \ -d '<KeyStore name="myTruststore"/>' \ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores
트러스트 저장소를 만든 후 다음 명령어를 사용하여 인증서를 PEM 파일로 트러스트 저장소에 업로드합니다. 사용 인증서 PEM 파일 API에서 별칭을 만듭니다.
curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F certFile="@cert.pem" \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myTruststore/aliases?alias=myTruststore&format=keycertfile"
여기서 -F
옵션은 PEM 파일의 경로를 지정합니다.
기존 키 저장소 또는 트러스트 저장소
키 저장소 나열 및 Truststores API를 사용합니다.
curl -u orgAdminEmail:password -X GET \ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores
클라우드 고객의 경우 두 국가 모두 무료 체험판 조직에 기본 키 저장소가 제공됩니다. 테스트 및 프로덕션 환경에 적합합니다 두 경우 모두에 대해 이 호출에 대해 다음과 같은 결과가 표시됩니다. 환경:
[ "freetrial" ]
이 기본 키 저장소를 사용하여 API를 테스트하고 API를 프로덕션으로 푸시할 수 있지만, 일반적으로 자체 인증서와 키로 자체 키 저장소를 만든 후 있습니다
프라이빗 클라우드 고객의 경우 첫 번째 클러스터를 만들 때까지 반환된 배열은 비어 있습니다. keystore.
키 저장소 또는 Truststore API를 가져옵니다. 클라우드 고객의 경우, 단일 서버 TLS가 인증서: Apigee Edge가 무료 체험판 계정에 제공하는 기본 인증서입니다.
curl -u orgAdminEmail:password -X GET\ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/freetrial
응답은 다음과 같이 표시됩니다.
{ "certs" : [ "wildcard.apigee.net.crt" ], "keys" : [ "freetrial" ], "name" : "freetrial" }
별칭 세부정보 보기
다음을 사용하여 키 저장소의 모든 별칭 목록을 가져옵니다. 별칭 나열 API:
curl -u orgAdminEmail:password -X GET \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases"
응답은 다음과 같이 표시됩니다.
[ "alias1", "alias2", "alias3", ]
만료일 및 발급기관과 같은 별칭에 대한 모든 정보를 가져오려면 별칭 가져오기 API를 사용하고 별칭 이름을 지정합니다.
curl -u orgAdminEmail:password -X GET \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}"
응답은 다음과 같이 표시됩니다.
{ "alias": "alias1", "certsInfo": { "certInfo": [ { "basicConstraints": "CA:TRUE", "expiryDate": 1459371335000, "isValid": "No", "issuer": "EMAILADDRESS=foo@bar.com, CN=smg, OU=doc, O=Internet Widgits Pty Ltd, L=noho, ST=Some-State, C=AU", "publicKey": "RSA Public Key, 1024 bits", "serialNumber": "00:86:a0:9b:5b:91:a9:fe:92", "sigAlgName": "SHA256withRSA", "subject": "EMAILADDRESS=foo@bar.com, CN=smg, OU=doc, O=Internet Widgits Pty Ltd, L=noho, ST=Some-State, C=AU", "subjectAlternativeNames": [], "validFrom": 1456779335000, "version": 3 } ], "certName": "new\-cert" }, "keyName": "newssl20" }
별칭에 대한 인증서를 다운로드하려면 별칭 API용 인증서 내보내기
curl -u orgAdminEmail:password -X GET \ "https://api.enterprise.apigee.com/v1/e/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}/certificate"
응답은 다음과 같이 표시됩니다.
-----BEGIN CERTIFICATE----- MIIDojCCAwugAwIBAgIJAIagm1uRqf6SMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYD ... RBUkaTe/570sLHY0tvkIm5tEX36ESw== -----END CERTIFICATE-----
만료된 인증서를 갱신하려면 인증서 서명 요청 (CSR) 그런 다음 CSR을 CA로 보내 새 인증서를 얻습니다. 광고 서버에 대한 CSR를 생성하려면 별칭이 아닌 경우 별칭 API에 대한 CSR 생성:
curl -u orgAdminEmail:password -X GET \ "https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}/csr"
응답은 다음과 같이 표시됩니다.
-----BEGIN CERTIFICATE REQUEST----- MIIB1DCCAT0CAQAwgZMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRl ... RF5RMytbkxkvPxIE17mDKJH0d8aekv/iEOItZ+BtQg+EibMUkkjTzQ== -----END CERTIFICATE REQUEST-----
양방향 TLS용 트러스트 저장소에 인증서 추가
인바운드 연결(Edge에 대한 API 요청)에 양방향 TLS를 사용하는 경우 트러스트 저장소에는 Edge에 요청할 수 있는 클라이언트마다 인증서 또는 CA 체인이 포함됩니다.
트러스트 저장소를 처음 구성할 때 알려진 클라이언트의 모든 인증서를 추가할 수 있습니다. 그러나 시간이 지남에 따라 새 클라이언트를 추가할 때 트러스트 저장소에 인증서를 추가해야 할 수도 있습니다.
양방향 TLS에 사용되는 트러스트 저장소에 새 인증서를 추가하려면 다음 안내를 따르세요.
- 가상 호스트의 truststore에 대한 참조를 사용하고 있는지 확인하세요.
- 위의 설명에 따라 트러스트 저장소에 새 인증서를 업로드합니다. Truststore를 만듭니다.
트러스트 저장소 참조를 업데이트하여 동일한 값으로 설정합니다. 이 업데이트를 통해 Edge가 truststore와 새 인증서를 새로고침합니다.
자세한 내용은 참조 수정하기를 참고하세요.
keystore/truststore 또는 별칭 삭제
keystore/truststore 또는 별칭을 삭제할 때는 주의해야 합니다. 키 저장소를 삭제하면 가상 호스트, 대상 엔드포인트 또는 대상 서버에서 사용하는 트러스트 저장소 또는 별칭은 모두 가상 호스트 또는 대상 엔드포인트/대상 서버를 통한 API 호출이 실패합니다.
일반적으로 keystore/truststore 또는 별칭을 삭제하는 데 사용하는 프로세스는 다음과 같습니다.
- 위에 설명된 대로 새 keystore/truststore 또는 별칭을 생성합니다.
- 인바운드 연결, 즉 Edge에 대한 API 요청의 경우 새 키 저장소와 키 별칭을 참조하도록 가상 호스트 구성입니다.
- 아웃바운드 연결의 경우: Apigee에서 백엔드 서버로의 연결입니다.
<ph type="x-smartling-placeholder">
- </ph>
- 이전 항목을 참조한 API 프록시의 TargetEndpoint 구성을 업데이트합니다. 새 키 저장소와 키 별칭을 참조할 키 저장소 및 키 별칭입니다. TargetEndpoint가 TargetServer를 참조하는 경우 새 키 저장소를 참조하도록 TargetServer 정의를 업데이트하세요. 키 별칭이 있습니다
- keystore와 truststore가 TargetEndpoint에서 직접 참조되는 경우 프록시를 다시 배포해야 합니다. TargetEndpoint가 TargetServer 정의, TargetServer 정의는 키 저장소 및 트러스트 저장소를 사용하는 경우 프록시 재배포가 필요하지 않습니다.
- API 프록시가 올바르게 작동하는지 확인합니다.
- keystore/truststore 또는 별칭을 삭제합니다.
를 참조하세요. 자세한 내용은 별칭의 인증서 업데이트를 참조하세요.
키 저장소 또는 트러스트 저장소 삭제
curl -u orgAdminEmail:password -X DELETE \ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myKeystoreName
가상 호스트에서 사용 중인 키 저장소 또는 트러스트 저장소를 삭제하고 다시 만들면 API 프록시를 다시 배포해야 합니다.
별칭 삭제하기
별칭 삭제 API:
curl -u orgAdminEmail:password -X DELETE \ https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myKeystoreName/aliases/{alias_name}