What are the most common/biggest challenge people find with Let's Encrypt?

Hi, I’m the developer of a windows GUI for requesting and applying LE certs, called Certify SSL Manager (https://certifytheweb , a freemium offering).

I’ve found that there a common set of problems people face trying to get the Let’s Encrypt way of doing things to work (mainly around validation) and that the easier we can make it the more people are likely to use it.

My question was, what challenges (on linux, mac os, windows etc) are people finding that they constantly get tripped up by or things that are really common/annoying issues they wish they didn’t have to think about?

Hi @webprofusion,

I would say that a majority of the questions that we see on the forum relate to failed challenges. I’m starting a project in Certbot to try to provide much more detailed advice (via a future page on the Certbot web site) about why challenges may have failed and what to do about them.

I have a list of what I thought were the most common reasons that each challenge fails, which I can share with you if you’d like. In general, people often didn’t know what challenge they were using and didn’t know what it was trying to do, and so they may not have thought of reasons why it wouldn’t work with their setup. For example, people may not have understood that TLS-SNI-01 requires an inbound connection to port 443 of the exact machine that you’re running the client on, which should also be the webserver itself and that it needs to either have no webserver or an existing webserver that the client can reconfigure, and not be behind any kind of proxy, firewall, or CDN that terminates TLS.

There are also some people who are missing important concepts (e.g., you need a public domain name, you must actually control the domain name or server it points to, some validation methods require an inbound network connection to validate, you can’t receive an inbound connection on a private IP address, most clients require you to run directly on the actual web server for their default modes and default validation methods).

I think a lot of users would really appreciate more useful error diagnostics that give them something practical to try in response, and that’s certainly something that I’m going to be working on with Certbot.

1 Like

Also, many Certbot users have some trouble with automated renewal if they’re not using an OS package that provided a cron job or if they’re not already familiar with cron. They also often have trouble with automated renewal if they used something other than certbot --apache, because the renewal would require some other step to happen and/or take effect by restarting the web server.

@schoen thanks Seth, your list of common reasons for failure would be great. You can send me anything you think is useful to apps {at} webprofusion.com

It sounds like the challenges are pretty common across different platforms. What I’d like to do in Certify SSL Manager, on Windows at least, is completely diagnose those common faults and provide either guidance or auto configuration.

I’ve found having a validation step to ensure the challenge response is going to make it through externally over http port 80 was a big part of that, but I need to do more there. I’m not yet sure about using TLS-SNI-01 on windows but DNS challenges seem like they would be pretty strong if only we could talk to all the different DNS api’s!

As a fallback to http-01/tls-sni-01 could there be a scheme where the server responds to a challenge with a custom http header of LE’s choice, perhaps for a limited time and perhaps only in response to OPTIONS or similar? That would certainly be easy(ish) to do in IIS at least. Currently custom path handlers etc can really mess with the .well-known/acme-challenge fetches.

Sure, I’ll try to do that soon. I hope it will be helpful.

[quote]As a fallback to http-01/tls-sni-01 could there be a scheme where the server responds to a challenge with a custom http header of LE’s choice, perhaps for a limited time and perhaps only in response to OPTIONS or similar? That would certainly be easy(ish) to do in IIS at least. Currently custom path handlers etc can really mess with the .well-known/acme-challenge fetches.
[/quote]

That would need to be discussed over in the ACME working group.

https://datatracker.ietf.org/wg/acme/about/

They debate new validation methods and their security implications. If they adopt a new method as part of the standard, Let’s Encrypt might eventually consider it.

However, new DV validation methods also have to be approved by the CA/Browser Forum as part of their Baseline Requirements. There is now an enumerated list of approved DV methods and CAs have to use only methods that appear somewhere on that list.

So, there is a lot of discussion that would need to happen first.

That sort of self-validation can bring its own confusion and problems. :grimacing: I’ve seen users who don’t understand that both their client and the Let’s Encrypt servers need to connect to their server, and i think i’ve seen situations where the client fails, even though the validation server would have succeeded!

(I can’t remember specifically why. Probably due to NAT, firewall or reverse proxy complications, or the client misunderstanding the setup.)

(I experienced a similar bug once, though it didn’t affect my Let’s Encrypt usage. Due to a NAT bug, a VPS couldn’t access one of its own public IPs, even though the rest of the Internet could.)

Edit: I don’t mean to shoot down the idea, or say it’s not worth it. I just wanted to emphasize that adding moving parts, especially with insufficient documentation, brings its own risks.

Yep, already on it :slight_smile: Certify optionally uses an external proxy api to validate your site is accessible in advance before attempting the LE challenge/response. It’s very common for IIS servers to not be able to see themselves from the same DNS host name you would use externally.

2 Likes

can you send me that list as well please

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