Problem auto-renewing webmail SSL certs

Community Support Mail
1

Not sure if this is just my configuration, or whether its a wider problem. I have a domain on my Hestia server. The website SSL cert renews fine, but I just got an email warning from Letsencrypt telling me that the webmail.domain.com and mail.domain.com certificates were going to expire.

I tested them and the information was correct. They were going to expire in 20 days.

cat domain.com.crt | openssl x509 -noout -dates

Not an emergency, but shouldn’t they be auto-renewing, along with the web domain certs, which were created at the same time?

I went into control panel, edit mail domain, and removed SSL, and then added it in again. I got this message, and the cert refused to update.
Error: Let’s Encrypt validation status 400. Details: Unable to update challenge :: authorization must be pending

So it seems that this might be why the certs refused to auto-renew as well? Any ideas what’s going on? (At the moment no SSL on that mail domain, although I guess I could pull the certs out of a backup.)

2

I’ve been digging around. Tried to restore the /home/user/conf/mail/ directory from a backup, but that didn’t work. Tried editing /usr/local/hestia/users/username/mail.conf as well and restarting all services, but that didn’t roll back the mail ssl config either, so I guess I’ll just leave it for now.

Nothing in /var/log/hestia/system.log (seems it doesn’t log any information on a fail)
Nothing in /var/log/apache2/domains/domain.com.error.log or webmail.domain.com.error.log (where does the mail domain log its info?)

Tried running a few v-blah-mail/ssl/letsencrypt scripts with bash -x but nothing useful in there either. So can’t really dig up any debug info, sorry.

3

Normally 400 means the well-known/xxx can’t be found

Any info regarding setup?

4

I don’t really know what info I can give. Can’t find any logs for the mail domains. I know how the letsencrypt renewal process works for web domains, and that seems to be working.
But the renewal process for SSL on mail domains seems to be broken on all mail domains on the server. I’m seeing
LETSENCRYPT_FAIL_COUNT=‘11’ etc.
In all the /usr/local/hestia/data/users/*/mail.conf files
Where is letsencrypt looking for .well-known? Is it in the roundcube directory maybe? I’ll check. Oh, maybe roundcube has some logs as well … back in a minute.

5

OK, getting there … so I can’t find where roundcube logs errors, the files in /var/log/roundcube/error* were empty.

So then I looked in /var/lib/roundcube/ and found a .well-known directory, and in .well-known/acme-challenge, there were a bunch of auth files from the past couple of weeks, owned by the user which owned the mail domain. Suspicious. So the LE server wasn’t finding them. OK, so then I went to /etc/roundcube/htaccess, and found that a Basic Auth stanza I’d put in there was blocking access! OK, so I took that out, and after a couple more tries, and after restarting everything, I got the mail domain’s SSL certificates to renew. Phew.

So anyway, it was my fault. The config that had worked on the previous versions of Vesta and Hestia had stopped working with the new mail domain SSL arrangement. (From domain.com/webmail to webmail.domain.com

Guess I’ll have to re-write that Basic Auth stanza to ignore .well-known.

6

/var/log/nginx/domains/webmail.*.error.log

Normally

1 Like
7

OK, so for anyone else who likes to put basic auth on their roundcube webmail, the lines that need to go into /etc/roundcube/htaccess are as follows

 <IfModule mod_authn_file.c>
     AuthType Basic
     AuthName Private
     AuthUserFile /path/to/webmail.passwd
     Require expr %{REQUEST_URI} =~ m#^/.well-known/acme-challenge#
     Require valid-user
 </IfModule>

Which is basically saying, exempt that URL from password protection, so that letsencrypt can do its job.
/var/lib/roundcube/.htaccess is symlinked to /etc/roundcube/htaccess

8

Good to know. As I was working with htaccess I was assuming the logs would be under the apache directory! So now I know webmail access logs are in /var/log/nginx instead!

9

I know due the fact we use nginx as proxy all the logs are created in /var/nginx/*

For the main domains this has been changed to /var/apache2/domains