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.

Chrome y Edge ya no negocian TLS 1.0/1.1 y no hay flag que lo devuelva. iLO 2 (TLS 1.0) e iLO 3 (TLS 1.1 como máximo) nunca van a subir a TLS 1.2. Salidas que funcionan hoy:

1. Firefox, en un perfil aparte: about:config → security.tls.version.enable-deprecated = true.
2. Edge en modo Internet Explorer (Windows).
3. SSH al iLO para lo que no necesite la UI, y de paso forzar AES:

1
2

ssh -o HostKeyAlgorithms=+ssh-rsa -o KexAlgorithms=+diffie-hellman-group14-sha1 -c aes256-cbc Administrator@<ilo-ip>
set /map1/config1 oemhp_enforce_aes=yes

Por qué pasa

HPE lo dejó por escrito: TLS 1.2 no está soportado en iLO 3 y no se va a añadir porque los G7 están fuera de soporte. iLO 2 (G6 y anteriores) está peor: TLS 1.0 y nada más.

Del lado del navegador:

• Chrome y Edge quitaron TLS 1.0/1.1 en 2020 (Chrome 84) y la política SSLVersionMin que permitía reactivarlos en 2022 (Chrome 98). El resultado con un iLO viejo es ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
• Firefox los desactivó en la 78 (2020), pero dejó la preferencia. Desde la 93 también apaga 3DES, salvo que TLS deprecado esté habilitado. RC4 desapareció en la 44 (2016) y no vuelve. El error típico es SSL_ERROR_UNSUPPORTED_VERSION o SSL_ERROR_NO_CYPHER_OVERLAP.

El bug para eliminar esas preferencias de Firefox sigue abierto, así que hoy (septiembre de 2026) esta vía sigue funcionando.

Opción 1: Firefox con TLS deprecado, en un perfil aparte

No bajes la seguridad de tu navegador de diario. Crea un perfil solo para management:

1. about:profiles → Create a New Profile → nómbralo ilo → Launch profile in new browser.
2. En ese perfil, about:config → busca security.tls.version.enable-deprecated → true.
3. Abre https://<ilo-ip>/ y acepta el certificado autofirmado.
4. Si sigue sin negociar, security.tls.version.min → 1 (TLS 1.0, iLO 2) o 2 (TLS 1.1, iLO 3).

Cuando Firefox choca con un sitio TLS 1.0, la página de error trae el botón Enable TLS 1.0 and 1.1, que cambia la misma preferencia. Las recetas viejas tocaban cuatro prefs (fallback-limit, min, max, enable-deprecated); en Firefox actual con enable-deprecated basta y min es el respaldo.

Para lanzar ese perfil después:

1

firefox -P ilo --no-remote

Opción 2: Edge en modo Internet Explorer

Solo Windows. El modo IE usa el motor Trident y el Schannel del sistema, que sí conserva TLS 1.0/1.1.

1. edge://settings/defaultBrowser → Permitir que los sitios se vuelvan a cargar en modo Internet Explorer → Permitir → reinicia Edge.
2. Abre la URL del iLO → menú ⋯ → Volver a cargar en modo Internet Explorer.
3. Edge recuerda la página en modo IE 30 días; márcala para que no lo olvide.

En Windows 11 24H2 y posteriores TLS 1.0/1.1 vienen apagados también en Schannel: si el modo IE tampoco entra, actívalos en Opciones de Internet → Opciones avanzadas → Usar TLS 1.0 / 1.1 mientras trabajas con el iLO, y apágalos después.

Opción 3: desde el propio iLO por SSH

SSH al iLO sigue funcionando con cualquier OpenSSH si le pides los algoritmos viejos (detalle en SSH a equipos legacy):

1
2
3
4

ssh -o HostKeyAlgorithms=+ssh-rsa \
    -o KexAlgorithms=+diffie-hellman-group14-sha1 \
    -c aes256-cbc \
    Administrator@<ilo-ip>

Dentro, dos ajustes que ayudan a la parte web:

1
2
3
4
5

# Ofrecer AES en vez de RC4/3DES (en la UI: Administration → Security → Encryption → Enforce AES/3DES Encryption)
set /map1/config1 oemhp_enforce_aes=yes

# Certificado nuevo (expirado, hostname cambiado): borra el actual; el iLO se reinicia y genera otro autofirmado
delete /map1/sslcert1

Forzar AES no arregla el error por sí solo: el problema es la versión de TLS, no solo el cifrado. Lo que consigue es que, con TLS 1.0/1.1 ya habilitado en el navegador, la sesión use AES-CBC y no dependas de 3DES (que Firefox solo permite en modo deprecado) ni de RC4 (que ya no existe en ningún navegador).

Y para power, virtual media, usuarios y firmware ni siquiera necesitas la UI: comandos CLI de iLO.

Lo que no sirve

• Actualizar el firmware de iLO 2/3 no cambia el tope de TLS; solo asegúrate de estar en la última (2.33 / 1.94.2) por el resto de fixes. Ver actualizar firmware por SSH.
• Flags de Chrome/Edge: no existen para TLS 1.0/1.1 desde 2022.
• Un Chrome viejo o una VM con Windows 7 e IE11 funciona, pero es peor que un perfil de Firefox: sistema sin parches y navegador sin parches para abrir una interfaz de management.

Si es un iLO 4

iLO 4 con firmware 2.x negocia TLS 1.2 y no tiene este problema. Si un iLO 4 te da ERR_SSL_VERSION_OR_CIPHER_MISMATCH, está en un firmware 1.x: actualízalo (2.8x es la rama final) y el navegador entra sin trucos.

Ver también

• SSH: “no matching host key type found” — los mismos iLO 2/3 también rompen el cliente SSH moderno.
• Navegar la web moderna en XP y 2003 — el caso inverso: sistema viejo contra web nueva.
• Referencia externa: HPe iLO 3 fails with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.