HTTP-01 Challenge Failed Due To Unsupported TLS Protocol

I have been able to manually renew my Let’s Encrypt certificate with Certbot for the past month or so—a cron job runs every Sunday. Today the job failed even though I have not really changed anything about my server, NGINX, keys, DNS, etc. I am running FreeBSD 12.0-RELEASE-p8 on a DigitalOcean droplet with NGINX 1.16.1 compiled with OpenSSL 1.1.1c. My authoritative DNS servers and domain are through Cloudflare.

My domain is, and the weekly command I run is

/usr/local/bin/certbot-3.7 certonly -d -d --webroot -w /usr/local/www/ -n --agree-tos --must-staple --redirect --hsts --uir --staple-ocsp --csr /usr/local/etc/letsencrypt/csr/csr.pem --disable-hook-validation --no-directory-hooks --disable-renew-updates --no-autorenew -m

Today the command produced the following output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Using the webroot path /usr/local/www/ for all unmatched domains.
Waiting for verification...
Challenge failed for domain
Challenge failed for domain
http-01 challenge for
http-01 challenge for
Cleaning up challenges
Some challenges have failed.

 - The following errors were reported by the server:

   Type:   tls
   Detail: Fetching
   remote error: tls: protocol version not supported

   Type:   tls
   Detail: Fetching
   remote error: tls: protocol version not supported

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   you have an up-to-date TLS configuration that allows the server to
   communicate with the Certbot client.

I know that DigitalOcean performed some maintenance on 8/22, but I am able to access my site through curl and normal web browsers just fine over IPv4 and IPv6.

This happened ≈ 1 month ago, and the “fix” was to temporarily enable TLS 1.2. Upon renewing my certificate, I disabled TLS 1.2; and the challenge has been able to work fine until today. My web server is configured to redirect all HTTP requests to HTTPS. In addition to my site’s being on HSTS Preload, the following is a snippet of my NGINX configuration:

user www;
http {
    root /usr/local/www/;
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve X25519;
    ssl_certificate /usr/local/etc/letsencrypt/live/;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/;
    ssl_trusted_certificate /usr/local/etc/letsencrypt/live/;
    ssl_early_data on;
    ssl_session_tickets on;
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_stapling_file /usr/local/www/;
    add_header Expect-CT "enforce, max-age=31536000" always;
    add_header Expect-Staple "max-age=3153600; includeSubDomains; preload" always;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header Public-Key-Pins 'pin-sha256="+hEWUMAjFcv3ugd61E4aC0D5Tnman/w4OJxAG1TiSU0="; pin-sha256="H4qzKcDCMla4HfrSDuKXGAaU049eMfdC76q0qT/1K90="; max-age=604800; includeSubDomains' always;

I have not changed the above configuration at all, so I’m perplexed why the challenge is suddenly failing. When I look at the log from last week, I do see that the challenge was fetched over HTTP; but the log today appears to be over HTTPS. I’m not sure why that is though. I can post my logs or anything else that may be of help.

1 Like

Hi @Zack


is your error.


the reason. The Letsencrypt validation server doesn’t support Tls.1.3, you have only Tls.1.3 active.

So it’s impossible to check your validation file.

Add Tls.1.2 support.

Only Tls.1.3 is too limited.

PS: Checking your domain ( ):

Error creating a TLS-Connection: TLSv1.3 found, but no connection via TLSv1.2 possible. Please activate TLSv1.2

Tls.1.2 isn’t active.


Hi @JuergenAuer,

Can you explain how this has worked the past month then? My server has only had TLS 1.3 enabled for the past month.

1 Like

I don’t know. But your configuration looks buggy.

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2019-08-18 2019-11-16, - 2 entries
Let’s Encrypt Authority X3 2019-08-16 2019-11-14, - 2 entries
Let’s Encrypt Authority X3 2019-08-11 2019-11-09, - 2 entries
Let’s Encrypt Authority X3 2019-08-04 2019-11-02, - 2 entries
Let’s Encrypt Authority X3 2019-08-03 2019-11-01, - 2 entries
Let’s Encrypt Authority X3 2019-07-28 2019-10-26, - 2 entries

and a lot more certificates. Why do you create weekly new certificates? Startet 2019-06-13.

Create one certificate, then use it 60 - 85 days, then create the next.



It is not buggy. I do not renew my certificate the “normal” way as you can see from the weekly command I posted. I want a certificate using secp384r1. Additionally, despite its falling out of favor, I like to use HPKP; thus I don’t want a new public key each time. For those reasons, I manually request a certificate each week with the CSR I generated with my key several months ago.

The fact that it breaks every month or so but not every week suggests to me that the validation server goes through additional steps when a month or so has passed.

I am not running Google or anything crazy, so being restrictive in the type of TLS connections I allow is not a big deal. I will likely use DNS validation instead that way I don’t have to enable TLS 1.2.

Why issue a new certificate every week, though?

Certbot doesn’t support ECDSA yet, but it does support reusing keys with --reuse-key.

It might be worth using another ACME client like

That fits – Let’s Encrypt’s current configuration is that authorizations can (usually) be reused for up to 30 days. (ACME clients should be prepared to validate any time they issue a certificate, though.)

How about excluding from the redirect to HTTPS?

Or using automated DNS validation?


@mnordhoff, I will change the frequency at which I request a new certificate. I foolishly used Certbot’s recommendation of running renew every day as a reason for me to request certificates frequently as well. Obviously they are completely different processes so I will change my cron job to run every 45 days instead.

Thank you for answering my question as to why it only broke every month or so. Currently I have modified my shell script to temporarily enable TLS 1.2 in my NGINX configuration file before requesting a certificate followed by disabling TLS 1.2. I know it is absurd, but technically I’m expected to redirect all HTTP requests in order to be compliant with HSTS. I know the challenge path only exists for a brief moment, but I don’t like breaking standards. I may end up using the DNS validation, but I don’t like the idea of storing my Cloudflare API key on my web server. Do you happen to know if/when Let’s Encrypt will work over TLS 1.3? While will allow me to easily request an secp384r1 certificate using the same key, it does not solve the issue of the Let’s Encrypt servers not being TLS 1.3 capable.

1 Like

Cloudflare actually now supports limited-scope API Tokens so you don’t have to give quite so much privilege to the ACME client. But unfortunately, certbot doesn’t support using them yet (see issue 7252. But there are a number of other clients that do. The most popular is probably

1 Like

I’m not promoting this, but if you want to do more work and run a DNS server, you could set up DNS validation by delegating a subdomain to a DNS server like acme-dns or BIND, with more fine-grained permissions.

1 Like

Thank you for the information! I don’t know how I missed that. I will definitely use the DNS challenge now. Additionally, since I will have a stored limited-scope token on my server, I will likely forgo HPKP in favor of adding a TLSA record. I will also force a new key each 30 days to have a weaker form of “forward secrecy”. I know most browsers must have an add-on to use DNSSEC, but it is better than nothing. Not to mention the fact that Chrome ignored HPKP anyway.

1 Like

That is an intriguing work-around, but I think I’ll just use the limited-scope tokens that Cloudflare now provides.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.