OpenSSL config and Certbot compatibility issue (MinProtocol = TLSv1.3)

[ammnt]

Hi,

look like the acme-v02.api.letsencrypt.org endpoint currently NOT supports TLS 1.3 clients:
SSL Server Test: acme-v02.api.letsencrypt.org (Powered by Qualys SSL Labs)

My operating system is (include version):
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Linux 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
OpenSSL 1.1.1d 10 Sep 2019

I installed Certbot with snap:

certbot 1.16.0 1201 latest/stable certbot-eff✓ classic

I ran this command:

sudo certbot certonly --manual --preferred-challenges=dns -d 'test.ammnt.app' --key-type ecdsa --force-renewal

and it produced this output:
An unexpected error occurred:
requests.exceptions.SSLError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:1123)')))

Certbot's behavior differed from what I expected because these directives has been added to the OpenSSL config file (/etc/ssl/openssl.cnf) before:

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.3
CipherString = DEFAULT@SECLEVEL=2
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Options = ServerPreference,PrioritizeChaCha

Of course it works fine if MinProtocol = TLSv1.2 is installed. And same error with Certbot from Debian repos🤔

So please add add TLS 1.3 support for acme-v02.api.letsencrypt.org endpoint and appropriate HTTPS settings👆

Thank you.
Cheers😘

[Osiris]

While I'm not from the LE staff, I'm wondering why TLS 1.3 isn't enabled indeed, as the API endpoints are behind the Cloudflare CDN and Cloudflare has adopted TLS 1.3 already.

Maybe it's as simple as to hit the toggle switch by a Let's Encrypt engineer?

I am curious though: why only TLS 1.3? Wouldn't that hamper your connectivity to other sites beside Let's Encrypt as well? TLS 1.2 should also be safe enough (for now).

[_az]

@Osiris

as the API endpoints are behind the Cloudflare CDN and Cloudflare has adopted TLS 1.3 already.

I don't know for sure, but I think Let's Encrypt might be terminating TLS themselves, and Cloudflare is only acting as a TCP tunnel.

There's a few tell tales, like the missing Server header and a noticeable handshake delay when connecting from where I live, that doesn't happen when Cloudflare is terminating the connection locally.

[ammnt]

@Osiris

I am curious though: why only TLS 1.3? Wouldn't that hamper your connectivity to other sites beside Let's Encrypt as well? TLS 1.2 should also be safe enough (for now).

This is my personal private DNS server with NGINX reverse proxy (DNS-over-HTTPS). It is important to me that it is strict TLS 1.3. Everything is already working fine, except for the function of issuing and renewing an SSL certificate through Certbot.

I like your suggestion to use Cloudflare for LE endpoint. This is the fastest and easiest way for LE engineers to solve all such problems at once. Thank you so much!

[orangepizza]

letsencrypt/boulder

	RootCAs:      rootCAs,
	ClientCAs:    rootCAs,
	ClientAuth:   tls.RequireAndVerifyClientCert,
	Certificates: []tls.Certificate{cert},
	// Set the only acceptable TLS version to 1.2 and the only acceptable cipher suite
	// to ECDHE-RSA-CHACHA20-POLY1305.
	MinVersion:   tls.VersionTLS12,
	MaxVersion:   tls.VersionTLS12,
	CipherSuites: []uint16{tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305},
}, nil

looks like this is intensional choice to only use TLS 1.2
maybe because of this? proposal: crypto/tls: support TLS 1.3 post-handshake authentication · Issue #40521 · golang/go · GitHub