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

프라이빗 클라우드의 TLS 인증서 업데이트

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

가상 호스트 또는 대상 엔드포인트/대상 서버에서 키 저장소 및 트러스트 저장소의 이름을 지정하는 데 사용하는 방법은 인증서 업데이트 수행 방법을 결정합니다. 포드의 다음을 사용하여 keystore 및 truststore의 이름을 지정합니다.

참고 자료 - 권장
직접 이름
흐름 변수

이러한 각 메서드는 인증서 업데이트 프로세스에 다른 영향을 미칩니다. 자세한 내용은 다음 표를 참조하세요.

구성 유형	인증서 업데이트/교체 방법	가상 호스트, 대상 엔드포인트/대상 서버를 업데이트하는 방법
참조 (권장)	키 저장소의 경우 새 이름과 이전 별칭과 동일한 이름으로 새 키 저장소를 만듭니다. 트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.	키 저장소 또는 트러스트 저장소에 대한 참조를 업데이트합니다. 라우터 또는 메시지 프로세서를 다시 시작할 필요가 없습니다.
흐름 변수(대상 엔드포인트만 해당)	키 저장소의 경우 새 이름 및 동일한 이름 또는 새 이름의 별칭으로 새 키 저장소를 만듭니다. 트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.	각 요청에서 업데이트된 흐름 변수를 새 키 저장소, 별칭 또는 트러스트 저장소의 이름으로 전달합니다. 라우터 또는 메시지 프로세서를 다시 시작할 필요가 없습니다.
직접	새 키 저장소, 별칭, 트러스트 저장소를 만듭니다.	가상 호스트를 업데이트하고 라우터를 다시 시작합니다. 트러스트 저장소가 대상 엔드포인트/대상 서버에서 사용되는 경우 프록시를 다시 배포합니다.
직접성	키 저장소 또는 트러스트 저장소를 삭제하고 동일한 이름으로 다시 생성합니다.	가상 호스트를 업데이트할 필요도 없고 라우터를 다시 시작할 필요도 없습니다. 하지만 API 요청은 새 키 저장소와 별칭이 설정될 때까지만 유지됩니다. Edge와 백엔드 서비스 간의 양방향 TLS에 키 저장소가 사용되는 경우 다시 시작하세요. 메시지 프로세서의 역할을 합니다.
직접	트러스트 저장소의 경우에만 트러스트 저장소에 새 인증서를 업로드합니다.	트러스트 저장소를 가상 호스트에서 사용하는 경우 라우터를 다시 시작합니다. 대상 엔드포인트/대상 서버에서 트러스트 저장소를 사용하는 경우 메시지를 다시 시작합니다. 프로세서.

인증서 이전과 이후의 인증서 업데이트

업데이트하기 전에 다음 openssl 명령어를 사용하여 현재 인증서를 테스트합니다. 다음과 같습니다.

echo | openssl s_client -servername hostAlias -connect hostAlias.apigee.net:443 2>/dev/null | openssl x509 -noout -dates -subject

여기서 hostAlias는 가상 호스트 또는 IP 주소의 호스트 별칭입니다. 예를 들면 다음과 같습니다.

echo | openssl s_client -servername api.myCompany.com -connect api.myCompany.com:443 2>/dev/null | openssl x509 -noout -dates -subject

다음과 같은 형식으로 출력이 표시됩니다.

notBefore=Dec 30 22:11:38 2015 GMT
notAfter=Dec 30 22:11:38 2016 GMT
subject= /OU=Domain Control Validated/CN=*.apigee.net

인증서를 업데이트한 후 동일한 명령어를 사용하여 테스트합니다.

키 저장소의 TLS 인증서 업데이트

Edge의 온프레미스 배포의 경우:

새 키 저장소를 만들고 다음에 설명된 대로 인증서와 키를 업로드합니다. 키 저장소 및 트러스트 저장소. 새 키 저장소에서 키 별칭에 기존 키 저장소를 사용합니다

참고: 현재 키 저장소를 삭제하고 동일한 키 저장소로 새 키 저장소를 만들 수 있습니다. 확인할 수 있습니다 라우터를 다시 시작할 필요가 없습니다. 하지만 API 요청은 새 키 저장소가 별칭이 설정됩니다
인바운드 연결에서 사용하는 가상 호스트(API 요청) 다음과 같이 에지에 삽입하세요. <ph type="x-smartling-placeholder">
1. 가상 호스트가 키 저장소에 대한 참조를 사용하는 경우 참조를 다음과 같이 업데이트합니다. 합니다.
2. 가상 호스트가 키 저장소의 직접 이름을 사용하는 경우: <ph type="x-smartling-placeholder">
  1. 이전 키 저장소와 키 별칭을 참조한 모든 가상 호스트를 새 키 저장소와 키 별칭을 참조합니다.
  2. 라우터를 한 번에 하나씩 다시 시작합니다. 이전 키 저장소와 키 저장소를 삭제한 경우 같은 이름으로 새 키 저장소를 생성한 경우 라우터를 다시 시작할 필요가 없습니다.
    
    프록시를 다시 배포할 필요가 없습니다.
아웃바운드 연결에서 사용하는 대상 엔드포인트/대상 서버의 경우. 데이터를 Apigee에서 백엔드 서버로 이동할 수 있습니다 <ph type="x-smartling-placeholder">
1. 대상 엔드포인트/대상 서버가 키 저장소에 대한 참조를 사용하는 경우 참조 작업에 설명된 대로 참조에 포함해야 합니다. 프록시 재배포가 필요하지 않습니다.
2. 대상 엔드포인트/대상 서버가 흐름 변수를 사용하는 경우 흐름 변수를 업데이트합니다. 아니요 프록시 재배포가 필요합니다.
3. 대상 엔드포인트/대상 서버가 키 저장소의 직접 이름을 사용하는 경우: <ph type="x-smartling-placeholder">
  1. 대상 엔드포인트/대상 서버 구성을 이전 키 저장소와 키 별칭을 참조하여 새 키 저장소와 키를 참조함 별칭입니다.
  2. TargetEndpoint 정의에서 키 저장소를 참조하는 모든 API 프록시의 경우 프록시를 다시 배포해야 합니다.
    
    TargetEndpoint가 TargetServer 정의를 참조하고 TargetServer가 정의가 키 저장소를 참조하는 경우 프록시 재배포가 필요하지 않습니다.
  3. Edge와 백엔드 서비스 간의 양방향 TLS에 키 저장소가 사용되고 같은 이름으로 키 저장소를 삭제/다시 만든 경우 Edge를 다시 시작해야 합니다. 메시지 프로세서.
새 키 저장소가 올바르게 작동하는지 확인한 후 이전 키 저장소 키 저장소가 있어야 합니다.

트러스트 저장소에서 TLS 인증서 업데이트

truststore에 대한 참조를 사용하는 경우 truststore에서 인증서를 업데이트하는 프로세스 는 위에 표시된 키 저장소의 경우와 동일합니다. 유일한 차이점은 다음과 같습니다.

새 인증서를 새 트러스트 저장소에 업로드할 때 별칭 이름은 트러스트 저장소를 제공합니다
인증서가 체인의 일부인 경우 인증서를 사용하여 해당 파일을 단일 별칭에 업로드하거나 체인의 모든 인증서를 개별적으로 트러스트 저장소를 만들어야 합니다.

키 저장소와 트러스트 저장소의 직접 이름을 사용하는 경우:

다음에 설명된 대로 트러스트 저장소에 새 인증서를 업로드합니다. 키 저장소 및 트러스트 저장소. 이전 인증서를 삭제할 필요는 없습니다.
인바운드 연결에서 사용하는 가상 호스트(API 요청) 한 번에 하나씩 라우터를 다시 시작합니다.
아웃바운드 연결에서 사용하는 대상 엔드포인트/대상 서버의 경우 한 번에 하나씩 에지 메시지 프로세서를 있습니다.
새 트러스트 저장소가 올바르게 작동하는지 확인합니다.