Certificate coming up as invalid

Help
#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

The main domain bearclaw.io is pointed to a different server, so I am not 100% sure if that is the issue.

My domain is: dev.bearclaw.io

I ran this command: certbot --apache

It produced this output: Gave me the congrats message that the certificate was setup

My web server is (include version): Apache 2.4.6

The operating system my web server runs on is (include version): CentOS 7

My hosting provider, if applicable, is: liquidweb.com

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): webmin

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.11.0

1 Like
Improving instructions for complete newbies
#2

Hi @sektor1952,

Maybe you can try

sudo grep -ir SSLCert /etc/httpd

to see where different certificates are configured in your Apache setup. It looks like a default non-publicly-trusted certificate is still taking precedence over your new Let's Encrypt certificate, for some reason.

1 Like
#3

Here is the output from the above command.

/etc/httpd/conf/httpd.conf:SSLCertificateFile /etc/letsencrypt/live/dev.bearclaw.io/cert.pem
/etc/httpd/conf/httpd.conf:SSLCertificateKeyFile /etc/letsencrypt/live/dev.bearclaw.io/privkey.pem
/etc/httpd/conf/httpd.conf:SSLCertificateChainFile /etc/letsencrypt/live/dev.bearclaw.io/chain.pem
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateFile at a PEM encoded certificate. If
/etc/httpd/conf.d/ssl.conf:SSLCertificateFile /etc/pki/tls/certs/localhost.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# the referenced file can be the same as SSLCertificateFile
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

1 Like
#4

This is related to various other problems with CentOS Apache defaults that have cropped up over the years, but I suspect the problem is that you have a default VirtualHost (e.g. for _default_) instead of a VirtualHost that specifies a specific servername. So, the default VirtualHost in httpd.conf conflicts with the default VirtualHost in ssl.conf, resulting in the latter taking precedence for some reason, and serving the localhost.crt instead of the Let's Encrypt certificate.

If this hypothesis seems plausible to you, could you change httpd.conf to indicate your server name explicitly? Alternatively, you could make a new .conf file with a new non-default VirtualHost specifically for your site, and then run Certbot again?

You can find more information about specifying names for VirtualHosts in Apache configurations at

https://httpd.apache.org/docs/2.4/vhosts/examples.html

2 Likes
#5

Here is the interesting thing all 3 servers are configured the same way with the default vhost like you mention and they work fine.

#6

That is interesting, but there are some tricky things even about alphabetical order (!) in the CentOS Apache defaults, leading to cases where default certificates were or were not used depending on the alphabetical position of the filename.

#7

I agree it is interesting, but also puzzling as well and I don't use the default vhost entries.

#8

Could you try

sudo httpd -t -D DUMP_VHOSTS

to see exactly what the virtual host configuration actually looks like here?

Multiple certificates conflict
#9

Here you go, sorry for the delay in response.

VirtualHost configuration:
*:80 dev.bearclaw.io (/etc/httpd/conf/httpd.conf:354)
*:443 is a NameVirtualHost
default server dev.bearclaw.io (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost dev.bearclaw.io (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost dev.bearclaw.io (/etc/httpd/conf/httpd.conf:361)

#10

This represents a conflict: you can't explicitly specify the same name and port in two different virtual hosts on the same machine. (Or as @rg305 would say, you can, but Apache will "run at all costs" and just randomly pick one instead of refusing to choose between them—in this case, apparently randomly picking the one with the localhost cert instead of the valid Let's Encrypt cert.)

3 Likes
#11

That did it, I honestly didn't even notice the other 443 host. I guess having another pair of eyes helped.

Thank you for your assistance.

2 Likes
#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.