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/
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.