TLS renewal failing over and over

1

When I click the “Provision” button on the TLS Certificates page I get a very unhelpful “Something went wrong. Sorry” error! :rofl:

The overnight automatic attempts are sending me emails showing a failure of LetsEncrypt to download the challenge files. My domains serve their content from the correct paths (as far as I know). Could it be a permissions issue? What should the default permissions be?

I needed to change the permissions on the folders for my domains in order to FTP the files into them for the websites.

I’ve tried changing them back as follows but I suspect this isn’t correct.

sudo chown -R user-data /home/user-data/www/default
sudo chown -R user-data /home/user-data/www/gideon-it.co.uk
sudo chown -R user-data /home/user-data/www/philipalantyler.co.uk
sudo chown -R user-data /home/user-data/www/gideon-it.com

The emailed error message is shown below for the gideon-it.com domain.

Provisioning TLS certificates for gideon-it.com, autoconfig.gideon-it.com, autodiscover.gideon-it.com, mta-sts.gideon-it.com, www.gideon-it.com.

Provisioning TLS certificates for philipalantyler.co.uk, autoconfig.philipalantyler.co.uk, autodiscover.philipalantyler.co.uk, mta-sts.philipalantyler.co.uk, www.philipalantyler.co.uk.

error: gideon-it.com, autoconfig.gideon-it.com, autodiscover.gideon-it.com, mta-sts.gideon-it.com, www.gideon-it.com:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Requesting a certificate for gideon-it.com and 4 more domains

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:

Domain: autodiscover.gideon-it.com

Type: connection

Detail: 81.174.152.174: Fetching http://autodiscover.gideon-it.com/.well-known/acme-challenge/yWGA3xoJeMbxz8NBVyDfeHFtIJc28MR3D4Qbr1OMQ0Q: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

The System software is up to date.|
Mail-in-a-Box is up to date. You are running version v68

2

try
ls -ls /home/user-data/www

mine looks like this. ubuntu is my sudo username

4 -rw-rw-r-- 1 user-data ubuntu 3315 Apr 16 12:53 index.html

I don’t think that is the problem.
But next time upload via ftp in your /home directory than ssh into the box and copy “sudo cp -rp” to the www directory to preserve permissions. Check via ftp if the directories have owner permissions 775 and files within directories 644. But you don’t change this via ftp. Just ssh and sudo cp -rp.

Make new directory
sudo mkdir /home/user-data/www/test for testing.

FTP the files to your /home/YOURsudoUSERNAME/ directory.
Then ssh to your box.

sudo cp -rp /home/YOURsudoUSERNAME/test/. /home/user-data/www/test/

DO not change permissions or owneship. That is the correct way.

I remember when doing it manually that you should not try too much times to renew. There is some timeout period with Let’s Encrypt. And why do you provision yourself. This is all automatic in MIAB.

You can run
cd ~/mailinabox/management/
./ssl_certificates.py

To provision and check the messages.

Rerun the entire setup if you think you messed some permissions just type

sudo mailinabox

3

I re-ran sudo mailinabox and then tried to re-provision. I only tried it manually previously as the automatic was failing.

This was the result…

tardis@box:~$ cd ~/mailinabox/management/
tardis@box:~/mailinabox/management$ ./ssl_certificates.py
Traceback (most recent call last):
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 684, in
provision_certificates_cmdline()
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 395, in provision_certificates_cmdline
status = provision_certificates(env, limit_domains=domains)
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 245, in provision_certificates
domains, domains_cant_provision = get_certificates_to_provision(env, limit_domains=limit_domains)
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 186, in get_certificates_to_provision
existing_certs = get_ssl_certificates(env)
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 56, in get_ssl_certificates
pem = load_pem(load_cert_chain(fn)[0])
File “/home/tardis/mailinabox/management/./ssl_certificates.py”, line 624, in load_cert_chain
with open(pemfile, “rb”) as f:
PermissionError: [Errno 13] Permission denied: ‘/home/user-data/ssl/ssl_private_key.pem’

I checked the permissions as you suggested and this was the result…

tardis@box:/$ ls -ls /home/user-data/www
total 28
4 drwxr-xr-x 2 user-data root 4096 Mar 30 18:46 default
4 drwxr-xr-x 2 user-data root 4096 Mar 22 15:26 gideon-it.com
4 drwxr-xr-x 9 user-data root 4096 Mar 2 09:53 gideon-it.co.uk
4 drwxr-xr-x 2 user-data root 4096 Mar 1 23:14 mta-sts.gideon-it.co.uk
4 drwxr-xr-x 2 user-data root 4096 Mar 1 18:19 mta-sts.philipalantyler.co.uk
4 drwxr-xr-x 8 user-data root 4096 Mar 3 08:34 philipalantyler.co.uk
4 drwxr-xr-x 2 user-data root 4096 Mar 1 18:00 tempfiles.co.uk

I checked permissions on /home/user-data/ssl too …

tardis@box:~$ ls -ls /home/user-data/ssl
total 32
4 -rw-r–r-- 1 root root 3635 Feb 29 20:53 box.gideon-it.com-20240529-842bbd34.pem
4 -rw-r–r-- 1 root root 1013 Feb 21 13:00 box.gideon-it.com-selfsigned-20240221.pem
4 -rw-r–r-- 1 root root 424 Feb 21 13:00 dh2048.pem
4 -rw-r–r-- 1 root root 3717 Feb 29 20:51 gideon-it.com-20240529-b694c943.pem
4 -rw-r–r-- 1 root root 3737 Mar 3 17:44 gideon-it.co.uk-20240601-971559f9.pem
4 drwxr-xr-x 5 root root 4096 May 18 03:22 lets_encrypt
4 -rw-r–r-- 1 root root 3786 Mar 1 18:33 philipalantyler.co.uk-20240530-e44d4952.pem
0 lrwxrwxrwx 1 root root 59 Feb 29 20:53 ssl_certificate.pem → /home/user-data/ssl/box.gideon-it.com-20240529-842bbd34.pem
4 -rw------- 1 root root 1704 Feb 21 13:00 ssl_private_key.pem

Thanks for the help. But it still isn’t working. Any other ideas?

4

Chown of the www directory to your username. Now it is owned by root.
Is tardis your sudo username?

Like this.

As tardis:
sudo chown -R user-data:tardis /home/user-data/www
then
cd /home/user-data/www
ls -ls >> should give you user-data:tardis

Then go to your ftp application, I use Filezilla. And find the /home/user-data/www` and right click on default or any other hosted site directory, and hit File Attributes. Directories should be 755 and files inside them, 644. If they are not, go back to the ssh session and

As tardis:
sudo chmod 755 >>> path to directory
sudo chmod 644 >>> path to file or files

This is because you did not run the command as sudo.

As tardis:
cd ~/mailinabox/management/
sudo ./ssl_certificates.py

If it fails with sudo, change to root and run ./ssl_certificates.py` as root like this:

sudo su
root@box:/home/ubuntu/mailinabox/management#./ssl_certificates.py

DO NOT CHANGE ANYTHING THERE EVERYTHING IS OK
Please report back.

5

Partial success.

tardis is indeed my sudo username.

I tried the command

sudo chown -R user-data:tardis /home/user-data/www

Then I checked the folder permissions with FileZilla and /home/user-data/www has 755, the files within are 664.

I tried the sudo su variation when the regular manual provision command didn’t.

The domain philipalantyler.co.uk renewed OK
The domains gideon-it.co.uk and gideon-it.com didn’t.

root@box:~/mailinabox/management# sudo su
root@box:/home/ubuntu/mailinabox/management#./ssl_certificates.py
root@box:~/mailinabox/management# ./ssl_certificates.py
Provisioning TLS certificates for gideon-it.com, autoconfig.gideon-it.com, autodiscover.gideon-it.com, mta-sts.gideon-it.com, www.gideon-it.com.
Provisioning TLS certificates for gideon-it.co.uk, autoconfig.gideon-it.co.uk, autodiscover.gideon-it.co.uk, mta-sts.gideon-it.co.uk, www.gideon-it.co.uk.
Provisioning TLS certificates for philipalantyler.co.uk, autoconfig.philipalantyler.co.uk, autodiscover.philipalantyler.co.uk, mta-sts.philipalantyler.co.uk, www.philipalantyler.co.uk.
error: gideon-it.com, autoconfig.gideon-it.com, autodiscover.gideon-it.com, mta-sts.gideon-it.com, www.gideon-it.com:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for gideon-it.com and 4 more domains

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: autodiscover.gideon-it.com
Type: dns
Detail: DNS problem: server failure at resolver looking up A for autodiscover.gideon-it.com; DNS problem: server failure at resolver looking up AAAA for autodiscover.gideon-it.com

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

error: gideon-it.co.uk, autoconfig.gideon-it.co.uk, autodiscover.gideon-it.co.uk, mta-sts.gideon-it.co.uk, www.gideon-it.co.uk:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for gideon-it.co.uk and 4 more domains

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: autodiscover.gideon-it.co.uk
Type: connection
Detail: 81.174.152.174: Fetching http://autodiscover.gideon-it.co.uk/.well-known/acme-challenge/arD_Ud8TUsCTPzDG-KGdSi7Ds4tSqDrVCkAufj1y574: Timeout during connect (likely firewall problem)

Domain: autoconfig.gideon-it.co.uk
Type: connection
Detail: 81.174.152.174: Fetching http://autoconfig.gideon-it.co.uk/.well-known/acme-challenge/HgB7Z7Lxn35krfep9Sjyb2G76cFPVHdtC90NGwez27Y: Timeout during connect (likely firewall problem)

Domain: gideon-it.co.uk
Type: connection
Detail: 81.174.152.174: Fetching http://gideon-it.co.uk/.well-known/acme-challenge/N7VL_jjNQ7E6RhexpavuvCA5DMUQX_h-ERdXRmSBa9Q: Timeout during connect (likely firewall problem)

Domain: www.gideon-it.co.uk
Type: dns
Detail: DNS problem: server failure at resolver looking up CAA for www.gideon-it.co.uk

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

installed: philipalantyler.co.uk, autoconfig.philipalantyler.co.uk, autodiscover.philipalantyler.co.uk, mta-sts.philipalantyler.co.uk, www.philipalantyler.co.uk:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for philipalantyler.co.uk and 4 more domains

Successfully received certificate.
Certificate is saved at: /tmp/tmpqewcz_qc/cert
Intermediate CA chain is saved at: /tmp/tmpqewcz_qc/chain
Full certificate chain is saved at: /tmp/tmpqewcz_qc/cert_and_chain.pem
This certificate expires on 2024-08-17.
NEXT STEPS:

  • Certificates created using --csr will not be renewed automatically by Certbot. You will need to renew the certificate before it expires, by running the same Certbot command again.

If you like Certbot, please consider supporting our work by:

web updated

Thanks for your help Vele - I’ll try again with the other two domains.

6

This is a DNS propagation problem. Wait 48 hours it seems that DNS has propagated only in one half of the world. gideon-it.com does not even exist in the DNS records?

UPDATE: aha, it is a redirect, OK then you don’t need a certificate for that.

Is it hosted on your MIAB or somewhere else.
In conclusion the provisioning works well. It seems that you have another issue with your A record not propagating and Let’s Encrypt says there is no A record and it fails.
Strange. Check the link in 24 hours if it still has not propagated

7

As MiaB has been running with all the domains for about 80 days without an issue I’m guessing the DNS issue was caused by me re-running the “sudo mailinabox” setup script?

I’ll leave it and see if it resolved itself overnight and continue investigating tomorrow if not.

Thanks, again, for the help! :+1:

8

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

9

It’s the web redirecting that did it. When you reinstalled it replaced installed index.html again and reset the nginx settings so that it would serve from the directly certbot is given to write the challenge file in. But on the .com box you’ve still got things in place that break the HTTP challenge.

10

Well I fixed it by installing a new MiaB instance in a new VM on my server on the same IP and re-created the domains. I’ve since moved it again from the server to a spare laptop - that way I get some battery backup resiliance if the power goes off.

It’s working really well with 16Gb of RAM and a 256Gb SSD on a 2.3Ghz 4-core i3 gen 4 CPU.

Thanks so much for your help guys! I appreciate it.