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 13
Kent WSr. Network / Systems AdminAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.