Questions about TLS 1.0 / 1.1 deprecation for ACME requests

[jsha]

If you have any questions about the upcoming deprecation of TLS 1.0 / 1.1 for requests to the ACME API, please post them on this thread.

[mirabilos]

Oh no!

Damn, I need a couple of months off $dayjob to fix all the things I need prior to, and do the actual porting of, a newer SSL library to my hobby OS (as opposed to just backporting necessary individual fixes)…

[jsha]

If you get really stuck, you could have another system request and valid certificates for you using the DNS challenge type, then scp the certificates to your hobby OS.

Good luck, and I'm curious - what's your hobby OS called, and what's it like?

[mirabilos]

MirBSD. I could also proxy the requests through a Debian system; I already have set this up for one IMAP account (firewalled on the Debian box of course), but… meuh.

[webprofusion]

Out of interest which cipher suites will you support and will you use an RSA or EC chain (or both)? Some older versions of Windows (e.g. 2012 ) are still very much in use but by default only have a limited (compared to modern systems) set of cipher suites enabled.

[I understand this will affect approx 1.7 million certificates, based on the 0.008% of issuances not using TLS 1.2]

[jsha]

@webprofusion

Out of interest which cipher suites will you support and will you use an RSA or EC chain (or both)?

Good question. We plan to keep the same chain. We hadn't planned to change our list of cipher suites (which you can see here), but it may be that there are some we can eliminate because no client that supports TLS 1.2+ needs them. Do you have an recommendations?

[jvanasco]

Will this be implemented by ISRG within their network with a relevant error message OR will this be implemented on the CDN/Gateway/LoadBalancer layer with a generic status code or timeout?

[jsha]

At first we will provide an ACME-level error message. You can see the feature flag and corresponding error message in the pull request here: Add feature flags for upcoming deprecations by jsha · Pull Request #6043 · letsencrypt/boulder · GitHub. Note that the error message may change in the future, and the latest code will always be the best reference.

That means we'll actually still be terminating TLS 1.0 and 1.1 at our load balancers, and passing that information along to Boulder to give an informative error message. We will probably leave this informative error message in place for one full renewal cycle before turning off TLS 1.0 and 1.1 at the load balancers (after which the error messages will be whatever the client's TLS library shows when a TLS version cannot be negotiated).

[jvanasco]

@jsha

That means we'll actually still be terminating TLS 1.0 and 1.1 at our load balancers, and passing that information along to Boulder to give an informative error message.

Awesome! I am very glad you chose to implement it with this strategy! This will make troubleshooting much easier for all.

[jillian]

I've updated the Announcment thread with the following information:

@jillian

Our Staging environment now reflects this change and can be used for testing applicable updates to your client. If you attempt to connect to https://acme-staging-v02.api.letsencrypt.org with TLS 1.0 or 1.1 you will get the following message:

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "upgrade your ACME client to support TLSv1.2 or better",
  "status": 400
}

[webprofusion]

On Windows it's not necessarily the ACME client you have to upgrade, it's the OS level TLS and cipher suite registry settings, so in that context the error detail is misleading, as in that case no amount of upgrading your ACME client will help.

[jsha]

That's useful, I was just thinking we should add a more helpful error message. Similarly, on Linux it's more likely that people need to upgrade their OpenSSL.

Do you have any ideas about an error that is more helpful and is broad enough to cover Windows, Linux, and other OSes?

[petercooperjr]

Might it make sense for the error message to include a URL to a documentation page (and/or community forum post) with common platforms and solutions? Though I'm a little wary of suggesting that "all one has to do" to upgrade is fix some libraries where on systems old enough to not enable TLSv1.2 by default there are likely other security issues.

[rmbolger]

I like the idea of including a URL to a living document that is easier to update. And perhaps make the error message less of an explicit command like "You must do X" and more of a statement of fact. Something like:

"TLSv1.2 is now required for all ACME clients. Please see https://letsencrypt.org/docs/tls1.2-required/ for more detail."

[webprofusion]

@rmbolger

"TLSv1.2 is now required for all ACME clients. Please see https://letsencrypt.org/docs/tls1.2-required/ for more detail."

Nice! It still perhaps requires users to know what an ACME client is, perhaps something like

"TLSv1.2 is now required in order to use the Let's Encrypt service. Please see https://letsencrypt.org/docs/tls1.2-required/ for more detail."