LE has compatibility issue with very old Android/OpenSSL. https://community.letsencrypt.org/t/production-chain-changes... Possibly Google's cert doesn't have the issue?

Yeah, that transition didn't go as smoothly as they might have hoped. Most of us first-world programmers can just shrug and say "don't use unsupported versions," but I've had multiple non-technical clients call me up urgently and ask why a (relatively small, but not insignificant depending on the market, and definitely not in their control) subset of their users were seeing certificate errors.

So I don't recommend LE to my clients anymore. But it's a hassle to buy certificates the old way after having tasted ACME, so I'm always looking for an ACME-compatible alternative. ZeroSSL is backed by a more conservative Sectigo CA, but its ACME endpoints aren't very reliable. If this Google cert becomes widely available, I might just as well switch to it. :)

From memory, ZeroSSL also gets expensive after a couple of domains, and I had issues using certbot rather than acme.sh with it.

Nowadays you can get virtually unlimited 90-day certs from ZeroSSL if you use ACME through the EAB feature rather than using their API.

But their ACME support seems half-hearted at best. The endpoints often return errors for no reason, compatibility with clients is hit-and-miss, and they keep spamming you with renewal notices even if you renew the cert. For important domains these days I just get a cheap 1-year DV cert like the good ol' days.

Funny you should mention about the forums. There's been a fairly notable Chrome issue intermittently affecting users on MacOS X since late last year and Google seem oblivious to it.

https://support.google.com/chrome/thread/135844398/chrome-is...

So, yeah... I don't want to depend on a free Google Cloud account for SSL.

The reason may be so that services on private subnets don't need internet access to use Let's Encrypt. Just a guess though.

You don't need direct Internet access to use Let's Encrypt, as long as you can arrange for the challenge response to appear in public DNS under the name you want to use.

Would you mind giving an example of what that might look like? Or linking to something? I've always struggled with needing to open ports temporarily on stuff behind my own reverse proxy to avoid passing the certs by hand, and it sounds like something that'd be useful to understand.

It's the DNS-01 challenge[1]. This reduces the challenge to using some DNS provider with an API supported by a client[2] / [3], as well as the server needing to be able to reach the LE-API. We use this with the CNAME delegation into an irrelevant zone everywhere to get wildcard certificates for our LBs ( meaning: the _acme_challenge.example.com record is just a CNAME for _acme_challenge.dont.ever.use.this.example.com, and the servers just have credentials to modify records in the zone <dont.ever.use.this.example.com>)

1: https://letsencrypt.org/docs/challenge-types/#dns-01-challen...

2: https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...

3: https://github.com/acmesh-official/acme.sh/wiki/dnsapi

The magic phrase is “DNS-01” challenge. You place a DNS TXT record to validate control of the domain. There are lots of ACME clients that support a wide variety of DNS service providers. For example, I have a Home Assistant server which automatically issues certs using Gandi DNS and the HA Lets Encrypt support, all without being on the internet (except for the DNS entries)

I think you're confusing internet access with reachable from the internet.

If I remember correctly, you don't need your server to be reachable from the internet, but you still need to be able to contact your DNS provider and the LE server, so you need internet access

The acme client needs to reach LE though. Or you need to do a dance where the client is outside of the private network and ships the certificate into the private network.