DNS issue preventing certificate renewal

I’m having a weird DNS issue. I’ve made no changes to my firewall and nothing has changed (so far as I know) at my domain registrar but when I try to renew the TLS certificates I get DNS errors for two of my three domains. All are registered with the same company (LCN.com). When I run a DNS check at

It says no authoritative DNS found!! According to MiaB’s status page all the DNS settings are correct.

✓ Nameservers are set correctly at registrar. [ns1.box.gideon-it.com; ns2.box.gideon-it.com]
✓ Domain’s email is directed to this domain. [gideon-it.co.uk ↦ 10 box.gideon-it.com]
:heavy_multiplication_x: MTA-STS policy is missing: STSFetchResult.NONE
✓ Postmaster contact address exists as a mail alias. [postmaster@gideon-it.co.uk ↦ ptyler@gideon-it.co.uk]
✓ Domain is not blacklisted by dbl.spamhaus.org.
✓ Domain resolves to this box’s IP address. [gideon-it.co.uk ↦ 81.174.152.174]
✓ TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2024-08-20.
? This domain’s DNSSEC DS record is not set. The DS record is optional. The DS record activates DNSSEC. See below for instructions.

show more
www.gideon-it.co.uk: Domain resolves to this box’s IP address. [www.gideon-it.co.uk ↦ 81.174.152.174]
www.gideon-it.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2024-08-20.
autoconfig.gideon-it.co.uk: Domain resolves to this box’s IP address. [autoconfig.gideon-it.co.uk ↦ 81.174.152.174]
autoconfig.gideon-it.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2024-08-20.
autodiscover.gideon-it.co.uk: Domain resolves to this box’s IP address. [autodiscover.gideon-it.co.uk ↦ 81.174.152.174]
autodiscover.gideon-it.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2024-08-20.

The domain philipalantyler.co.uk sometimes comes back OK with authoritative DNS and sometimes doesn’t. The primary domain gideon-it.com is the same, sometimes it works, sometimes it doesn’t.

I’ve got 6 days or so left to renew the TLS certificates.

Is it worth rerunning the MiaB setup? Would this fix it? I’ve already tried that once when only the philipalantyler.co.uk domain renewed and it hasn’t helped.

According to ShieldsUp! port 53 is open on my firewall.
https://www.grc.com/x/ne.dll?rh1dkyd2

Any suggestions appreciated, especially suggestions that fix it! :wink:

Are you running the latest version of MIAB? The DNS experts in addition to Josh are @MarthinL and @miabuser. So maybe they can help.

Also please respond if you implemented any redirects. I know that gideon-.com- is your box domain but it seems that gideon.co.uk- redirects to it? And you host a 3rd domain philipalantyler.co.uk for which the provisioning DID work and you have a new certificate. Am I right?

I’m on the latest MiaB - I just re-ran sudo mailinabox to ensure all was well as far as setup was concerned.

The gideon-it.com default webpage re-directs to gideon-it.co.uk but thats just using a javascript page re-direct. I am unaware of any other ways to redirect.

I set the box up using gideon-it.com as the main domain. The other two domains are on the same box.

I’ve checked my ISP’s broadband firewall is OFF for my account. Using ShieldsUP! I can see the required ports are open.

I’m getting and sending mail without issue. The websites at gideon-it.co.uk and philipalantyler.co.uk are working fine too.

It’s very bizarre.

I wander if it is a firewall problem or the redirect? But how did you originally provision the certificates at first install then?

This quote might point to a firewall problem or a false negative.
On the other hand how did you provision the certificates in the first place? Was the redirect on?
Might be a better idea to redirect via nginx: read more here: Redirect webmail.mydomain.example to box.mydomain.example/mail

An DO run:
sudo ~/mailinabox/tools/web_update .
Make some new entries in custom dns see of they propagate. For e.g. some random TXT record.
It all looks strange to me.

I don’t think I understand what you mean by redirect. I’m not redirecting any domains.

Do you think this could be something to do with it…

Is it worth me completely building a new MiaB VM? I can do that. I’ve downloaded all the mail in my mailboxes.

Without me having a single clue what I’ve done to fix it the TLS cert. is now working on gideon-it.co.uk but STILL not working on gideon-it.com. I did re-run sudo mailinabox but other than that I’ve done nothing.

Still getting errors doing an authoritative lookup on

gideon-it.com redirects to gideon-it.co.uk , i.e. when you enter that URL in the browser it goes to the other one?
How do you achieve this. Maybe this is the culprit. Try removing it and provision again.

I doubt it’s that. All that is is a javascript command in the index.html file.

I’ve removed the custom index.html and left the original default one in it’s place. Just in case.

Almost all done now. It must be trying automatically in the background…

Domain Certificate Status Actions
box.gideon-it.com Certificate has a problem: The certificate is expiring soon: The certificate expires in 7 days on 2024-05-29.
mta-sts.box.gideon-it.com Certificate has a problem: The certificate is expiring soon: The certificate expires in 7 days on 2024-05-29.
gideon-it.com Signed & valid. The certificate expires in 89 days on 2024-08-20.
autoconfig.gideon-it.com Signed & valid. The certificate expires in 89 days on 2024-08-20.
autodiscover.gideon-it.com Signed & valid. The certificate expires in 89 days on 2024-08-20.
mta-sts.gideon-it.com Signed & valid. The certificate expires in 89 days on 2024-08-20.
www.gideon-it.com Signed & valid. The certificate expires in 89 days on 2024-08-20.

read this:

Let’s Encrypt cannot find the ACME challenge file because the redirect says it is at a location other than .com i.e. at co.uk.

I am just guessing? Might not be the case at all. But it is definitely not a firewall since it already provisioned 2 valid certificates on your network.

But it is worth trying. And the proper way to redirect in NGINX server is to add another server block in the config file.

Repeat sudo ~/mailinabox/tools/web_update .
and try again to provision.
After the certificate expires on the .com you’ll get warnings on the webmail and admin pages and if you can live with that than it is not worth reinstalling or you might wait a bit.

1 Like

Also it might be a good idea to reboot the server.

sudo systemctl reboot

I don’t think that’s quite it but you’re getting closer to the real issue here.

I still have many questions but I suspect that’s where your problem lies. I.e., the problem probably doesn’t have anything to do with DNS.

If I’m reading the situation correctly, you used acme.sh (ACME) little less than three months ago to issue certificates for your servers. Did you use MiaB’s admin page to request the certificates and install them or did you get them another way? ACME supports several ways of verifying that you have control of the domain, most prominently one requiring a DNS record being added and another that checks that checks the contents of a file through the HTTP server.

I suspect that MiaB uses the latter method. Despite it’s tight integration and control over DNS, the ACME script doesn’t have a driver that knows the DNS API that MiaB implements, so it cannot add the challenge record it needs. But it can be given a local file path to put a file that would get served up at a well-known URL based on the domain you’re trying to verify you own and control. It would have made sense for Josh to use that mechanism rather than write a MiaB driver for ACME.

What seems to have happened in your case though, based on guessed answers and inferences, is that when you originally issued the certificates your web setup was still as per the MiaB standard setup, so it worked. Meanwhile one of many things got in the way. Most likely it’s the javascript based redirect on your website that is preventing nginx from serving the well-known directory from the directory MiaB has access to. The ACME code gets redirected like everything else hitting box.gideon-it.co.uk on port 80 to your other server, and the file it looks for sinmply isnt on there because MiaB does not have access to that filesystem.

It could also be that you’ve chosen to make your website more secure by turning off HTTP and allowing only HTTPS, either just in the firewall settings or inthe web host settings itself by enabling STS which makes it very strict about redirecting everything over HTTPS. ACME exclusively works over HTTP, so if it gets redirected elsewhere or can’t get through, it will not issue the certificate. I’ve ran a few tests and I can confirm without any doubt that http://www.gideon-it.co.uk/.well-known/acme-challenge/ comes back with an error code 301 meaning “Moved Permanently”. Feels like an STS setting to me, bt I can’t see deeper inside your server to be sure.

Since you have no time to mess around, I would suggest you temporarily disable the web site redirect you’re doing, make sure you can access static html files on the MiaB server directly using http. using curl http://www.gideon-it.co.uk/ is a good place to start. If that bring back the contents of index.html or index.php then you’re mostly there. Once that works get back to me and we can check the rest.

Of course I could be way off base here in the sense that MiaB has actually implemented a DNS based challenge for ACME. I’d be pleasantly surprised if that is the case, but if it is then we will need to look at why the DNS challenge is failing.

Dude, I see you already managed to get new certificates today for gideon-it.co.uk as well as gideon-it.com. What did the trick, or am I seeing the web-site’s certificates and not the email box’s certificates?

Nope, I checked now. box.gideon-it.com Webmail :: Welcome to box.gideon-it.com Webmail still has the certificate that expires 29 May. Looks like you managed to renew the certificates for the “real” website you’re redirecting to recently (expiring 24 August 2024), but the MiaB certificates has been failing to renew.

@MarthinL Thanks. There is another topic with some messages from Let’s Encrypt here.

I tried to help Gideon and he really did provision 2 of 3 domains hosted on his MIAB.
the co.uk one and the https://philipalantyler.co.uk/ both recieived new certificates.

Please note that his box is hosted https://gideon-it.com/ and box.gideon-it.com so he redirects the MIAB to co.uk https://gideon-it.co.uk and http redirects to https on the dot com site.

Maybe he provide some logs from /var/log/letsencrypt/letsencrypt.log
For us to see what is going on.
Also his status page will be helpful. Thanks for jumping in @MarthinL

@MarthinL Thanks. There is another topic with some messages from Let’s Encrypt here.

I tried to help Gideon and he really did provision 2 of 3 domains hosted on his MIAB.
the co.uk one and the https://philipalantyler.co.uk/ both recieived new certificates.

Please note that his box is hosted https://gideon-it.com/ and box.gideon-it.com so he redirects the MIAB to co.uk https://gideon-it.co.uk and http redirects to https on the dot com site.

Maybe he provide some logs from /var/log/letsencrypt/letsencrypt.log
For us to see what is going on.
Also his status page will be helpful. Thanks for jumping in @MarthinL

Also note MTA-STS policy is missing: STSFetchResult.NONE

This (from the other thread) confirms my suspicions that MiaB is letting ACME use the HTTP challenge method, not the DNS challenge method. That confirms my initial diagnosis that the redirecting he’s doing on box.gideon-it.com is causing ACME to effectively look for the challenge file on the wrong server, i.e. not box.gideon-it.com.

I think he should not redirect dot com domain where hosts the MIAB but the other way around.
Let’s see if Gideon can provide some Let’sEncrypt Logs. And a status page

I dont believe that will work either. Both domain names points to the same IP which is also box.gideon-it.com. I think he needs to explain what his intentions are with the redirecting. Is it just for show or is there another site involved.

This is the key symptom: ACME/certbot ONLY works over HTTP, not HTTPS, and his box redirects all HTTP traffic to HTTPS.
The problem is in an nginx config that’s trying to be clever.

$ curl http://box.gideon-it.com/
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>