En corto
| |
| |
Para que pase a ACTIVE tienen que cumplirse tres cosas a la vez: el A/AAAA del dominio apunta a la IP del balanceador (y a nada más), el certificado está adjunto a un target proxy con su forwarding rule, y ningún CAA de la zona prohíbe a las CAs de Google. Después, hasta 60 minutos.
Por qué
Google emite los certificados gestionados con Google Trust Services (pki.goog) o con Let’s Encrypt, y elige una u otra en cada emisión o renovación. Para validar el dominio hace una comprobación HTTP contra la IP a la que resuelve el nombre, así que hasta que el DNS apunte al balanceador no hay nada que validar. Y como cualquier CA, respeta los registros CAA: si tu zona dice que solo digicert.com puede emitir (política corporativa típica), Google no puede.
Los estados lo cuentan:
domainStatus | Causa | Qué hacer |
|---|---|---|
PROVISIONING | En curso | Esperar; si pasa de 60 minutos, revisar lo de abajo |
FAILED_NOT_VISIBLE | El nombre no resuelve a la IP del balanceador, o el certificado no está adjunto a un target proxy | Corregir A/AAAA, adjuntar el certificado, esperar la propagación |
FAILED_CAA_CHECKING | Google no pudo leer los CAA (DNS que no responde, DNSSEC roto) | Arreglar la zona |
FAILED_CAA_FORBIDDEN | Hay CAA y no incluye a pki.goog ni a letsencrypt.org | Añadir los dos registros |
FAILED_RATE_LIMITED | Demasiados intentos de emisión | Esperar; no recrear el certificado en bucle |
El CAA correcto
Sin ningún registro CAA, cualquier CA puede emitir y Google funciona. Si tienes CAA (o tu organización lo exige), añade las dos CAs:
| |
Poner solo una obliga a Google a usar siempre esa; la documentación lo desaconseja porque una renovación puede salir por la otra. Los CAA se heredan hacia abajo: un CAA en example.com cubre www.example.com si el subdominio no tiene el suyo.
| |
Certificate Manager: emitir antes de cambiar el DNS
Con los certificados clásicos (compute ssl-certificates) el dominio tiene que apuntar ya al balanceador, lo que en una migración significa unos minutos de HTTPS roto. Certificate Manager resuelve eso con autorización DNS: publicas un CNAME de validación y Google emite el certificado mientras el tráfico sigue en el sitio viejo.
| |
Cuando el certificado esté ACTIVE, cambias el A/AAAA y el corte es cero. Los CAA aplican igual.
Trampas
- Cloudflare u otro proxy delante del balanceador: el A apunta al proxy, no a Google, y la validación falla con
FAILED_NOT_VISIBLE. Nube gris durante la emisión, o Certificate Manager con autorización DNS. - Un certificado gestionado no adjunto a nada no se emite. Crearlo y esperar no hace nada; adjúntalo al target proxy primero.
- Cambiar la lista de dominios crea un certificado nuevo: adjunta el nuevo, espera
ACTIVE, y solo entonces quita el viejo del proxy, o tendrás un hueco. - Wildcards solo con Certificate Manager y autorización DNS; los certificados gestionados clásicos no los admiten.
- DNSSEC mal firmado rompe la lectura de CAA:
FAILED_CAA_CHECKINGaunque no tengas ningún CAA.
Referencia: Google-managed SSL certificates y Certificate Manager en la documentación de Google Cloud.