Hosting·4 min read

Let's Encrypt fails in DirectAdmin: the five causes we always find

A failed certificate request is nearly always DNS, the www variant, the mail name, something blocking the challenge folder, or a subdomain you just created. Here is how to find it in minutes.

The certificate request for my domain fails in DirectAdmin. Check where the
domain, www and mail currently point, whether the challenge folder is
reachable from the outside and whether a redirect sits in between. Tell me
what to change, do not change anything yet.

A failed certificate request gives you a message in DirectAdmin that looks technical and tells you little. In practice the cause is nearly always one of the same five things. You can check all five from the outside, and that is exactly what the assistant on your account can do for you.

The background in one paragraph: Let's Encrypt only issues a certificate if it can prove you control the domain. It gets that proof by requesting a small file at http://yourdomain.com/.well-known/acme-challenge/.... If that fails, there is no certificate. Everything below is a reason why that request fails.

1. The domain does not point here yet

The most common cause, and the most logical one: your hosting is ready, but the A record still points at your old provider. Let's Encrypt then lands on the old server and does not find the file.

Two things go wrong here. You look at your own domain and see the new site, because you use a modified hosts file or because your own provider is already up to date. And: you changed the record a moment ago, but the old TTL is still running. Ask the assistant to check propagation worldwide and wait until that is right before trying again.

2. The www variant is missing

DirectAdmin requests one certificate for several names by default: your domain, www, and usually mail. Every name on that list is validated separately. One name that does not check out makes the whole request fail.

This often goes wrong for domains where www was never created, or where www points at another party. The fix: create the www record and point it at the same place as your domain, or remove www from the list of names in the request.

3. The mail name points elsewhere

Same mistake, different name. If your email lives with another party, mail.yourdomain.com often points at that party. If that name is still in your certificate request, the whole thing fails.

In that case remove mail from the list. You do not need that name for a working website, and your mail program can use the server name of your hosting instead.

4. Something blocks the challenge folder

The validation uses plain http, not https, and a folder whose name starts with a dot. Three things can get in the way:

  • A redirect from everything to https. A rule in .htaccess that rewrites every request is usually fine, but a redirect to another domain is not.
  • A rule that blocks folders starting with a dot. That sits in many security plugins and in some off the shelf configurations.
  • A maintenance page or a plugin that catches everything. Let's Encrypt then gets a page instead of the file.

This is the case where you can really put the assistant to work: have it make a request from the outside to a path in that folder and report the status code and any redirects.

5. You just created a subdomain

This is the quiet one. If you create a subdomain and request a certificate for it, DirectAdmin does not request a second certificate: it replaces your account certificate with a new one that has the extra name on it. If that new name does not pass validation, for example because the DNS record is not there yet, the request can fail while your old certificate has meanwhile been replaced or expired.

You do not see the result at the time, but a few weeks later: a site that suddenly shows a warning. We ran into this with an example subdomain on our own site.

The approach that prevents it: create the DNS record for the subdomain first, check that it is visible worldwide, and request the certificate after that. Also keep an eye on the end date of your certificates. The assistant can do that for all your websites in one instruction:

Go through my websites and put in a table which names are on the certificate
and when it expires. Flag anything that runs out within 21 days.

Common mistakes

"I tried again ten times." Do not. Let's Encrypt limits the number of requests per domain per period. If you keep trying without removing the cause, you hit that limit and have to wait. Find the cause first, then try once.

"The message mentions a rate limit, so my server is broken." No, that is the limit from the previous point. It lifts again after a while.

"I can already see the new site, so DNS is fine." Not necessarily. You are looking from your own connection, Let's Encrypt is not. Have propagation checked from the outside.

"I requested the certificate and now my email stopped working." Check which names are on the certificate. If you removed mail while your mail program uses that name, put the server name of your hosting in your mail program instead.

"It worked and now it has suddenly expired." Often point 5: a later request that failed, for example for a subdomain you have since deleted. Request the certificate again with only the names that really exist.

MK
Maarten Keizer

Founder of Invoker. Over twenty years in hosting, system administration and web development; builds the Claude hosting himself and tests everything on our own servers first.

about maarten