CentOS 7 + hostfile entry + SSL certificate domain mismatch error

I've supported SSL certs and configured servers for years, so no newb here.

Had an interesting issue on CentOS 7.  
Let's call my SSL domain www.domain.com, we'll say IP is setup in the virtual host directive (Apache 2.4.6 / OpenSSL 1.0.2k-fips
And the server hosting it linux.domain.local, a CentOS 7.4.1708 box.

Cert is installed, and answering to www.domain.com, everything is good.

Here's where the issue rears it's ugly head -
For some local software, ansible + jenkins, we have to make a host file entry back to the machine's IP itself, so in my etc/host file, I placed:   www.domain.com

When I restart apache / openssl, I then get a domain mismatch warning in a browser when visiting the site. If I go to www.domain.com, it gives the mismatch , and when viewing the cert via the browser (view cert), it says the servername is actually linux.domain.local.

If I REM out the /etc/hosts file entry, and restart apache, SSL works as expected.

When the entry is in /etc/hosts, it appears to grab the rDNS name of the machine rather than serving up what I have specified in the <Virtualhost> directive.
To pre-answer, Yes, the directive ServerName is www.domain.com, and the virtual host is setup specifically with the IP:port (

Never seen this on any other Linux / RMP based flavor. One workaround seems to be setting the rDNS, but I don't want to rely on that for our production server(s).
I'd rather know WHY CentOS 7 has this issue, I have found others reporting the same....bug?

Anyone heard of this, and gotten to the bottom of it?

Update -
I went a bit further with testing, and set the rDNS for the IP to the www.domain.com (previously, it was set to linux.domain.local).
Upon restarting apache,  SSL "broke" and thought it was serving up linux.domain.local.  
So in a nutshell, what I'm seeing is, when you restart apache / openssl, if the rDNS OR an entry in the hosts file MATCHES the FQDN SSL cert name (www.domain.com), SSL loads as the local machine name (linux.domain.local) rather than the www.domain.com.
LVL 12
Kent WSr. Network / Systems AdminAsked:
Who is Participating?
Kent WConnect With a Mentor Sr. Network / Systems AdminAuthor Commented:
I finally found a work-around /fix.

This is Apache 2.4.6 so there is no "NameVirtualHost" to turn off.

On your suggestion, I listed the virtual hosts, and the _default_ came back to the local machine name (not www.domain.com which is the actual SSL site)

In the default <VirtualHost _default_:443> I had to
SSLEngine off

That made it not default to the machine name upon machine start up if the mentioned hosts file or rDNS entries were present.
Keep in mind I have a full VirtualHost directive defining the actual SSL site and cert, keys, etc.

In older Apache versions, or older CentOS versions (not sure which is the culprit thus far) this directive is ignored if you have a VirtualHost defining the IP.

To break this default, all one has to do is take the actual IP / FQDN of the secure site, place it in /etc/hosts AND/OR set the rDNS of this IP to the actual site name (matching the SSL domain), restart Apache, and BAM, it breaks every time.

Questions - Bug? Is the culprit Apache? Or CentOS 7?
arnoldConnect With a Mentor Commented:
Does the system have multiple IPs?
Checking on the config suggests you have hostname in the Apache config
Use httpd -D virt_host ..use httpd -D to display the virtual host table.
Kent WSr. Network / Systems AdminAuthor Commented:
Arnold helped figure this out, when I listed the host names  and found the local machine name vs. FQDN Common Name on the SSL cert.  Although this has never been an issue in older Apache / OpenSSL implementations, I had to turn off the default "SSLEngine On".  Otherwise, if the rDNS or hosts file entry matched, the https connection gave a 401.3 error.
Remedied by setting the default SSLEngine directive to "Off", so the only SSLEngine On was in the actual VirtualHost definition for my certificate.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.