Each domain is setup with an MX record pointing to “mail.domain.com” which is an A record pointing to the IP of the shared server. (No mail.domain.com sub-virtual server exists)
I had everything setup with let’s encrypt using virtualmin.
Dovecot handles POP3s access (port 995)
Everything worked fine for 3mo but the auto-renewal didn’t work for the “mail.domain.com” subdomains. Therefore the cert is missing it from the SAN list. It’s looking for http://mail.domain.com/.well-known/acme-challenge/TOKEN and fails with timeout. It succeeds with the other SANS
My workaround was to use certbot to manually expand the cert authenticating via DNS then manually copied it over to dovecot but ofcourse this isnt ideal since I always have to do it manually.
I don’t really understand how “/.well-known/acme-challenge/TOKEN” works. I don’t see any “.well-known” folder anywhere. Should there be a rewrite rule to point requests for that folder somewhere else?
Since you’re using CloudFlare for DNS resolution, a workaround that should work would be to create an “alias” Virtual Server pointing “mail.domain.com” to “domain.com”… Then when it’s trying to generate the LE certificate, it’ll be able to reach the “.well-known” directory of “domain.com” and should work.
The .well-known directory is created when the validation happens. There should be rules to exclude this path from any rewrites or proxy rules. You have to allow Apache to serve this path from the filesystem. Virtualmin does this automatically for web apps it installs, generally speaking, but htaccess might override that, or some other rules you or your app has put in place might also.
Hmm, " Failed to create virtual server : The domain mail.domain.com is already hosted by your Apache webserver"
Checking the apache conf, it has “ServerAlias mail.domain.com”
Let’s encrypt seems to only fail on “mail” with “Timeout during connect (likely firewall problem)” or at least that’s the only one that is reporting an error.
The only difference I see between “mail” and root/www is that mail is not proxied on cloudflare
OK, I figured out the issue, much more simple than I thought.
I decided to block http (port 80) in FirewallD since I thought I had no need for it.
Perhaps I can tie a firewall command to open port 80 (if closed) when the certbot tries to validate, then close the port afterwards. Any recommendation on how to implement this such that it doesnt get overwritten in future webmin/virtualmin updates?