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

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

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

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

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

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

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

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

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

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

 새 키 저장소, 별칭 또는 트러스트 저장소 이름과 함께 각 요청의 업데이트된 흐름 var를 전달합니다.

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

트러스트 저장소가 대상 엔드포인트/대상 서버에서 사용되는 경우 프록시를 다시 배포합니다.
직접 키 저장소 또는 트러스트 저장소를 삭제하고 동일한 이름으로 다시 생성합니다. 가상 호스트 업데이트가 필요하지 않으며 라우터를 다시 시작할 필요가 없습니다. 그러나 API 요청은 새 키 저장소와 별칭을 설정할 때까지 실패합니다.

Edge와 백엔드 서비스 간의 양방향 TLS에 키 저장소가 사용되는 경우 메시지 프로세서를 다시 시작합니다.
직접 트러스트 저장소의 경우에만 트러스트 저장소에 새 인증서를 업로드합니다. 가상 호스트에서 트러스트 저장소를 사용하는 경우 라우터를 다시 시작합니다.

대상 엔드포인트/대상 서버에서 truststore를 사용하는 경우 메시지 프로세서를 다시 시작합니다.

업데이트 전후에 인증서 테스트

업데이트하기 전에 다음 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. 키 저장소 및 Truststores에 설명된 대로 새 키 저장소를 만들고 인증서와 키를 업로드합니다. 새 키 저장소에서는 기존 키 저장소에 사용된 것과 동일한 키 별칭 이름을 사용해야 합니다.

    참고: 현재 키 저장소를 삭제하고 동일한 이름과 별칭으로 새 키 저장소를 생성할 수 있습니다. 라우터를 다시 시작할 필요가 없습니다. 그러나 API 요청은 새 키 저장소와 별칭을 설정할 때까지 실패합니다.
  2. 인바운드 연결에서 사용하는 가상 호스트(Edge에 대한 API 요청):
    1. 가상 호스트가 키 저장소에 대한 참조를 사용하는 경우 참조 작업에 설명된 대로 참조를 업데이트합니다.
    2. 가상 호스트에서 키 저장소의 직접적인 이름을 사용하는 경우:
      1. 이전 키 저장소 및 키 별칭을 참조한 모든 가상 호스트를 업데이트하여 새 키 저장소 및 키 별칭을 참조합니다.
      2. 한 번에 하나씩 라우터를 다시 시작합니다. 이전 키 저장소를 삭제하고 같은 이름으로 새 키 저장소를 생성한 경우 라우터를 다시 시작할 필요가 없습니다.

        프록시 재배포는 필요하지 않습니다.
  3. 아웃바운드 연결에 사용되는 대상 엔드포인트/대상 서버(Apigee에서 백엔드 서버로의 경우):
    1. 대상 엔드포인트/대상 서버가 키 저장소에 대한 참조를 사용하는 경우 참조 작업에 설명된 대로 참조를 업데이트합니다. 프록시 재배포는 필요하지 않습니다.
    2. 대상 엔드포인트/대상 서버가 흐름 변수를 사용하는 경우 흐름 변수를 업데이트합니다. 프록시 재배포는 필요하지 않습니다.
    3. 대상 엔드포인트/대상 서버가 키 저장소의 직접적인 이름을 사용하는 경우:
      1. 이전 키 저장소 및 키 별칭을 참조한 모든 API 프록시의 타겟 엔드포인트/대상 서버 구성이 새 키 저장소 및 키 별칭을 참조하도록 업데이트합니다.
      2. TargetEndpoint 정의에서 키 저장소를 참조하는 API 프록시의 경우 프록시를 다시 배포해야 합니다.

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

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

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

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

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

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