☰

Como migrar para certificados gerenciados pelo Google sem tempo de inatividade?

tag-icon • tag-icon ssl-certificate google-cloud-platform load-balancing google-compute-engine
Como migrar para certificados gerenciados pelo Google sem tempo de inatividade?

Estou migrando example.com de um provedor de hospedagem externo (que não é do Google) para o GCP.

Ao configurar o balanceador de carga, percebi que preciso apontar example.com para o balanceador de carga para que o certificado gerenciado pelo Google seja validado.

Devo apenas alterar o registro A de example.com para o IP (estático) do novo balanceador de carga - então ele será validado.

O problema é que já tenho muito tráfego para example.com, solicitações que acontecem depois que example.com começa a apontar para o balanceador de carga, mas antes da validação do certificado gerarão erros de SSL e usuários muito insatisfeitos.

Alguém resolveu isso? Eu sei que existem maneiras deevite tempo de inatividade quandogirandocertificados, mas deve haver alguma maneira de migrar sites grandes sem tempo de inatividade?

Responder1

As outras respostas são muito boas, mas fiquei muito motivado para encontrar uma maneira de migrar para um balanceador de carga GCP sem planejar o tempo de inatividade, onde basicamente apenas sentamos e esperamos a emissão dos certificados. Adicionando minha própria resposta, já que esta pergunta recebeu muito tráfego e descobriu-se que o tempo de inatividade não é necessário com algum planejamento e testes.

Veja como eu fiz isso:

  1. Emita certificados Let's Encrypt temporários para example.com.
  2. Importe os certificados como certificados autogerenciados.
  3. Configure o balanceador de carga para usar os certificados autogerenciados.
  4. Atualize os registros DNS para apontar para o balanceador de carga.
  5. Crie certificados gerenciados pelo Google e atribua-os como umsegundocertificado, ao lado do certificado autogerenciado.
  6. Aguarde até que o certificado gerenciado pelo Google seja ACTIVE. Isso pode levar muito tempo. É aqui que haveria tempo de inatividade sem o certificado autogerenciado.
  7. Aguarde 30 minutos para que o certificado seja propagado para todos os Google Front Ends (GFEs).
  8. Agora há dois certificados atribuídos ao balanceador de carga. Atualize-o para usar apenas o certificado gerenciado pelo Google. Feito!

Detalhes

Para resumir o problema: os certificados gerenciados do Google exigem um registro DNS apontando para um balanceador de carga com o certificado já atribuído ou não serão emitidos. Isso cria um problema, pois a emissão do certificado pode levar até uma hora e não queremos erros de SSL durante esse período.

A solução alternativa que encontrei foi usarcertificados autogerenciadosdurante a migração e mudar para os certificados gerenciados pelo Google assim que nosso domínio apontasse para o balanceador de carga do GCP e os certificados já tivessem sido emitidos.

eu useiVamos criptografarcertificados, mas outros também funcionarão. Uma vantagem disso foi que já estávamos usando certificados Let's Encrypt, então não precisei me preocupar comcompatibilidade de certificado.

Aqui está uma versão simplificada do que fiz. O proxy de destino do balanceador de carga será chamado my-target-proxy, os certificados serão chamados lb-certificate-letsencrypte lb-certificate-managed. Os nomes de domínio são example.come subdomain.example.com.

Pré-requisitos:

Gere um novo certificado para usar como certificado autogerenciado, assinado por Let's Encrypt:

openssl genrsa -out letsencrypt.pem 2048

Crie um arquivo de configuração do 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

Gere umsolicitação de assinatura de certificado:

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

Obtenha um certificado assinado do Let's Encrypt:

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

Atualize os registros DNS indicados pelo certbot para verificar a propriedade. Outros desafios também poderiam funcionar, mas o DNS parecia mais fácil.

Anote qual arquivo é a cadeia de certificados completa e substitua 0003_chain.pemno exemplo, se necessário:

A cadeia completa de certificados é salva em: ...

Faça upload e crie o certificado autogerenciado no GCP:

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

Crie o balanceador de carga para o qual você está migrando ou configure-o para usar o certificado autogerenciado:

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

Atualize os registros DNS para apontar para o IP do seu balanceador de carga. Agora deve ser possível encerrar o TLS para example.com e subdomain.example.com. Você pode testar esta etapa adicionando um registro para example.com em seu arquivo hosts, apontando para o IP do balanceador de carga. A resposta de John Hanley dá muitos bons conselhos sobre isso.

Crie o certificado gerenciado:

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

Os caracteres curinga não são compatíveis com certificados gerenciados pelo Google, portanto, liste todos os domínios em uso.

Atribua-o ao proxy de destinojuntocom o certificado autogerenciado. Os certificados não serão provisionados até que sejam atribuídos a um proxy:

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

Verifique o status:

gcloud compute ssl-certificates describe lb-certificate-managed

Espere até que statusmude de PROVISIONINGpara ACTIVE-qualquer outro estadoé um erro que deve ser investigado. "O provisionamento de um certificado gerenciado pelo Google pode levar até 60 minutos."de acordo com os documentos(Let's Encrypt faz a mesma coisa em segundos...).

Pode levar mais 30 minutos para ficar disponível para uso por um balanceador de carga.

Portanto,espere 30 minutosdepois que o status mudou para ACTIVE.

Atualize o proxy de destino para usar apenas o certificado gerenciado pelo Google:

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

Pode demorar um pouco para que a nova configuração seja propagada. Verifique o emissor do endpoint no navegador ou usando o openssl:

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

O emissor agora deve ser "Google Trust Services LLC" em vez de "Let's Encrypt".

O certificado Let's Encrypt autogerenciado agora pode ser removido ou mantido até que expire, caso haja algum problema com o certificado gerenciado.

Para limpar o certificado Let's Encrypt autogerenciado não utilizado, execute:

gcloud compute ssl-certificates delete lb-certificate-letsencrypt

Responder2

Você terá tempo de inatividade.

Você pode seguir estas dicas para minimizar o tempo de inatividade. Com um planejamento adequado, o tempo de inatividade será muito curto e, em alguns casos, novas tentativas automáticas tornarão isso invisível para os clientes.

No entanto, não conheço o design do seu site, a utilização de cookies, a autenticação, a gestão de sessões, etc. Se possível, considere enviar um e-mail aos seus clientes avisando-os com antecedência sobre a manutenção do site.

Este é um bom momento para revisar seus registros. Procure possíveis problemas com acesso a endereços IP. Esses tipos de problemas começarão a falhar após a conclusão da migração e o encerramento do sistema antigo.

  1. Lembre-se de que os registros de recursos DNS são armazenados em cache globalmente. O registro de recurso TTL fornece uma dica sobre quanto tempo. Os resolvedores de DNS são livres para usar sua própria interpretação do seu TTL.

  2. Anote o TTL dos registros de recursos que você alterará. Agora altere o TTL para um valor curto, como 1 minuto.

  3. Antes de fazer as alterações finais, espere pelo menos que o TTL antigo expire.

  4. Configure seus serviços e o balanceador de carga antes de fazer qualquer alteração no DNS. Certifique-se de que os serviços funcionem corretamente usando apenas o endereço IP. Se você estiver redirecionando IP para domínio ou HTTP para HTTPS, desative temporariamente esses recursos e ative-os mais tarde.

  5. Use o certbot no modo manual e crie um certificado que pode ser carregado no balanceador de carga. Isso remove a etapa do balanceador de carga criar o certificado SSL e aguardar a verificação. Posteriormente, você poderá mudar para o SSL gerenciado pelo Google.

  6. Configure os front-ends HTTP e HTTPS do Google Cloud Load Balancer. Configure o certificado Let's Encrypt SSL no frontend.

  7. Planeje deixar o site antigo em funcionamento por cerca de 30 dias após a migração. Normalmente vejo tráfego por várias semanas no site antigo após a migração.

  8. Selecione a hora do dia ou dia da semana com menos tráfego. Em seguida, troque os registros de recursos DNS. Lembre-se de que o valor TTL antigo deveria ter expirado para que o novo TTL fosse usado para armazenamento em cache.

  9. Alguns dias depois, depois de verificar se tudo está funcionando, defina os valores TTL para algo normal, como604800que é o número de segundos em uma semana ou 86.400 (um dia). Reative o redirecionamento de site (IP -> domínio, HTTP -> HTTPS), se usado.

Responder3

Além das sugestões anteriores, lembre-se de que os certificados SSL gerenciados pelo Google não são compatíveis com balanceadores de carga HTTP(S) externos regionais e balanceadores de carga HTTP(S) internos. Para esses balanceadores de carga, você precisará usar certificados SSL autogerenciados. Não vi que tipo de balanceador de carga você está usando, porém antes de tentar configurar essa migração você precisará considerá-la. Também, neste mesmoguiavocê pode ver como criar e usar certificados SSL gerenciados pelo Google e as considerações para fazê-los funcionar corretamente1.

Sugiro que você defina uma janela de manutenção para essas alterações, pois pode levar até 30 minutos até que o certificado esteja disponível para todos os Google Front Ends (GFEs).

Além disso, emaqui você verá o guia oficial com o passo a passo para chegar a esse comportamento.

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

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

informação relacionada