Unable to use lets encrypt after upgrade to 0.40

After I installed 0.40, I restored my backup from my 0.30 installation. After doing so, the certificate was the invalid one. When I went to the admin section under certificates, I found the option to install a cert but not to update them through letsencrypt. I was able to run letsencrypt manually and update the symlinks.

Has anyone else had a problem like this? I’m not quite sure where to start looking at why it wouldn’t give options for letsencrypt.

I would have expected to find a blue button labeled ‘Provision’ which would have provisioned a LE certificate for you. There is no option to update (or renew) certificates as that is done as a part of the daily maintenance I do believe.

Thanks, for your reply. I’ve put together a lot more info below that will hopefully help find the solution (and fix help the next person with this issue fix the issue!)

I don’t have a blue button marked provision, just a blue one marked “Install Certificate.” I attempted clearing out the /home/user-data/ssl directory and re-running mailinabox as root to reset the ssl certificate based on another forum post about letsencrypt..

I do see letsencrypt/certbot running in the console output:

Mail-in-a-Box uses Let's Encrypt to provision free SSL/TLS certificates
to enable HTTPS connections to your box. We're automatically
agreeing you to their subscriber agreement. See https://letsencrypt.org.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Registering without email!

 - Your account credentials have been saved in your Certbot
   configuration directory at /home/user-data/ssl/lets_encrypt. You
   should make a secure backup of this folder now. This configuration
   directory will also contain certificates and private keys obtained
   by Certbot so making regular backups of this folder is ideal.

Your Mail-in-a-Box is running.

Please log in to the control panel for further instructions at:


You will be alerted that the website has an invalid certificate. Check that
the certificate fingerprint matches:

After this, the /home/user-data/ssl directory doesn’t contain any certificate from lets-encrypt, just the self-signed cert:

-rw-r--r-- 1 root root  424 Jan 23 08:51 dh2048.pem
drwxr-xr-x 4 root root 4096 Jan 23 08:54 lets_encrypt
-rw-r--r-- 1 root root 1001 Jan 23 08:48 mail.xxx.com-selfsigned-20190123.pem
lrwxrwxrwx 1 root root   62 Jan 23 08:48 ssl_certificate.pem -> /home/user-data/ssl/mail.xxx.com-selfsigned-20190123.pem
-rw------- 1 root root 1675 Jan 23 08:48 ssl_private_key.pem

The ssl/letsencrypt directory doesn’t have any keys in it:

$ ls lets_encrypt/
accounts  renewal-hooks

I also have looked at the letsencrypt logs. When I look at the requests made today, they are only requests for account-related things, nothing to do with getting an ssl certificate:

# tail -n 500 /var/log/letsencrypt/letsencrypt.log | grep -i 'sending' | grep 2019-01-23
2019-01-23 08:54:18,845:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2019-01-23 08:54:21,182:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce.
2019-01-23 08:54:21,338:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-acct:

I was able to go get the certificate with letsencrypt manually using the same command line arguments and then answering a few questions. After that, I configured ssl_certificate.pem to point to the letsencrypt/live certificate. Everything starts with the right certificate but the MIAB daemon still doesn’t like something. The certificate management page in the admin panel says this:
Certificate has a problem: There is a problem with the certificate. The domain name does not resolve to this machine: [Not Set] (A).

Overnight, it did something in daily maintenance that made the symlink point to itself which broke a few of the daemons. I changed the symlinks a bit and got things running again. I’m hoping I got the filename formats right so that it doesn’t break tonight.

Here is a follow-up for anyone else scratching their head with this one. When I installed Ubuntu 18.04, it setup a resolv.conf with just as the nameserver. This fails to resolve my MIAB server’s hostname once BIND is installed.

I followed the instructions on stack overflow to re-configure the systemd-resolv so that it uses an external DNS resolver.

After that, I ran mailinabox/management/ssl_certificates.py which was able to acquire a certificate through LetsEncrypt. The certs and keys were moved around as expected by MIAB.

The UI still showed an error about the DNS not resolving but the ssl_certificates script seems to have the right information.

Update Restarting services (I just rebooted the MIAB server) resolved the message in the UI.