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

To reach ACTIVE three things must hold at once: the domain’s A/AAAA points to the load balancer IP (and nothing else), the certificate is attached to a target proxy with its forwarding rule, and no CAA in the zone forbids Google’s CAs. Then, up to 60 minutes.

Why

Google issues managed certificates through Google Trust Services (pki.goog) or Let’s Encrypt, and picks one or the other on each issuance or renewal. To validate the domain it runs an HTTP check against the IP the name resolves to, so until DNS points at the load balancer there is nothing to validate. And like any CA, it honors CAA records: if your zone says only digicert.com may issue (a typical corporate policy), Google cannot.

The statuses tell the story:

The right CAA

With no CAA record at all, any CA may issue and Google works. If you have CAA (or your organization requires it), add both CAs:

1
2

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

Listing only one forces Google to always use that one; the documentation advises against it because a renewal may come out through the other. CAA records inherit downwards: a CAA on example.com covers www.example.com if the subdomain has none of its own.

1

dig +short CAA example.com

Certificate Manager: issue before switching DNS

With classic certificates (compute ssl-certificates) the domain must already point at the load balancer, which during a migration means a few minutes of broken HTTPS. Certificate Manager solves that with DNS authorization: you publish a validation CNAME and Google issues the certificate while traffic still flows to the old site.

 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.

# publish that CNAME in your zone and then:
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

Once the certificate is ACTIVE, you flip the A/AAAA and the cutover is zero. CAA applies the same way.

Traps

• Cloudflare or another proxy in front of the load balancer: the A record points at the proxy, not at Google, and validation fails with FAILED_NOT_VISIBLE. Grey cloud during issuance, or Certificate Manager with DNS authorization.
• A managed certificate attached to nothing never gets issued. Creating it and waiting does nothing; attach it to the target proxy first.
• Changing the domain list creates a new certificate: attach the new one, wait for ACTIVE, and only then remove the old one from the proxy, or you get a gap.
• Wildcards only with Certificate Manager and DNS authorization; classic managed certificates do not support them.
• Badly signed DNSSEC breaks CAA lookups: FAILED_CAA_CHECKING even when you have no CAA at all.

Reference: Google-managed SSL certificates and Certificate Manager in the Google Cloud documentation.

Chrome and Edge no longer negotiate TLS 1.0/1.1 and there is no flag to bring them back. iLO 2 (TLS 1.0) and iLO 3 (TLS 1.1 at most) will never move to TLS 1.2. What works today:

1. Firefox, in a separate profile: about:config → security.tls.version.enable-deprecated = true.
2. Edge in Internet Explorer mode (Windows).
3. SSH into the iLO for anything that does not need the UI, and enforce AES while you are there:

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

Why it happens

HPE put it in writing: TLS 1.2 is not supported on iLO 3 and will not be added because the G7 line is out of support. iLO 2 (G6 and earlier) is worse: TLS 1.0 and nothing else.

On the browser side:

• Chrome and Edge removed TLS 1.0/1.1 in 2020 (Chrome 84) and the SSLVersionMin policy that could re-enable them in 2022 (Chrome 98). Against an old iLO that shows up as ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
• Firefox disabled them in 78 (2020) but kept the preference. Since 93 it also turns off 3DES, unless deprecated TLS is enabled. RC4 was removed in 44 (2016) and is not coming back. The usual error is SSL_ERROR_UNSUPPORTED_VERSION or SSL_ERROR_NO_CYPHER_OVERLAP.

The bug to remove those Firefox preferences is still open, so as of today (September 2026) this route still works.

Option 1: Firefox with deprecated TLS, in a separate profile

Do not weaken your daily browser. Create a profile just for management:

1. about:profiles → Create a New Profile → name it ilo → Launch profile in new browser.
2. In that profile, about:config → search security.tls.version.enable-deprecated → true.
3. Open https://<ilo-ip>/ and accept the self-signed certificate.
4. If it still will not negotiate, security.tls.version.min → 1 (TLS 1.0, iLO 2) or 2 (TLS 1.1, iLO 3).

When Firefox hits a TLS 1.0 site, the error page shows an Enable TLS 1.0 and 1.1 button that flips the same preference. Old recipes touched four prefs (fallback-limit, min, max, enable-deprecated); on current Firefox enable-deprecated is enough and min is the fallback.

To launch that profile later:

1

firefox -P ilo --no-remote

Option 2: Edge in Internet Explorer mode

Windows only. IE mode uses the Trident engine and the system’s Schannel, which still keeps TLS 1.0/1.1.

1. edge://settings/defaultBrowser → Allow sites to be reloaded in Internet Explorer mode → Allow → restart Edge.
2. Open the iLO URL → ⋯ menu → Reload in Internet Explorer mode.
3. Edge remembers the page in IE mode for 30 days; add it to the IE mode pages list so it does not forget.

On Windows 11 24H2 and later TLS 1.0/1.1 are also off in Schannel: if IE mode still fails, enable them under Internet Options → Advanced → Use TLS 1.0 / 1.1 while you work on the iLO, and turn them off afterwards.

Option 3: from the iLO itself over SSH

SSH into the iLO still works from any OpenSSH if you ask for the old algorithms (details in SSH to legacy hosts):

1
2
3
4

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

Inside, two settings that help the web side:

1
2
3
4
5

# Offer AES instead of RC4/3DES (UI: Administration → Security → Encryption → Enforce AES/3DES Encryption)
set /map1/config1 oemhp_enforce_aes=yes

# New certificate (expired, hostname changed): delete the current one; the iLO resets and generates a new self-signed cert
delete /map1/sslcert1

Enforcing AES does not fix the error by itself: the problem is the TLS version, not only the cipher. What it buys you is that, once TLS 1.0/1.1 is enabled in the browser, the session uses AES-CBC and does not depend on 3DES (which Firefox only allows in deprecated mode) or RC4 (gone from every browser).

And for power, virtual media, users, and firmware you do not need the UI at all: iLO CLI commands.

What does not help

• Updating the firmware on iLO 2/3 does not raise the TLS ceiling; just make sure you are on the last release (2.33 / 1.94.2) for the rest of the fixes. See upgrade firmware over SSH.
• Chrome/Edge flags: none exist for TLS 1.0/1.1 since 2022.
• An old Chrome or a Windows 7 VM with IE11 works, but it is worse than a Firefox profile: an unpatched OS plus an unpatched browser to open a management interface.

If it is an iLO 4

iLO 4 with 2.x firmware negotiates TLS 1.2 and does not have this problem. If an iLO 4 gives you ERR_SSL_VERSION_OR_CIPHER_MISMATCH, it is on 1.x firmware: update it (2.8x is the final branch) and the browser gets in with no tricks.

See also

• SSH: “no matching host key type found” — the same iLO 2/3 also break a modern SSH client.
• Browsing the modern web on XP and 2003 — the mirror case: old OS against the new web.
• External reference: HPe iLO 3 fails with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.