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

Apigee Edge 문서입니다.
Go to the Apigee X 문서로 이동합니다. info

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

  • 참조 - 권장
  • 직접 이름
  • 흐름 변수

다음 표에 설명된 것처럼 이러한 각 방법이 인증서 업데이트 프로세스에 미치는 영향은 서로 다릅니다.

구성 유형 인증서 업데이트/교체 방법 가상 호스트, 대상 엔드포인트/대상 서버 업데이트 방법
참조 (권장) 키 저장소의 경우 새 이름 과 이전 별칭과 동일한 이름 으로 새 키 저장소를 만듭니다.

트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.

 키 저장소 또는 트러스트 저장소에 대한 참조를 업데이트합니다.

라우터 또는 메시지 프로세서를 다시 시작할 필요가 없습니다.
흐름 변수 (대상 엔드포인트만 해당) 키 저장소의 경우 새 이름 및 동일한 이름 또는 새 이름의 별칭으로 새 키 저장소를 만듭니다.

트러스트 저장소의 경우 새 이름으로 트러스트 저장소를 만듭니다.

 각 요청에서 업데이트된 흐름 변수를 새 키 저장소, 별칭 또는 트러스트 저장소의 이름으로 전달합니다.

라우터 또는 메시지 프로세서를 다시 시작할 필요가 없습니다.
직접성 새 키 저장소, 별칭, 트러스트 저장소를 만듭니다. 가상 호스트를 업데이트하고 라우터를 다시 시작합니다.

트러스트 저장소가 대상 엔드포인트/대상 서버에서 사용되는 경우 프록시를 다시 배포합니다.
직접성 키 저장소 또는 트러스트 저장소를 삭제하고 동일한 이름으로 다시 생성합니다. 가상 호스트를 업데이트할 필요가 없으며 라우터를 다시 시작할 필요도 없습니다. 하지만 새 키 저장소와 별칭이 설정될 때까지 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의 온프레미스 배포의 경우 다음 단계를 따르세요.

  1. 키 저장소 및 트러스트 저장소에 설명된 대로 새 키 저장소를 만들고 인증서와 키를 업로드합니다. 새 키 저장소에서 기존 키 저장소에 사용된 것과 동일한 이름으로 키 별칭을 사용해야 합니다.

    참고: 현재 키 저장소를 삭제하고 동일한 이름과 별칭으로 새 키 저장소를 만들 수 있습니다. 라우터를 다시 시작할 필요가 없습니다. 하지만 새 키 저장소 와 별칭이 설정될 때까지 API 요청이 실패합니다.
  2. 인바운드 연결, 즉 Edge로의 API 요청에 사용되는 가상 호스트의 경우 다음 단계를 따르세요.
    1. 가상 호스트가 키 저장소에 대한 참조를 사용하는 경우 참조 작업에 설명된 대로 참조를 업데이트합니다.
    2. 가상 호스트가 키 저장소의 직접 이름을 사용하는 경우 다음 단계를 따르세요.
      1. 이전 키 저장소 및 키 별칭을 참조한 가상 호스트를 업데이트하여 새 키 저장소 및 키 별칭을 참조합니다.
      2. 라우터를 한 번에 하나씩 다시 시작합니다. 이전 키 저장소를 삭제하고 동일한 이름으로 새 키 저장소를 만든 경우 라우터를 다시 시작할 필요가 없습니다.

        프록시를 다시 배포할 필요가 없습니다.
  3. 아웃바운드 연결, 즉 Apigee에서 백엔드 서버로의 연결에 사용되는 대상 엔드포인트/대상 서버의 경우 다음 단계를 따르세요.
    1. 대상 엔드포인트/대상 서버가 키 저장소에 대한 참조를 사용하는 경우 참조 작업에 설명된 대로 참조를 업데이트합니다. 프록시를 다시 배포할 필요가 없습니다.
    2. 대상 엔드포인트/대상 서버가 흐름 변수를 사용하는 경우 흐름 변수를 업데이트합니다. 프록시를 다시 배포할 필요가 없습니다.
    3. 대상 엔드포인트/대상 서버가 키 저장소의 직접 이름을 사용하는 경우 다음 단계를 따르세요.
      1. 이전 키 저장소 및 키 별칭을 참조한 API 프록시의 대상 엔드포인트/대상 서버 구성을 업데이트하여 새 키 저장소 및 키 별칭을 참조합니다.
      2. TargetEndpoint 정의에서 키 저장소를 참조하는 API 프록시의 경우 프록시를 다시 배포해야 합니다.

        TargetEndpoint가 TargetServer 정의를 참조하고 TargetServer 정의가 키 저장소를 참조하는 경우 프록시를 다시 배포할 필요가 없습니다.
      3. 키 저장소가 Edge와 백엔드 서비스 간의 양방향 TLS에 사용되고 동일한 이름으로 키 저장소를 삭제/다시 만든 경우 Edge 메시지 프로세서를 다시 시작해야 합니다.
  4. 새 키 저장소가 올바르게 작동하는지 확인한 후 위에서 설명한 대로 만료된 인증서와 키가 포함된 이전 키 저장소를 삭제합니다.

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

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

  • 새 인증서를 새 트러스트 저장소에 업로드할 때 별칭 이름은 트러스트 저장소에서 중요하지 않습니다.
  • 인증서가 체인의 일부인 경우 모든 인증서가 포함된 단일 파일을 만들어 해당 파일을 단일 별칭으로 업로드하거나, 각 인증서에 서로 다른 별칭을 사용하여 체인의 모든 인증서를 트러스트 저장소에 업로드 합니다.

키 저장소 및 트러스트 저장소의 직접 이름을 사용하는 경우 다음 단계를 따르세요.

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