1
2

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

1
2
3
4
5

gcloud compute ssl-certificates describe web-cert --global --format='yaml(managed)'
# managed:
#   domainStatus:
#     www.example.com: PROVISIONING | ACTIVE | FAILED_NOT_VISIBLE | FAILED_CAA_FORBIDDEN | FAILED_CAA_CHECKING | FAILED_RATE_LIMITED
#   status: PROVISIONING | ACTIVE

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:

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:

1
2

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

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.

1

dig +short CAA example.com

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

gcloud certificate-manager dns-authorizations create www-auth --domain=www.example.com
gcloud certificate-manager dns-authorizations describe www-auth --format='yaml(dnsResourceRecord)'
# dnsResourceRecord: name: _acme-challenge.www.example.com. type: CNAME data: xxxx.authorize.certificatemanager.goog.

# publica ese CNAME en tu zona y luego:
gcloud certificate-manager certificates create www-cert \
  --domains=www.example.com --dns-authorizations=www-auth
gcloud certificate-manager maps create web-map
gcloud certificate-manager maps entries create www --map=web-map --certificate=www-cert --hostname=www.example.com
gcloud compute target-https-proxies update web-proxy --certificate-map=web-map

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_CHECKING aunque no tengas ningún CAA.

Referencia: Google-managed SSL certificates y Certificate Manager en la documentación de Google Cloud.