I was following this guide which directed me here to get SSL certificates with Let's Encrypt. I successfully added one for my example.com main domain. I realized that my mail.example.com subdomain will need one, so tried the following:
# sudo letsencrypt --apache -d example.com,www.example.com,mail.example.com --email admin@example.com
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/example.com.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/example.com-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/example.com-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-enabled/example.com-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 example.com
Unable to set enhancement redirect for example.com
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/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/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 didn't really know why the redirect failed. Presumably because there wasn't a virtual host for mail.example.com. However, when I did choose to not redirect:
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Future versions of Certbot will automatically configure the webserver so that all requests redirect to secure HTTPS access. You can control this behavior and disable this warning with the --redirect and --no-redirect flags.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://example.com,
https://www.example.com, and https://mail.example.com
You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com.tk
https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
https://www.ssllabs.com/ssltest/analyze.html?d=mail.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/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"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
It seems to have passed the ssl test Let's Encrypt recommends I do. I don't actually know if this is acceptable or not, or if I actually have to go and make a virtual host. If that's the case, is it just a matter of willing it to existence with sudo nano /etc/apache2/sites-available/mail.example.com.conf , putting in the necessary info that these guides talk about and then rerunning sudo letsencrypt --apache -d example.com,www.example.com,mail.example.com --email admin@example.com ? In /etc/apache2/sites-available/example.com-le-ssl.conf I now have a new line saying ServerAlias mail.example.com .
Yes you should have a vhost configured for each subdomain.
Yes you should use the certificates you have already acquired and configure the (sub)domain(s) accordingly to use the cert containing the correct name(s).
If you are going to "test" and test again, please use the "staging environment" so as to conserve LE resources.
It is unfortunate that the guides you have referred to apparently don't mention the staging environment.
So, all I have to do is configure the subdomain, by creating a virtual host for it like how they are made in the guide? With sudo nano /etc/apache2/sites-available/mail.example.com.conf? And just use the same certificates I generated for the other virtual host example.com?
One thing, Rip. Do I do sudo nano /etc/apache2/sites-available/mail.example.com.conf or sudo nano /etc/apache2/sites-available/mail.example.com-le-ssl.conf? I seem to have a /etc/apache2/sites-available/example.com-le-ssl.conf file I don't remember creating, and I'm not sure how to distinguish the two types of .conf files.
You should have a set of configuration files already in /etc/apache2/sites-available.
Copy and EDIT them to configure your mail subdomain WITHOUT overlaps.
Make sure each vhost is unique. Then you'll have to enable the vhost.
I'll be honest, this redirect is extremely nonsensical anyhow. If you're using this for a mailserver, there's really no point in having an HTTP to HTTPS redirect since you never intend to use either protocol anyhow. Personally, I consider it a bug for certbot not to prompt for which domain names to implement a redirect. The message you received about upcoming certbot behavior prompted me to write an open message to the certbot developers.
Hi @griffin
True, but soon the redirect(s) will be automatic. If I'm not mistaken.
EDIT: But for mail services that don't use web interfaces, I agree.
EDIT: OP's linked resource guides the installation of postfix.admin and rouncube.
/etc/apache2/sites-available for me holds 000-default.conf and default-ssl.conf and example.com-le-ssl.conf and example.com.conf and example,com.conf.save
So, just to be clear, make files mail.example.com.confand mail.example.com-le-ssl.conf and make sure there are no overlaps? What do you mean by no overlaps, exactly? Apologies, as I'm new to TSL encryption.
Just to make things as clear as possible, I'll past the contents of each of the files.
example.com.conf (the identing in this pasted format is a bit weird):
My domain name is sangstar-mail.tk. It's a domain I'm using only in order to test successfully spinning up a mail server on it. Ideally, when I actually create a proper server, mail.example.com will serve different content to www.example.com and example.com, with the latter two serving the same content.
Q1: Will mail and regular web services be served from one single internal server IP?
[not sure if you have multiple servers or not]
Q2: Will the same web server be used to serve both mail and regular web service content?
[sometimes mail services require specific web servers - different to the default used for reg web]
Q1. Everything redirects to the server IP of one Digital Ocean Droplet, so I assume so. My mail subdomain has an A record that directs to the server IP and an MX record.
Q2. For this test case, the web server is just configured enough to have Apache and generate the SSL certificates. I've just followed the guide on what to do for it, but it is only serving me to spin up the mail server. To be honest, I'm a bit unsure about how to answer your question knowledgably since I'm so new to this subject but I don't see why the mail services I'm trying to spin up would require specific web servers different to the default used for reg web. Perhaps you could go over what would one then need to do in both cases, unless that would take too long?
Sometimes particular web services like ZIMBRA require their own particular web services.
They may be on Apache or NGINX, but customized for their particular use.
Then you want to add reg web services on top of that and they will fight for port 80 and 443.
So as long as the guide you are following is designed for both in mind, you should be fine.
