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 192.168.1.10 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:
192.168.1.10 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 (192.168.1.10:443).
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.
Had an interesting issue on CentOS 7.
Let's call my SSL domain www.domain.com, we'll say IP 192.168.1.10 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:
192.168.1.10 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 (192.168.1.10:443).
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Remedied by setting the default SSLEngine directive to "Off", so the only SSLEngine On was in the actual VirtualHost definition for my certificate.