I've got a server that has two SSL certificates set up, one for internal access where it is accessed along the lines of host.my-local.net
and other for external access where it is accessed similar to 185.185.185.185
(this is not the actual IP address, but it is an IP address as there is no host name assigned to it). When accessed via the external address, the connection is going through a load balancer / firewall which I don't have any access to, all I know is that it translates incoming connections on a specific port into the internal address on the SSL port.
The problem is, when an external connection comes in, I get browser warning that the site is masquerading as host.my-local.net
; it is presenting the certificate for host.my-local.net
instead of 185.185.185.185
. I have a virtual host set up for both names in my apache2 config file, so I assume that for some reason the server is having trouble distinguishing between an external connection and a LAN connection. I haven't had this problem with a simple NAT, so I don't know why it would make a difference if the load balancer is making the request look like it's coming from the LAN instead of internally.
I have verified that the browser I am using support SNI (Google Chrome) and Apache 2.4 apparently supports it out of the box without requiring the NameVirtualHost directive. However, the documentation says:
In 2.3.11 and later, any time an IP address and port combination is used in
multiple virtual hosts, name-based virtual hosting is automatically enabled
for that address.
However, it's not the same IP address used in the two different virtual hosts, one is the internal (LAN) IP address and one is the external (world visible) IP address, so does that apply here?
To clarify my configuration, I have two virtual hosts set up, like so:
# here i specify the certificate for 185.185.185.185, e.g.
SSLCertificateFile /etc/ssl/private/185.185.185.185.crt
# here i specify the certificate for host.my-local.net, e.g.
SSLCertificateFile /etc/ssl/private/host.my-local.net.crt
No comments:
Post a Comment