I have a droplet running CentOS 8 that I’m attempting to set up certificates for both the www and root domains.

(foo* replaces actual domain name wherever it occurs in the following discussion).*

Certificates have been created for both foo.dev and www.foo.dev in the terminal via certbot.

I’m running Apache.

$ sudo certbot certificates

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: foo.dev
    Serial Number: ------------------------------DFD0
    Domains: foo.dev
    Expiry Date: 2020-11-19 16:21:14+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/foo.dev/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/foo.dev/privkey.pem
  Certificate Name: www.foo.dev
    Serial Number: ------------------------------E106
    Domains: www.foo.dev
    Expiry Date: 2020-11-19 19:38:52+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/www.foo.dev/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.foo.dev/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The virtualHost records (DocumentRoot points to the same location on the server):

$ cat /etc/httpd/conf.d/foo.dev.conf 
<VirtualHost *:80>
    ServerName foo.dev

    DocumentRoot /var/www/foo.dev
    ErrorLog /var/log/httpd/foo.dev-error.log
    CustomLog /var/log/httpd/foo.dev-access.log combined
</VirtualHost>


$ cat /etc/httpd/conf.d/www.foo.dev.conf 
<VirtualHost *:80>
    ServerName www.foo.dev

    DocumentRoot /var/www/foo.dev
    ErrorLog /var/log/httpd/www.foo.dev-error.log
    CustomLog /var/log/httpd/www.foo.dev-access.log combined
</VirtualHost>
$ 

I’m unable to connect in Safari to the root domain (foo.dev). The problem is a name mismatch.

Both foo.dev & www.foo.dev resolve to the same IP address.

When I check the server for foo.dev on digicert, (referencing certificate for www.foo.dev) indicates that “Certificate does not match name foo.dev”.

Apparently, when accessing the root domain (foo.dev), it’s using the certificate for the www subdomain (www.foo.dev, as opposed to foo.dev), causing
Safari to refuse to connect. (I can connect via Paw by accepting the mis-matched certificate).

I have A, AAAA, & NS(3) domain records for both the root domain (foo.dev) and www domain (www.foo.dev)

What is the suggested or preferred solution to handling SSL connections and certificates for both the root (foo.dev) and www (www.foo.dev) subdomain?

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.

×
3 answers

Hi there @larry99,

I believe that there is no need to have duplicate Vhosts for both www and non-www unless you want to show different content.

If this is not the case rather than having a separate Vhost for your www and your non-www versions, I would recommend adding your www version as a server alias to your main Vhost and removing the duplicate.

So your main Vhost will look like this:

/etc/httpd/conf.d/foo.dev.conf
<VirtualHost *:80>
    ServerName foo.dev
    ServerAlias www.foo.dev

    DocumentRoot /var/www/foo.dev
    ErrorLog /var/log/httpd/foo.dev-error.log
    CustomLog /var/log/httpd/foo.dev-access.log combined
</VirtualHost>

Then disable the /etc/httpd/conf.d/www.foo.dev.conf config.

That way when you generate the SSL certificate, it would include both the www and non-www in the certificate.

Let me know how it goes.
Regards,
Bobby

Hi,

As @bobbyiliev mentioned above, you do not need to separate vhost for www subdomain of foo.dev, unless their contents differ. But let’s try to solve your configuration problem as it is now. I mean two domains with two separate certificates.

Prerequisites. You use standard Centos8 droplet with all additional packages installed from official repositories.

Step 1. Modify ssl.conf file.

a. Make a copy of this file, just in case.

sudo cp /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.original

b. Comment (or remove) all lines of SSL Virtual Host Context (starting with <VirtualHost _default_:443>, and ending with </VirtualHost>), and save the file.

Step 2. Modify config files of your virtual hosts

<VirtualHost *:80>
  ServerName foo.dev
  Redirect permanent / https://foo.dev/
</VirtualHost>

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName foo.dev  
    DocumentRoot /var/www/foo.dev  
    ErrorLog /var/log/httpd/foo.dev-error.log  
    CustomLog /var/log/httpd/foo.dev-access.log combined
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/foo.dev/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/foo.dev/privkey.pem
  </VirtualHost>
</IfModule>

<VirtualHost *:80>
  ServerName www.foo.dev
  Redirect permanent / https://www.foo.dev/
</VirtualHost>

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerName www.foo.dev
    DocumentRoot /var/www/foo.dev    
    ErrorLog /var/log/httpd/www.foo.dev-error.log    
    CustomLog /var/log/httpd/www.foo.dev-access.log combined
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/www.foo.dev/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/www.foo.dev/privkey.pem
  </VirtualHost>
</IfModule>

Step 3. Restart Apache service and check if it is running OK

sudo systemctl restart httpd
sudo systemctl status httpd

In addition, you may want to improve your SSL/TLS configuration making it more strict, and/or add some logging options to it.

Thanks to everyone who took the time to answer my questions. In the process of attempting to fix the certificates, I ended up with some certbot error messages I wasn’t able to resolve.

Long story short … I recreated the droplet from scratch (this time, with plenty of snapshots along the way in case I messed something up, and good notes on all the steps involved), and by following exactly all the Digital Ocean tutorials, I was able to set up SSH, Apache, firewalld, VirtualHost, certificates for both the root and www domains, and a cron task to automatically renew the certificates when needed; and lastly, succesfully tested on Qualys SSL Labs website.

Thanks!

Submit an Answer