Browser pulls self-issued certificate


#1

My domain is: support.atims.com

My web server is (include version):
Apache/2.4.27 (Amazon) OpenSSL/1.0.2k-fips PHP/7.1.15

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

My hosting provider, if applicable, is: N/A

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

Certificate installation was successful; however, when I open the website in the browser, I get certificate error. It looks like the certificate is the self-issued one for ip-192-168-250-58 which is the internal DNS name of the machine. I changed hostname to external in /etc/sysconfig/network, and rebooted the box - but the certificate is still coming from internal DNS. Not sure what else I can check


#2

look through

/etc/apache2/apache.conf
/etc/apache2/sites-enabled/*.conf

for certificate use.

Somewhere you have a self-signed cert for your internal IP.

Or Try:
grep -Ri 'SSLCertificateFile' /etc/apache2/
to locate all files that have certs.


#3

The self-signed cert is quite new…
Please give some details on this:


#4

the file is /etc/httpd/conf.d/ssl.conf but otherwise spot on.

Now I am curious: I have <VirtualHost _default_:443> section in both ssl.conf and in vh-le-ssl.conf that is created by Let’s Encrypt. Both have SSLCertificateFile and SSLCertificateKeyFile values. Obviously the value in ssl.conf overrode the generated one. However, when I just commented out the “local” value in ssl.conf, apache wouldn’t start. I had to copy LE value to ssl.conf

So, now I have SSLCertificate mentioned twice… Is it by design? As a developer I prefer to keep everything DRY - otherwise it will get out of sync. What’s the best practice here?

Or it’s so far from the topic of LE, that I should go-ogle away?


#5

The version in your ssl.conf is a default that existed prior to your use of Certbot. Many other people have run into this problem that the default takes priority over the other virtual host. There are some options involving changing the special string _default_ to other things (like an IP address) or removing the entire <VirtualHost> stanza, since you don’t really need that once you have a valid certificate. However, removing an SSLCertificateKeyFile within an HTTPS virtual host isn’t allowed because every Apache HTTPS virtual host must have an associated private key.

I think we have to think a little more about why these _default virtual hosts sometimes exist and whether we can provide a more useful warning about them or a more useful change to them from Certbot.


#6

My “best practice” is to delete anything that is “default” - but that’s just me.


#7

Heh… not being security guru I am afraid to delete anything! But when I deleted the whole VirtualHost section, everything still works fine - and SSL Reports doesn’t complain, either. Gone! Thank you :sweat_smile:


#8

Glad to hear that.
Look into HSTS - you will probably get an A+ @ SSL Labs.


#9

@rg305 - I was scratching my head, why am I not getting A+ - and yes, HSTS was the culprit. I was also wondering why I didn’t have this problem on several servers that I built a few months back. I noticed that Certbot was actually updating ssl.conf itself; rather than creating a new file that ended up conflicting with ssl.conf
For now - it works, and I got quite an educational experience as well :grinning:
Thank you!


#10

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