☰

다운타임 없이 Google 관리형 인증서로 마이그레이션하는 방법은 무엇인가요?

tag-icon • tag-icon ssl-certificate google-cloud-platform load-balancing google-compute-engine
다운타임 없이 Google 관리형 인증서로 마이그레이션하는 방법은 무엇인가요?

Google이 아닌 외부 호스팅 제공업체의 example.com을 GCP로 옮기려고 합니다.

로드 밸런서를 설정할 때 Google 관리형 인증서의 유효성을 검사하려면 example.com을 로드 밸런서로 지정해야 한다는 것을 알았습니다.

example.com의 A 레코드를 새 로드 밸런서의 (정적) IP로 변경하면 유효성이 검사됩니다.

문제는 example.com에 대한 트래픽이 이미 많다는 것입니다. example.com이 로드 밸런서를 가리키기 시작한 후 인증서가 검증되기 전에 발생하는 요청으로 인해 SSL 오류가 발생하고 사용자는 매우 불만스러워집니다.

이 문제를 해결한 사람이 있나요? 나는 방법이 있다는 것을 안다.다운타임을 방지하세요.회전인증서하지만 가동 중지 시간 없이 대규모 사이트를 마이그레이션할 수 있는 방법이 있어야 합니까?

답변1

다른 답변은 매우 훌륭하지만 기본적으로 인증서가 발급될 때까지 앉아서 기다리는 다운타임을 계획하지 않고 GCP 로드 밸런서로 마이그레이션할 수 있는 방법을 찾고자 하는 의욕이 매우 높았습니다. 이 질문에 트래픽이 많이 발생하고 일부 계획 및 테스트에서는 가동 중지 시간이 필요하지 않기 때문에 내 답변을 추가합니다.

내가 한 방법은 다음과 같습니다.

  1. example.com에 대한 임시 Let's Encrypt 인증서를 발급합니다.
  2. 인증서를 자체 관리형 인증서로 가져옵니다.
  3. 자체 관리형 인증서를 사용하도록 로드 밸런서를 설정합니다.
  4. 로드 밸런서를 가리키도록 DNS 레코드를 업데이트합니다.
  5. Google 관리형 인증서를 생성하고 이를두번째자체 관리형 인증서 옆에 있는 인증서입니다.
  6. Google 관리형 인증서가 될 때까지 기다립니다 ACTIVE. 시간이 오래 걸릴 수 있습니다. 자체 관리형 인증서가 없으면 가동 중지 시간이 발생합니다.
  7. 인증서가 모든 Google 프런트엔드(GFE)에 전파될 때까지 30분 동안 기다립니다.
  8. 이제 로드 밸런서에 두 개의 인증서가 할당되었습니다. Google 관리형 인증서만 사용하도록 업데이트하세요. 완료!

세부

문제를 요약하면 Google의 관리형 인증서에는 인증서가 이미 할당된 로드 밸런서를 가리키는 DNS 레코드가 필요합니다. 그렇지 않으면 발급되지 않습니다. 인증서 발급에 최대 1시간이 걸릴 수 있고 이 시간 동안 SSL 오류가 발생하는 것을 원하지 않기 때문에 이로 인해 문제가 발생합니다.

내가 찾은 해결 방법은 다음을 사용하는 것입니다.자체 관리형 인증서마이그레이션 중에 도메인이 GCP 로드 밸런서를 가리키고 인증서가 이미 발급된 경우 Google 관리형 인증서로 전환하세요.

나는 사용했다암호화하자인증서가 있지만 다른 인증서도 작동합니다. 이것의 이점은 우리가 이미 Let's Encrypt 인증서를 사용하고 있었기 때문에 걱정할 필요가 없었다는 것입니다.인증서 호환성.

다음은 제가 한 일의 단순화된 버전입니다. 로드 밸런서의 대상 프록시는 my-target-proxy, 인증서는 lb-certificate-letsencrypt및 이라고 합니다 lb-certificate-managed. 도메인 이름은 example.com및 입니다 subdomain.example.com.

전제 조건:

Let's Encrypt로 서명된 자체 관리형 인증서로 사용할 새 인증서를 생성합니다.

openssl genrsa -out letsencrypt.pem 2048

openssl 구성 파일을 만듭니다.

openssl.conf

[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
countryName               = Country Name (2 letter code)
stateOrProvinceName       = State or Province Name (full name)
localityName              = Locality Name (eg, city)
0.organizationName        = Organization Name (eg, company)
organizationalUnitName    = Organizational Unit Name (eg, section)
commonName                = Common Name (e.g. server FQDN or YOUR name)
emailAddress              = Email Address

[sans_list]
DNS.1                     = example.com
DNS.2                     = subdomain.example.com

생성인증서 서명 요청:

openssl req -new -key letsencrypt.pem -out letsencrypt.csr -config openssl.conf

Let's Encrypt에서 서명된 인증서를 받으세요.

certbot certonly --csr letsencrypt.csr --manual --preferred-challenges dns

소유권을 확인하려면 certbot에 표시된 DNS 레코드를 업데이트하세요. 다른 문제도 해결될 수 있지만 DNS는 가장 쉬운 것처럼 보였습니다.

어떤 파일이 전체 인증서 체인인지 기록해 두고 0003_chain.pem필요한 경우 예시를 바꾸세요.

전체 인증서 체인은 다음 위치에 저장됩니다.

GCP에서 자체 관리형 인증서를 업로드하고 만듭니다.

gcloud compute ssl-certificates create lb-certificate-letsencrypt \
  --certificate=0003_chain.pem \
  --private-key=letsencrypt.pem \
  --global

마이그레이션할 로드 밸런서를 생성하거나 자체 관리형 인증서를 사용하도록 구성합니다.

gcloud beta compute target-https-proxies create my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt [url-map and other options]
# Or
gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt

로드 밸런서의 IP를 가리키도록 DNS 레코드를 업데이트합니다. 이제 example.com 및 subdomain.example.com에 대한 TLS를 종료할 수 있습니다. 호스트 파일에 example.com에 대한 레코드를 추가하고 로드 밸런서 IP를 지정하여 이 단계를 테스트할 수 있습니다. John Hanley의 답변은 이에 대한 많은 좋은 조언을 제공합니다.

관리형 인증서를 만듭니다.

gcloud compute ssl-certificates create lb-certificate-managed \
  --domains=example.com,subdomain.example.com \
  --global

Google 관리형 인증서에서는 와일드카드가 지원되지 않으므로 사용 중인 모든 도메인을 나열해야 합니다.

대상 프록시에 할당함께자체 관리형 인증서로. 인증서는 프록시에 할당될 때까지 프로비저닝되지 않습니다.

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt,lb-certificate-managed

상태를 확인하세요.

gcloud compute ssl-certificates describe lb-certificate-managed

에서 - status로 변경될 때까지 기다리십시오 .PROVISIONINGACTIVE다른 상태조사해야 할 오류입니다. "Google 관리형 인증서를 프로비저닝하는 데 최대 60분이 걸릴 수 있습니다."문서에 따르면(Let's Encrypt는 몇 초 만에 동일한 작업을 수행합니다...)

로드 밸런서에서 사용할 수 있으려면 추가로 30분이 걸릴 수 있습니다.

그러므로,30분 기다려상태가 로 변경된 후 ACTIVE.

Google 관리 인증서만 사용하도록 대상 프록시를 업데이트합니다.

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-managed

새 설정이 적용되는 데 시간이 걸릴 수 있습니다. 브라우저에서 또는 openssl을 사용하여 엔드포인트에 대한 발급자를 확인합니다.

openssl s_client -connect example.com:443 -showcerts \
  -CAfile /etc/ssl/certs/ca-certificates.crt <<< Q

이제 발급자는 'Let's Encrypt'가 아닌 'Google Trust Services LLC'가 되어야 합니다.

이제 자체 관리형 Let's Encrypt 인증서를 제거하거나 관리형 인증서에 문제가 있는 경우 만료될 때까지 보관할 수 있습니다.

사용되지 않은 자체 관리형 Let's Encrypt 인증서를 정리하려면 다음을 실행하세요.

gcloud compute ssl-certificates delete lb-certificate-letsencrypt

답변2

가동 중지 시간이 발생합니다.

다음 팁에 따라 가동 중지 시간을 최소화할 수 있습니다. 적절한 계획을 세우면 가동 중지 시간이 매우 짧아지고 어떤 경우에는 자동 재시도를 통해 클라이언트가 이를 볼 수 없게 됩니다.

그러나 귀하의 사이트의 디자인, 쿠키의 사용, 인증, 세션 관리 등에 대해서는 알지 못하여 불가피한 중단이 있을 수 있습니다. 가능하다면 사이트 유지 관리에 앞서 고객에게 이메일을 보내 알려주는 것이 좋습니다.

지금은 로그를 검토하기에 좋은 시간입니다. IP 주소 액세스와 관련된 잠재적인 문제를 찾아보세요. 이러한 유형의 문제는 마이그레이션이 완료되고 이전 시스템을 종료한 후에 실패하기 시작합니다.

  1. DNS 리소스 레코드는 전역적으로 캐시된다는 점을 기억하세요. 리소스 레코드 TTL은 기간에 대한 힌트를 제공합니다. DNS 확인자는 TTL에 대한 자체 해석을 자유롭게 사용할 수 있습니다.

  2. 변경할 리소스 레코드의 TTL을 적어보세요. 이제 TTL을 1분과 같은 짧은 값으로 변경합니다.

  3. 최종 변경을 하기 전에 최소한 이전 TTL이 만료될 때까지 기다리십시오.

  4. DNS를 변경하기 전에 서비스와 로드 밸런서를 설정하세요. IP 주소만 사용하여 서비스가 올바르게 작동하는지 확인하세요. IP를 도메인으로 리디렉션하거나 HTTP를 HTTPS로 리디렉션하는 경우 해당 기능을 일시적으로 비활성화하고 나중에 활성화하십시오.

  5. 수동 모드에서 certbot을 사용하고 로드 밸런서에 로드할 수 있는 인증서를 만듭니다. 이렇게 하면 로드 밸런서가 SSL 인증서를 생성하고 확인을 기다리는 단계가 제거됩니다. 나중에 Google 관리형 SSL로 전환할 수 있습니다.

  6. Google Cloud 부하 분산기 HTTP 및 HTTPS 프런트엔드를 모두 구성합니다. 프런트엔드에서 Let's Encrypt SSL 인증서를 구성합니다.

  7. 마이그레이션 후 약 30일 동안 이전 사이트를 실행되도록 계획하세요. 일반적으로 마이그레이션 후 이전 사이트에서 몇 주 동안 트래픽이 발생합니다.

  8. 트래픽이 가장 적은 시간이나 요일을 선택합니다. 그런 다음 DNS 리소스 레코드를 전환합니다. 새 TTL이 캐싱에 사용되도록 이전 TTL 값이 만료되어야 한다는 점을 기억하세요.

  9. 며칠 후 모든 것이 작동하는지 확인한 후 TTL 값을 다음과 같은 일반적인 값으로 설정하십시오.604800이는 1주 또는 86400(1일)의 초 수입니다. 사용되는 경우 사이트 리디렉션(IP -> 도메인, HTTP -> HTTPS)을 다시 활성화합니다.

답변3

이전 제안 사항 외에도 리전 외부 HTTP(S) 부하 분산기와 내부 HTTP(S) 부하 분산기에는 Google 관리형 SSL 인증서가 지원되지 않는다는 점에 유의하세요. 이러한 로드 밸런서의 경우 자체 관리형 SSL 인증서를 사용해야 합니다. 어떤 유형의 로드 밸런서를 사용하고 있는지는 본 적이 없지만 이 마이그레이션을 설정하기 전에 먼저 고려해야 합니다. 또한, 이와 같은가이드Google 관리형 SSL 인증서를 만들고 사용하는 방법과 올바르게 작동하기 위한 고려사항을 확인할 수 있습니다.1.

모든 Google 프런트 엔드(GFE)에서 인증서를 사용할 수 있을 때까지 최대 30분이 걸릴 수 있으므로 이러한 변경 사항에 대한 유지 관리 기간을 설정하는 것이 좋습니다.

추가적으로,여기 이 동작에 도달하는 단계별 공식 가이드가 표시됩니다.

1 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

2 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#migating-ssl

관련 정보