If I were in your situation, I would do the following:
A separate certificate dedicated to mail.example.com; this will isolate issues with your mail and web services from each other. If mail messes up during renewal, it should not bring down your web systems.
A dummy vhost for HTTP-01 OR (preferably) DNS-01 authentication via acme-dns for mail.example.com
You can re-use your mail.example.com certificate between SMTP server and web server if you wish. If you don't end up hosting a webmail system, or anything else, on that domain then you won't need to run any web services on it.
In this situation though:
You need the mail.example.com certificate for your SMTP services
The easiest way to get that certificate, is by setting up a virtualhost for mail.example.com and using the HTTP-01 challenge
Thank you all for the responses so far. If it helps, the person I'm working with has informed me that we do not intend for the same web server to be used to serve both mail and regular web service content, and the email will definitely be on a different subdomain.
If they both share the same external IP, then you will have to compensate.
If they each have their own external IP, then treat them as separate systems and things will work easier.
If you are actually using a separate server for mail..... Then you don't technically need to configure a ServerAlias in this case. Just use mail.sangstar-mail.tk Don't just make one up if it doesn't exist. And IMHO don't use the same name that is configured as ServerName..
You should, however, create email aliases for "root" and/or your main email account for "webmaster@, abuse@, etc.
There's no reason to create them all as individual e-mail accounts. You can just set up forwarders that lead to a generic site.admin@ account and set up a filter for that in your mail client to keep the noise isolated.
You'll want them, because:
webmaster@ is where good natured people do things like report broken links, it happens more than you'd think!
abuse@ is nice to have, it sometimes keeps people from going directly to your host / data center / bandwidth provider in the event that someone found a way to use your server to send SPAM.
postmaster@ is handy to check, and make sure root's mail is also sent there, at the least it will show you if your mail server is configured incorrectly, it will also catch bounces that let you know you have a spammer.
hostmaster@ is strongly recommended by RFC2142 as a well-known mailbox name for your DNS zone's SOA record.
Then following the guide I originally posted here, I put:
**sangstar@mail** : **~** $ sudo systemctl reload apache2
Job for apache2.service failed.
See "systemctl status apache2.service" and "journalctl -xe" for details.
I tried systemctl status apache2.service which said:
Which I'm unsure what to make from. I figured I'd carry on and try sudo apache2ctl configtest which outputted:
AH00112: Warning: DocumentRoot [/var/www/mail.sangstar-mail.tk/html] does not exist
(2)No such file or directory: AH02291: Cannot access directory '/var/www/mail.sangstar-mail.tk/logs/' for error log of vhost defined at /etc/apache2/sites-enabled/mail.sangstar-mail.tk.conf:1
AH00014: Configuration check failed
Action 'configtest' failed.
The Apache error log may have more information.
For some reason, /var/www/mail.sangstar-mail.tk/logs/error.log does not exist.
Also, I'm not sure what I'd put in for this if I were to make a mail.example.com-le-ssl.conf file:
<VirtualHost *:443>
ServerName mail.example.com
"all that stuff"
That seems to have worked. With that, here's what I've inputted. The redirecting issue seems to remain, and is still unable to find the vhost, despite Site mail.sangstar-mail.tk already enabled
**sangstar@mail** : **~** $ sudo systemctl reload apache2
**sangstar@mail** : **~** $ sudo apache2ctl configtest
Syntax OK
**sangstar@mail** : **~** $ sudo nano /etc/apache2/sites-available/mail.sangstar-mail.tk.conf
**sangstar@mail** : **~** $ sudo letsencrypt --apache -d sangstar-mail.tk,www.sangstar-mail.tk,mail.sangstar-mail.tk --email sangstar@sangstar-mail.tk
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/sangstar-mail.tk.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/sangstar-mail.tk-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/sangstar-mail.tk-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/sangstar-mail.tk-le-ssl.conf
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Failed redirect for sangstar-mail.tk
Unable to set enhancement redirect for sangstar-mail.tk
Unable to find corresponding HTTP vhost; Unable to create one as intended addresses conflict; Current configuration does not support automated redirection
**IMPORTANT NOTES:**
**- We were unable to set up enhancement redirect for your server,**
**however, we successfully installed your certificate.**
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/sangstar-mail.tk/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/sangstar-mail.tk/privkey.pem
Your cert will expire on 2021-04-21. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
I would ignore the previous problems/error messages and move forward from where we are now.
The first cert was issued one week ago.
You have made many changes since then (and before).
I can't be 100% sure why anything happened now.
I can be 100% sure you have a cert.
And we can test that it can be renewed now (with your current config).
If that fails, then we need to modify it.
If it works, then we can stop fixing it - LOL
Doesn't matter; any cert with the name you need on it would work.