☰

¿Cómo migrar a certificados administrados por Google sin tiempo de inactividad?

tag-icon • tag-icon ssl-certificate google-cloud-platform load-balancing google-compute-engine
¿Cómo migrar a certificados administrados por Google sin tiempo de inactividad?

Voy a trasladar example.com de un proveedor de alojamiento externo (que no sea Google) a GCP.

Al configurar el balanceador de carga, noté que tengo que apuntar example.com al balanceador de carga para que se valide el certificado administrado por Google.

Se supone que debo cambiar el registro A de example.com a la IP (estática) del nuevo equilibrador de carga; luego se validará.

El problema es que ya tengo mucho tráfico en example.com, las solicitudes que ocurren después de que example.com comienza a apuntar al balanceador de carga, pero antes de que se valide el certificado generarán errores de SSL y usuarios muy descontentos.

¿Alguien ha solucionado esto? Sé que hay maneras deevitar el tiempo de inactividad cuandogiratoriocertificados, pero ¿debe haber alguna forma de migrar sitios grandes sin tiempo de inactividad?

Respuesta1

Las otras respuestas son muy buenas, pero estaba muy motivado para encontrar una manera de migrar a un balanceador de carga de GCP sin planificar el tiempo de inactividad en el que básicamente nos sentamos y esperamos a que se emitan los certificados. Agrego mi propia respuesta, ya que esta pregunta generó mucho tráfico y resulta que no es necesario el tiempo de inactividad con algo de planificación y pruebas.

Así es como lo hice:

  1. Emita certificados temporales de Let's Encrypt para ejemplo.com.
  2. Importe los certificados como certificados autoadministrados.
  3. Configure el equilibrador de carga para utilizar los certificados autoadministrados.
  4. Actualice los registros DNS para que apunten al equilibrador de carga.
  5. Cree certificados administrados por Google y asígnelos comosegundocertificado, al lado del certificado autogestionado.
  6. Espere a que el certificado administrado por Google sea ACTIVE. Esto puede llevar mucho tiempo. Aquí es donde habría tiempo de inactividad sin el certificado autogestionado.
  7. Espere 30 minutos para que el certificado se propague a todos los front-ends de Google (GFE).
  8. Ahora hay dos certificados asignados al equilibrador de carga. Actualícelo para utilizar únicamente el certificado administrado por Google. ¡Hecho!

Detalles

Para resumir el problema: los certificados administrados de Google requieren un registro DNS que apunte a un balanceador de carga con el certificado ya asignado o no se emitirán. Esto crea un problema, ya que la emisión del certificado puede tardar hasta una hora y no queremos errores de SSL durante este tiempo.

La solución que encontré fue usarcertificados autogestionadosdurante la migración y cambiar a los certificados administrados por Google una vez que nuestro dominio apuntaba al balanceador de carga de GCP y los certificados ya se habían emitido.

solíaVamos a cifrarcertificados, pero otros también funcionarán. Una ventaja de esto era que ya estábamos usando certificados Let's Encrypt, por lo que no tenía que preocuparme porcompatibilidad de certificados.

Aquí hay una versión simplificada de lo que hice. El proxy de destino del balanceador de carga se llamará my-target-proxy, los certificados se llamarán lb-certificate-letsencrypty lb-certificate-managed. Los nombres de dominio son example.comy subdomain.example.com.

Requisitos previos:

Genere un nuevo certificado para usarlo como certificado autoadministrado, firmado por Let's Encrypt:

openssl genrsa -out letsencrypt.pem 2048

Cree un archivo de configuración de 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

Generar unSolicitud de firma de certificado:

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

Obtenga un certificado firmado de Let's Encrypt:

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

Actualice los registros DNS indicados por certbot para verificar la propiedad. Otros desafíos también podrían funcionar, pero DNS parecía más fácil.

Tome nota de qué archivo es la cadena de certificados completa y reemplácelo 0003_chain.pemen el ejemplo si es necesario:

La cadena de certificados completa se guarda en: ...

Cargue y cree el certificado autoadministrado en GCP:

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

Cree el balanceador de carga al que está migrando o configúrelo para usar el certificado autoadministrado:

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

Actualice los registros DNS para que apunten a la IP de su balanceador de carga. Ahora debería poder finalizar TLS para ejemplo.com y subdominio.ejemplo.com. Puede probar este paso agregando un registro, por ejemplo.com, en su archivo de hosts, que apunte a la IP del balanceador de carga. La respuesta de John Hanley ofrece muchos buenos consejos al respecto.

Cree el certificado administrado:

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

Los certificados administrados por Google no admiten comodines, así que asegúrese de enumerar todos los dominios en uso.

Asígnalo al proxy de destinojuntoscon el certificado autogestionado. Los certificados no se aprovisionarán hasta que se asignen a un proxy:

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

Verifique el estado:

gcloud compute ssl-certificates describe lb-certificate-managed

Espere hasta que statuscambie de PROVISIONINGa ACTIVE-cualquier otro estadoEs un error que debería investigarse. "El aprovisionamiento de un certificado administrado por Google puede tardar hasta 60 minutos".según los documentos(Let's Encrypt hace lo mismo en segundos...).

Es posible que se necesiten 30 minutos adicionales para que esté disponible para su uso por parte de un equilibrador de carga.

Por lo tanto,espera 30 minutosdespués de que el estado haya cambiado a ACTIVE.

Actualice el proxy de destino para utilizar únicamente el certificado administrado por Google:

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

La nueva configuración puede tardar un poco en propagarse. Verifique el emisor del punto final en el navegador o usando openssl:

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

El emisor ahora debería ser "Google Trust Services LLC" en lugar de "Let's Encrypt".

El certificado Let's Encrypt autoadministrado ahora se puede eliminar o conservar hasta que caduque en caso de que haya algún problema con el certificado administrado.

Para limpiar el certificado Let's Encrypt autoadministrado no utilizado, ejecute:

gcloud compute ssl-certificates delete lb-certificate-letsencrypt

Respuesta2

Tendrás tiempo de inactividad.

Puede seguir estos consejos para minimizar el tiempo de inactividad. Con una planificación adecuada, el tiempo de inactividad será muy breve y, en algunos casos, los reintentos automáticos harán que esto sea invisible para los clientes.

Sin embargo, no conozco el diseño de su sitio, el uso de cookies, la autenticación, la gestión de sesiones, etc. Puede haber interrupciones inevitables. Si es posible, considere enviar un correo electrónico a sus clientes para informarles antes del mantenimiento del sitio.

Este es un buen momento para revisar sus registros. Busque posibles problemas con el acceso a las direcciones IP. Ese tipo de problemas comenzarán a fallar una vez que se complete la migración y cierre el sistema anterior.

  1. Recuerde que los registros de recursos DNS se almacenan en caché a nivel mundial. El registro de recursos TTL proporciona una pista sobre cuánto tiempo. Los solucionadores de DNS son libres de utilizar su propia interpretación de su TTL.

  2. Anota el TTL de los registros de recursos que cambiarás. Ahora cambie el TTL a un valor corto como 1 minuto.

  3. Antes de realizar los cambios finales, espere a que caduque al menos el antiguo TTL.

  4. Configure sus servicios y el equilibrador de carga antes de realizar cualquier cambio de DNS. Asegúrese de que los servicios funcionen correctamente utilizando únicamente la dirección IP. Si está redirigiendo IP a un dominio, o HTTP a HTTPS, desactive temporalmente esas funciones y habilítelas más tarde.

  5. Utilice certbot en modo manual y cree un certificado que pueda cargar en el equilibrador de carga. Esto elimina el paso en el que el equilibrador de carga crea el certificado SSL y espera la verificación. Más adelante podrás cambiar a SSL administrado por Google.

  6. Configure las interfaces HTTP y HTTPS de Google Cloud Load Balancer. Configure el certificado SSL Let's Encrypt en la interfaz.

  7. Planee dejar el sitio antiguo en funcionamiento durante unos 30 días después de la migración. Normalmente veo tráfico durante varias semanas en el sitio antiguo después de la migración.

  8. Seleccione la hora del día o el día de la semana con menor cantidad de tráfico. Luego cambie los registros de recursos DNS. Recuerde que el antiguo valor TTL debería haber caducado para que el nuevo TTL se utilice para el almacenamiento en caché.

  9. Unos días más tarde, una vez que haya verificado que todo está funcionando, configure los valores TTL en algo normal como604800que es la cantidad de segundos en una semana o 86400 (un día). Vuelva a habilitar la redirección del sitio (IP -> dominio, HTTP -> HTTPS), si se utiliza.

Respuesta3

Además de las sugerencias anteriores, tenga en cuenta que los certificados SSL administrados por Google no son compatibles con los balanceadores de carga HTTP(S) externos regionales ni con los balanceadores de carga HTTP(S) internos. Para estos balanceadores de carga necesitarás utilizar certificados SSL autoadministrados. No he visto qué tipo de balanceador de carga estás usando; sin embargo, antes de intentar configurar esta migración deberás considerarlo. Además, en este mismoguíapodrás ver cómo crear y utilizar certificados SSL administrados por Google y las consideraciones para que funcione correctamente1.

Le sugeriría que establezca una ventana de mantenimiento para estos cambios, ya que podrían pasar hasta 30 minutos hasta que el certificado esté disponible para todos los front-ends de Google (GFE).

Además, enaquí Verás la guía oficial con el paso a paso para llegar a este comportamiento.

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#migrating-ssl

información relacionada