Question

How does one make LetsEncrypt secure www subdomain properly?

Following along the tutorial for securing Apache on Ubuntu 14.04, I first created the certificate for the base domain, let’s say, mydomain.com. This created an SSL config file at /etc/apache2/sites-available/mydomain.com-le-ssl.conf which linked to the SSL paths as below:

SSLCertificateFile /etc/letsencrypt/live/**mydomain.com**/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/**mydomain.com**/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/**mydomain.com**/chain.pem

Later on, I created the SSL certificate for the www sub-domain by running the following command given in the tutorial:

certbot-auto --apache -d www.mydomain.com

Again, the SSL certificate was created fine. But, this is where the odd behaviour starts. Instead of creating a separate SSL config file for the www subdomain, LetsEncrypt rewrites the mydomain.com-le-ssl.conf with the following SSL paths:

SSLCertificateFile /etc/letsencrypt/live/**www.mydomain.com**/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/**www.mydomain.com**/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/**www.mydomain.com**/chain.pem

Now, why is this a problem? Because, it turns my canonical url from https://mydomain.com to https://www.mydomain.com

Additionally, trying to load https://www.mydomain.com throws an SSL error saying it belongs to the wrong domain.

In my Apache virtual host for the domain, I have the following redirect as per Apache documentation linked here:

 ServerAdmin admin@mydomain.com
 ServerName mydomain.com.com
 ServerAlias www.mydomain.com
 Redirect permanent "/" "https://mydomain.com/"

Does anyone here in the D.O community know why LetsEncrypt handles the www subdomain like this? It creates a proper sub-domain SSL config file for any other sub-domain (say, dev or test or whatever), but when it comes to the www sub-domain, it overwrites the paths in the main ssl config file.

I even tried creating a www.mydomain.com-le-ssl.conf file with the proper SSL paths and didn’t get any error when restarting Apache, but the SSL errors in the browser persist when trying to load https://www.mydomain.com, where it should instead redirect to https://mydomain.com as per the Apache vhost redirect configuration.

I would very much appreciate any assistance that would throw some insight into this issue.


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

@cloudnine

Ideally, when you create a certificate using LetsEncrypt, you want to pass them both at the same time.

i.e.

-d mydomain.com -d www.mydomain.com

Using the above, regardless of whether you’re using www or another sub, should work without any issues and prevent any potential errors or conflicts in the configuration.

You can always delete the existing configuration and SSL certificates and start over using the above without any issues as long as the DNS is working properly.

You can also extend that as needed:

-d mydomain.com -d www.mydomain.com -d www2.mydomain.com -d www3.mydomain.com

@ jtittle1 Thank you, this worked well for RHEL 7.6

@cloudnine

From what I can see, you need to make sure you remove the configuration from these directories:

/etc/letsencrypt/archives
/etc/letsencrypt/live
/etc/letsencrypt/renewal

Don’t actually delete those directories, rather, cd in to them and remove the domain configuration as needed, then run the command passing both to create new configuration files.

Looking over the options, the only other option I see is using revoke, though in the past, when and if an error pops up, I’ve always removed the configuration and started fresh.