Issue with SSL on www. subdomain

[brewbart]

Hello,

I tried searching for a solution and ran through some of the stuff I thought might help but its not. I ran certbot prior to having my virtual hosts set up correctly. I am currenty using Centos 7 and Certbot to create my ssl certificates. The domain is happyhandsprep.com. When I attempt to go to www.happyhandsprep.com I get the server mismatch
IE
The hostname in the website’s security certificate differs from the website you are trying to visit.
Error Code: DLG_FLAGS_SEC_CERT_CN_INVALID
Firefox
www.happyhandsprep.com uses an invalid security certificate. The certificate is only valid for happyhandsprep.com Error code: SSL_ERROR_BAD_CERT_DOMAIN

I added the virtual hosts to my config as follows
<VirtualHost *>
ServerAdmin admin@happyhandsprep.com
DocumentRoot /var/www/html
serverName happyhandsprep.com
ServerAlias www.happyhandsprep.com

I then attempted to update the cert using
sudo certbot --apache certonly -d happyhandsprep.com -d www.happyhandsprep.com.

It says it was successful but still when I go to the www. version it still throws the certificate error.

Any insight into how I can correct this would be appreciated.

[Patches]

Can you confirm with certbot certificates that you really have a certificate encompassing the www domain?

Did you reload Apache after issuing the new certificate?

Are the paths to the certificate defined in both VirtualHosts, just one, or some place they are inherited by both?

[mnordhoff]

There are several certificates for the domain. Some are for “happyhandsprep.com”, some are for “www.happyhandsprep.com” and some are for both.

https://crt.sh/?q=%happyhandsprep.com

The web server is currently using this older one, which is only for “happyhandsprep.com”.

https://crt.sh/?id=225376955

I’m not certain what “sudo certbot --apache certonly” does, to be honest. It may issue a certificate, and then not configure the web server to use it. Could you show us its output?

And the Apache configuration file(s)?

And also what @Patches said.

Edit: Additionally, you need to mind the Duplicate Certificate rate limit.

https://letsencrypt.org/docs/rate-limits/

[brewbart]

Found the following certs:
Certificate Name: happyhandsprep.com-0001
Domains: happyhandsprep.com
Expiry Date: 2018-01-04 19:44:12+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/happyhandsprep.com-0001/fullchain.pe m
Private Key Path: /etc/letsencrypt/live/happyhandsprep.com-0001/privkey.pem
Certificate Name: www.happyhandsprep.com
Domains: www.happyhandsprep.com
Expiry Date: 2018-01-04 20:15:13+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/www.happyhandsprep.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.happyhandsprep.com/privkey.pem

I did reload apache. How do i go about cleaning up the certificates and getting it to use the newest certificate?

[Patches]

So you have two certificates, one with and and without www, but the certificate that contains both is missing.

What is the output of?

ls -lR /etc/letsencrypt/archive
ls -lR /etc/letsencrypt/live

And what is the SSLCertificateFile currently configured with Apache?

[brewbart]

I really appreciate the replies. It guided me to the place where I had to be to fix the issue.

Essentially I went into the config that is pointed to by the
SSLCertificateFile which I found using grep -i -r “SSLCertificateFile” /etc/httpd/ and edited the virtual host there. I was unaware it was using that rather than my main httpd.conf file.

Once i updated it to use the latest certificate that had both URLs i am no longer throwing that security error.

Thanks a million for the help and this has been a huge learning experience in apache/centos7 and SSL certs

[rg305]

@brewbart

certonly

I think that will only get the cert and nothing more as you may have expected.

[schoen]

Agreed with @rg305 and @mnordhoff that certbot --apache certonly is not necessarily desirable. It will indeed obtain a certificate and not attempt to install it, which not very many Apache users have a reason to prefer.

certonly has various uses but is often meant for use with plugins like --webroot that don’t provide an installer functionality at all. --apache isn’t in this category.