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

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

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

이 문서에서는 Edge용 키 저장소 및 트러스트 저장소를 생성, 수정, 삭제하는 방법을 설명합니다. 4.18.01 이상 버전의 클라우드 및 Edge용 비공개 클라우드용

를 통해 개인정보처리방침을 정의할 수 있습니다.

참고: 아래 API 예시에서는 클라우드용 에지 관리 API: https://api.enterprise.apigee.com 프라이빗 클라우드 설치의 경우 해당 URL을 https://MS_IP:8080로 바꿉니다. 여기서 MS_IP는 관리 서버의 IP 주소입니다.

소개

TLS와 같이 공개 키 인프라를 사용하는 기능을 구성하려면 다음을 수행해야 합니다. 필요한 키와 디지털 인증서를 제공하는 키 저장소와 트러스트 저장소를 만듭니다.

키 저장소, truststore, 별칭에 관한 소개는 키 저장소 및 트러스트 저장소.

키 저장소 만들기

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

환경에서 키 저장소를 생성하려면 다음 안내를 따르세요.

이 섹션의 API 호출을 사용하여 키 저장소를 생성합니다.
별칭을 만들고 인증서/키 쌍을 별칭에 업로드합니다. 인증서를 업로드하는 방법과 키는 인증서/키 쌍의 형식을 기반으로 합니다. 다음 섹션에서는 업로드하는 방법을 설명합니다. 각 인증서/키 쌍의 유형을 포함합니다.
참고: 가능하면 키 및 인증서에 PEM 형식을 사용하는 것이 좋습니다. 자세한 내용은 지원되는 인증서 파일 형식을 참조하세요.

키 저장소를 생성하려면 키 저장소 이름을 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">
1. 이전 항목을 참조한 API 프록시의 TargetEndpoint 구성을 업데이트합니다. 새 키 저장소와 키 별칭을 참조할 키 저장소 및 키 별칭입니다. TargetEndpoint가 TargetServer를 참조하는 경우 새 키 저장소를 참조하도록 TargetServer 정의를 업데이트하세요. 키 별칭이 있습니다
2. keystore와 truststore가 TargetEndpoint에서 직접 참조되는 경우 프록시를 다시 배포해야 합니다. TargetEndpoint가 TargetServer 정의, TargetServer 정의는 키 저장소 및 트러스트 저장소를 사용하는 경우 프록시 재배포가 필요하지 않습니다.
3. API 프록시가 올바르게 작동하는지 확인합니다.
4. keystore/truststore 또는 별칭을 삭제합니다.

를 참조하세요. 자세한 내용은 별칭의 인증서 업데이트를 참조하세요.

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

키 저장소 또는 Truststore 삭제 API:

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}