Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Apigee 루트 CA 인증서 및 순환 정보

이 페이지는 Apigee에 적용되지만 Apigee Hybrid에는 적용되지 않습니다.

이 페이지에서는 Apigee 런타임에 대한 TLS 연결을 보호하는 Apigee 루트 인증 기관 (CA) 인증서를 설명하고 순환 프로세스를 설명합니다. 또한 순환의 영향을 받는 액세스 패턴과 애플리케이션을 준비하기 위해 취해야 하는 단계를 나열합니다.

루트 CA 인증서 정보

각 Apigee 조직에는 TLS 종료를 위해 Apigee 런타임 인그레스에서 사용하는 서버 인증서를 발급하는 Google 관리 루트 CA 인증서가 있습니다. 클라이언트가 Apigee 인스턴스에 대한 HTTPS 연결을 열면 서버는 이 루트 CA에 연결되는 인증서를 제공합니다. 서버 인증서를 검증하는 클라이언트는 TLS를 종료하는 고객 관리 부하 분산기를 통해 트래픽이 흐르는 경우 암시적으로 또는 클라이언트가 Apigee 런타임에 직접 연결하는 경우 명시적으로 루트 CA를 신뢰해야 합니다.

루트 CA 인증서는 caCertificates[] 필드의 organizations.get API 응답에 노출됩니다. 이 필드는 배열입니다. 순환 중에 현재 및 예정된 루트 CA 인증서가 모두 동시에 반환되므로 클라이언트가 전환 전에 둘 다 신뢰할 수 있습니다.

참고: 지원 중단된 caCertificate (단수) 필드는 인증서 하나만 반환하며 순환 중에 예정된 인증서를 표시하지 않습니다. caCertificate을 읽는 모든 도구를 caCertificates[]을 읽도록 업데이트합니다.

루트 CA 인증서를 순환하는 이유

Apigee 루트 CA 인증서의 유효 기간은 길지만 유한합니다(일반적으로 10년). 만료되기 전에 순환되므로 다음을 충족합니다.

Apigee 런타임을 보호하는 인증서는 사용 중에는 만료되지 않습니다.
Apigee 구성요소 간의 내부 통신 채널은 중단 없이 계속 작동합니다.

교체는 일상적이고 계획된 작업입니다. Apigee는 Google Cloud 관리하는 일정에 따라 실행합니다. 순환을 시작하지 않으며 순환 자체는 Apigee 런타임 엔드포인트나 Apigee API 노출 영역을 변경하지 않습니다.

순환 단계 및 일정

Apigee는 4단계로 루트 CA 인증서를 순환합니다. 각 단계는 점진적으로 진행됩니다. 조직 전체에 리전별로 적용되며 완료하는 데 시간이 걸립니다. 아래 표에는 각 단계의 고객에게 표시되는 효과와 현재 루트 CA의 만료일을 기준으로 측정한 일반적인 시작 시간이 설명되어 있습니다.

단계	일반적인 타이밍	`caCertificates[]`에 포함된 항목	변경사항
1. 새 인증서가 게시됨	현재 인증서가 만료되기 약 1년 전	현재 및 신규 (모두)	Apigee는 새 루트 CA 인증서를 생성하고 이를 모든 Apigee 소유 구성요소의 트러스트 저장소에 추가합니다. 새 인증서도 `organizations.get` 응답에 표시되므로 가져와서 스테이징할 수 있습니다. Apigee 런타임은 현재 루트 CA로 서명된 서버 인증서를 계속 제공하므로 기존 클라이언트는 아직 영향을 받지 않습니다. 이 단계가 시작되면 Apigee에서 고객 알림을 보냅니다.
2. 리프 인증서 전환	현재 인증서가 만료되기 약 60일 전	현재 및 신규 (모두)	Apigee 런타임이 새 루트 CA로 서명된 새 서버 (리프) 인증서를 표시하기 시작합니다. 현재 루트 CA만 신뢰하는 클라이언트는 이 단계가 해당 리전에서 완료된 후 TLS 유효성 검사에 실패합니다. 두 인증서를 모두 신뢰하는 클라이언트 (또는 새 인증서만 신뢰하는 클라이언트)는 계속 작동합니다. 이 단계가 시작되면 Apigee에서 고객 알림을 보냅니다.
3. 이전 인증서가 철회됨	현재 인증서가 만료되기 약 30일 전	신제품만	Apigee는 내부 신뢰 저장소에서 이전 루트 CA를 삭제하고 `organizations.get`에서 반환하지 않습니다. 여전히 이전 루트 CA만 신뢰하는 클라이언트는 연결할 수 없습니다. 이 단계가 시작되면 Apigee에서 고객 알림을 보냅니다.
4. 순환 완료	원래 만료일	신제품만	Apigee에서 이전 루트 CA를 영구적으로 삭제하고 순환이 완료됩니다. 이제 새 루트 CA가 유일한 루트 CA이며 새로운 10년 주기가 시작됩니다. 이 단계가 완료되면 Apigee에서 고객에게 알림을 보냅니다.

순환의 영향을 받는 사용자

순환에 조치가 필요한지 여부는 클라이언트가 Apigee 런타임에 도달하는 방식에 따라 달라집니다.

액세스 패턴	조치가 필요한가요?	이유
Google Cloud 외부 애플리케이션 부하 분산기를 사용하는 외부 라우팅 (MIG)	아니요	외부 부하 분산기가 사용자가 관리하는 인증서를 사용하여 TLS를 종료합니다. 클라이언트는 Apigee 루트 CA가 아닌 인증서를 신뢰합니다. 회전은 이러한 클라이언트에 영향을 주지 않습니다.
내부 라우팅 (VPC), TLS 옵션 1 (내부 HTTPS 애플리케이션 부하 분산기)	아니요	내부 부하 분산기가 사용자가 관리하는 인증서를 사용하여 TLS를 종료합니다. 클라이언트는 Apigee 루트 CA가 아닌 인증서를 신뢰합니다. 회전은 이러한 클라이언트에 영향을 주지 않습니다.
내부 라우팅 (VPC), TLS 옵션 2 (내부 기본 완전한 도메인 이름)	예	클라이언트는 Apigee에서 관리하는 내부 부하 분산기에 직접 연결하고 Apigee에서 발급한 서버 인증서를 검증합니다. 각 클라이언트는 순환 컷오버 전에 새 루트 CA를 신뢰해야 합니다.
런타임 인스턴스 수신 IP에 대한 직접 TCP 연결 (예: 내부 TCP 부하 분산기를 통해)	예	클라이언트가 Apigee에서 발급한 서버 인증서를 검증합니다. 각 클라이언트는 순환 컷오버 전에 새 루트 CA를 신뢰해야 합니다.
TLS가 아닌 옵션 (`curl` `-k` 플래그 또는 인증서 유효성 검사를 건너뛰는 클라이언트)	아니요	클라이언트가 서버 인증서를 검증하지 않으므로 순환이 기능에 미치는 영향이 없습니다. 이 옵션은 테스트 환경 외부에서는 권장되지 않습니다.

주의: 애플리케이션이 Apigee 루트 CA를 OS 트러스트 저장소, 애플리케이션 관리 트러스트 저장소, 사이드카 또는 서비스 메시 신뢰 번들에 저장하는 경우 로테이션 컷오버 전에 이러한 모든 트러스트 저장소에 새 루트 CA를 추가해야 합니다. 그렇지 않으면 전환 후 TLS 핸드셰이크가 실패하고 클라이언트에서 x509: certificate signed by unknown authority 또는 SSL_ERROR_BAD_CERT_DOMAIN와 같은 오류가 수신됩니다.

로테이션을 준비하는 방법

조치가 필요한 액세스 패턴 중 하나를 사용하는 경우 순환 알림에서 받은 순환 컷오버 날짜 전에 다음 단계를 따르세요.

기본 요건: 아래 명령줄 예시에는 시스템에 curl, jq, awk, base64, openssl 유틸리티가 설치되어 있어야 합니다.

1단계: Apigee 런타임 인스턴스 검색

조직의 Apigee 런타임 인스턴스를 나열합니다. 각 인스턴스에는 전용 인그레스 IP가 있습니다. 이 IP는 직접 연결 클라이언트가 도달하는 호스트입니다.

# Ensure $AUTH and $PROJECT_ID are set in your environment
curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances \
  | jq -r '.instances[] | "\(.name)\t\(.host)"'

클라이언트가 이러한 IP가 아닌 호스트 (예: 내부 부하 분산기 앞에 있는 자체 DNS 이름)에 연결하는 경우 해당 호스트를 대신 사용하세요.

2단계: 현재 및 예정된 루트 CA 인증서 가져오기

organizations.get에서 caCertificates[] 필드를 읽습니다. 순환 중에 이 배열에는 현재 루트 CA와 새 루트 CA가 모두 포함되며, 각각 base64로 인코딩됩니다.

curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID \
  | jq -r '.caCertificates[]' \
  | awk '/-----BEGIN/{i++}{print > ("ca_" i ".b64")}'

각 항목을 PEM 형식으로 디코딩하고 유효 기간을 검사하여 새 인증서를 식별합니다.

for f in ca_*.b64; do
  base64 -d "$f" > "${f%.b64}.crt"
  echo "==> ${f%.b64}.crt"
  openssl x509 -in "${f%.b64}.crt" -noout -subject -issuer -dates
done

notAfter 날짜가 늦은 인증서가 새 루트 CA입니다.

3단계: 신뢰 저장소에 새 루트 CA 추가

현재 Apigee 루트 CA를 신뢰하는 모든 클라이언트 트러스트 저장소에 새 루트 CA 인증서를 추가합니다. 컷오버가 완료될 때까지 현재 루트 CA를 그대로 유지하여 컷오버 기간 동안 연결이 계속 작동하도록 합니다. 전환 후 신뢰 저장소에서 이전 루트 CA를 삭제할 수 있습니다.

정확한 절차는 클라이언트에 따라 다릅니다. 일반적인 사례는 다음과 같습니다.

인증서를 OS 수준 트러스트 저장소에 추가합니다 (예: Debian 기반 시스템에서 /etc/ssl/certs/ 후 update-ca-certificates).
애플리케이션 관리 트러스트 저장소 (예: Java cacerts 키 저장소, Nginx ssl_trusted_certificate 번들 또는 Envoy validation_context 트러스트 번들)에 인증서를 추가합니다.
워크로드 포드에 마운트된 Kubernetes Secret 또는 ConfigMap에 인증서를 추가합니다.

4단계: 새 루트 CA로 연결이 작동하는지 확인

새 루트 CA를 스테이징한 후 새 인증서만 신뢰할 때 Apigee 런타임에 대한 HTTPS 요청이 성공하는지 확인합니다.

# Ensure $ENV_GROUP_HOSTNAME and $INTERNAL_LOAD_BALANCER_IP are set
curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert NEW_CA_FILE \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

이 명령어가 성공하면 클라이언트가 컷오버 준비를 마친 것입니다. 실패하면 클라이언트가 아직 새 루트 CA를 신뢰하지 않는 것이므로 3단계를 다시 확인하세요.

예: 내부 라우팅 (VPC), TLS 옵션 2

이 예시에서는 내부 라우팅 (VPC), TLS 옵션 2에 설명된 액세스 패턴의 순환 단계를 보여줍니다. 여기서 클라이언트는 Apigee 내부 부하 분산기에 직접 연결하고 Apigee 자체 서명 인증서를 검증합니다. 이는 로테이션의 영향을 가장 많이 받는 액세스 패턴입니다.

전환 전:

Apigee 내부 부하 분산기의 IP를 가져옵니다.

export INTERNAL_LOAD_BALANCER_IP=$(curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances -s \
  | jq -r '.instances[0].host')

현재 루트 CA와 새 루트 CA를 별도의 파일로 가져오고 새 루트 CA를 식별합니다.

curl -H "$AUTH" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID \
  | jq -r '.caCertificates[]' \
  | awk '/-----BEGIN/{i++}{print > ("ca_" i ".b64")}'

for f in ca_*.b64; do
  base64 -d "$f" > "${f%.b64}.crt"
done

# Identify the new root CA (latest notAfter):
openssl x509 -in ca_1.crt -noout -dates
openssl x509 -in ca_2.crt -noout -dates

현재 루트 CA와 새 루트 CA가 모두 포함된 결합된 신뢰 저장소를 빌드하고 테스트 요청에 사용합니다.
```
cat ca_1.crt ca_2.crt > cacert-combined.crt

curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert cacert-combined.crt \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP
```
이 요청이 성공하면 cacert-combined.crt를 클라이언트 신뢰 저장소로 배포합니다. 결합된 신뢰 저장소는 오늘 현재 인증서를 계속 검증하고 전환 후에는 새 인증서를 검증합니다.

컷오버 후 (일반적으로 컷오버일로부터 며칠 이내) 새 인증서만 신뢰할 때 연결이 여전히 성공하는지 확인하여 순환을 확인합니다.

curl -is -H "Host: $ENV_GROUP_HOSTNAME" \
  https://example.$PROJECT_ID.apigee.internal/PROXY_BASEPATH \
  --cacert NEW_CA_FILE \
  --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP

이 요청이 성공하면 트러스트 저장소에서 이전 루트 CA를 안전하게 삭제할 수 있습니다.

알림

Apigee는 각 순환 단계가 시작될 때 Google Cloud 프로젝트의 프로젝트 소유자와 조직 소유자에게 알림을 보냅니다. 각 알림에는 단계 이름, 조직에 단계가 적용되는 날짜, 이 페이지로 연결되는 링크가 포함됩니다.

알림	권장 고객 조치
1. 새 인증서 게시 (만료일 약 1년 전)	`caCertificates[]`에서 새 루트 CA를 가져와 현재 Apigee 루트 CA를 신뢰하는 모든 클라이언트 트러스트 저장소에 추가합니다. 순환 준비 방법을 참고하세요.
2. 리프 인증서 전환 (만료일 ~60일 전)	이 단계가 리전에 적용되기 전에 모든 클라이언트가 새 루트 CA를 신뢰하는지 확인하세요. 이 단계가 지나면 이전 루트 CA만 신뢰하는 클라이언트는 연결할 수 없습니다.
3. 오래된 인증서가 철회됨 (만료일 약 30일 전)	이 단계가 모든 지역에 적용되면 클라이언트 트러스트 저장소에서 이전 루트 CA를 안전하게 삭제할 수 있습니다.
4. 순환 완료 (원래 만료일)	어떤 조치도 필요하지 않습니다. 이전 루트 CA가 영구적으로 삭제되었으며 새 루트 CA가 조직의 유일한 루트 CA입니다.

순환 알림을 받지 못하고 순환의 영향을 받는 사용자에 나열된 액세스 패턴 중 하나를 사용하는 경우 Apigee 지원팀에 문의하여 조직의 알림 수신자를 확인하세요.

다음 단계

TLS 구성 옵션을 검토하여 Apigee의 모든 TLS 종료 옵션을 파악합니다.
전체 내부 액세스 호출 패턴은 내부 전용 액세스로 API 프록시 호출을 참고하세요.
caCertificates[] 필드의 전체 스키마는 organizations.get API 참조를 확인하세요.

Apigee 루트 CA 인증서 및 순환 정보 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

루트 CA 인증서 정보

루트 CA 인증서를 순환하는 이유

순환 단계 및 일정

순환의 영향을 받는 사용자

로테이션을 준비하는 방법

1단계: Apigee 런타임 인스턴스 검색

2단계: 현재 및 예정된 루트 CA 인증서 가져오기

3단계: 신뢰 저장소에 새 루트 CA 추가

4단계: 새 루트 CA로 연결이 작동하는지 확인

예: 내부 라우팅 (VPC), TLS 옵션 2

알림

다음 단계

Apigee 루트 CA 인증서 및 순환 정보