New certificate installed - getting fails in the browser

Help
1

Hi all,

We’re setting up a new server, hoping to get Certbot on it early. Things seemed to work nicely, but we’re running into some real strange weirdness. The certificate installs just fine and clean, but when we go to the site, the redirect hits and we’re faced with a:

Your connection is not private

Attackers might be trying to steal your information from viola.rcsipublishing.com (for example,
passwords, messages, or credit cards). Learn more

NET::ERR_CERT_AUTHORITY_INVALID

Running the following produced this:

echo | openssl s_client -connect viola.rcsipublishing.com:443 -servername viola.rcsipublishing.com 2>/dev/null | awk '/Certificate chain/,/—/'

Certificate chain
0 s:/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=viola.rcsipublishing.com/emailAddress=root@viola.rcsipublishing.com
i:/C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=viola.rcsipublishing.com/emailAddress=root@viola.rcsipublishing.com

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: viola.rcsipublishing.com

I ran this command: certbot --apache

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Which names would you like to activate HTTPS for?

1: viola.rcsipublishing.com

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1
Obtaining a new certificate
Created an SSL vhost at /etc/httpd/conf.d/viola.rcsipublishing.com-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/viola.rcsipublishing.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
Redirecting vhost in /etc/httpd/conf.d/viola.rcsipublishing.com.conf to ssl vhost in /etc/httpd/conf.d/viola.rcsipublishing.com-le-ssl.conf

Congratulations! You have successfully enabled https://viola.rcsipublishing.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=viola.rcsipublishing.com

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/viola.rcsipublishing.com/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/viola.rcsipublishing.com/privkey.pem
    Your cert will expire on 2020-07-01. 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

My web server is (include version):

Apache 2.4.6

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

CentOS Linux release 7.7.1908 (Core)

My hosting provider, if applicable, is:

Self

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):

No

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

certbot 1.3.0

If anyone could give me a hand with this, it’d be appreciated. Especially if someone could let me know how to fill in the SomeCity/SomeOrganization that’s plaguing the certificate, it’d be appreciated

1 Like
2

Hi @daemionfox,

That is a self-signed certificate that came by default on your system. This reminds me of a common problem with CentOS in the past (that I thought we had now successfully fixed in Certbot!)—could you look at your configuration in /etc/httpd/conf.d and see if there is an ssl.conf file that defines a default HTTPS virtual host?

1 Like
3

Yes, yes, that file does exist, and yes, it’s calling for a default:443

Let me remove that from the system and then re-add the Listen directive…

That did it! Thanks a bunch!

1 Like
4

I will say, that this is a virgin install. PHP, Apache, Mysql, Certbot, all on a brand new box, so I was a little surprised to run into this issue so quick. The self-signed cert makes sense, just wish it had been more obvious to me what was going on.

Thanks again

1 Like
5

Yes, I think it’s a bug in Certbot that this doesn’t work in the default CentOS install. But again, I thought it had already been fixed in an earlier version. So I’ll bring this up with some of my colleagues and see if there’s some reason why it’s still not working in your environment.

Thanks for letting us know about your problem!

1 Like
6

I do it differently, cerbot could do it that way as well.
On CentOS (5, 6, and 7 are the same), the file /etc/httpd/conf.d/ssl.conf is shipped with mod_ssl package. The following files (self-signed certificate) are created at the installation time of that package:

/etc/pki/tls/certs/localhost.crt
/etc/pki/tls/private/localhost.key

I take care to do only the minimal quantity of modification. So, I do the following.

  1. Add the certificate related files to the standard location of CentOS:
/etc/pki/tls/certs/example.com.crt
/etc/pki/tls/certs/server-chain.crt
/etc/pki/tls/private/example.com.key
  1. Replace localhost.* files with symbolic links:
/etc/pki/tls/certs/localhost.crt -> example.com.crt
/etc/pki/tls/private/localhost.key -> example.com.key
  1. Do the minimal modification as well in /etc/httpd/conf.d/ssl.conf, (only remove the comment character):
121c121
< #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
---
> SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
  1. After reloading the apache server, everything works like charm.
1 Like
7

There is a similar thing on debian/ubuntu, they call it snakeoil certificate, but it doesn’t interfere with any others (and I can’t recall if it’s enabled by default). Anyhow, it should send BOTH, not the selfsigned one only.

1 Like
8

@daemionfox, would you be willing to share the contents of your configurations in /etc/httpd/conf.d to help us investigate this bug? Do you still have a copy of the ssl.conf file?

It looks like this is related to a bug about Certbot’s interaction with the CentOS Apache configuration that we fixed in the past, but something seems to have changed in either Certbot or CentOS to make a form of this bug reappear in some circumstances.

2 Likes
9

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