SSL Certificate hostname mismatch through WAN link

RHochstenbach · September 11, 2015, 04:57:36 AM

First of all, I hope that I've posted this in the correct forum. If not, please move it for me

We have an appliance in our organization that accepts HTTPS connections and uses a signed SSL certificate (by Comodo). Some of our customers are connected to a large WAN network provided by an ISP (comparable to AT&T Exchange). It's a closed Internet environment. We are connected to that network as a service provider using a router and a VPN tunnel to that WAN.

The appliance has been connected to that WAN router through a switch by using its 2nd network adapter. The computers at the customers use a DNS server where the hostname of our appliance resolves to the internal IP address, so they don't connect over the public Internet. The computers being used by those customers (all are iMacs) can't connect properly to our appliance, because of a certificate error. After investigating, this appears to be a Hostname Mismatch. I've verified that the computers are connecting to the appliance by hostname, and that the hostname matches the CN in the certificate.

My next step was checking if there was something wrong with the appliance. So I've connected a laptop (a Macbook to match the OS on the customers' computers) to the same switch as the 2nd network adapter of the appliance is connected to. I was able to connect and I didn't see any certificate errors. So I think it's caused by something in the WAN.

I had a thought that it might be caused by a reverse proxy in the WAN, but the certificate that was received by these computers was the same certificate that is sent by the appliance. So that wasn't likely to be the case. The provider of the WAN network confirmed that there wasn't any proxy being used in their network.

You can find the topology in the attachment

Does anyone have a clue why this is happening? A temporary workaround is manually trusting our certificate on all those computers.

deanwebb · September 11, 2015, 08:47:47 AM

Looks like the right section of the forum to me. Hello!

The devices connecting to the HTTPS server need to be able to resolve the hostname of the Comodo CA, which will be on the big Internet. That means that they need DNS support to get the correct IP and then allow traffic to the CA's IP address from that network. If those Macs don't have Internet access, then they'll never properly resolve the HTTPS cert.

RHochstenbach · September 11, 2015, 09:45:47 AM

Thanks for your reply

I haven't thought of that. I've always assumed that the certificate authorities where already trusted on most operating systems.

SimonV · September 11, 2015, 10:13:17 AM

Are you positive that they are using the exact same FQDN, and that the loadbalancer is presenting the same certificate when they are connecting from the LAN?

RHochstenbach · September 11, 2015, 10:29:22 AM

Quote from: SimonV on September 11, 2015, 10:13:17 AM
Are you positive that they are using the exact same FQDN, and that the loadbalancer is presenting the same certificate when they are connecting from the LAN?

Yes I am. I had one of our engineers on-site who confirmed that the FQDN is correct, and the presented certificate is 100% identical to the one being sent from our appliance.

deanwebb · September 11, 2015, 10:30:38 AM

Quote from: RHochstenbach on September 11, 2015, 09:45:47 AM
Thanks for your reply
I haven't thought of that. I've always assumed that the certificate authorities where already trusted on most operating systems.

They are trusted, but they still have to reach the CA to determine if the certificate being presented is both valid and unexpired.

RHochstenbach · September 11, 2015, 12:53:29 PM

I have just tried something to test this theory. Had a computer connected to that network, and made sure that it didn't have any other connections. Even removed the default gateway, so it would definitely not be possible to reach the Internet. When I enter the FQDN of the appliance (I've added the FQDN to the Hosts file), I don't get a certificate error. So the lack of a working Internet connection doesn't seem to be causing this issue, I guess.

SimonV · September 11, 2015, 01:19:03 PM

Quote from: deanwebb on September 11, 2015, 10:30:38 AM
Quote from: RHochstenbach on September 11, 2015, 09:45:47 AM
Thanks for your reply
I haven't thought of that. I've always assumed that the certificate authorities where already trusted on most operating systems.
They are trusted, but they still have to reach the CA to determine if the certificate being presented is both valid and unexpired.

Not sure, the clients have the root CA's public key on-board which is used to verify if the privately signed certificate is valid. The only reason they would phone home is to check the revocation list, but I don't think it would spawn a cert error. Wouldn't it be a daily nuisance in enterprise environments in that case? For example - our guest network uses a publicly signed certificate on the captive portal, but there's no way the clients can get to the internet without first passing through that portal. And it does seem odd it generates an invalid hostname error, which usually points to a DNS issue.

Have they by chance tested from that exact same location with a Windows box instead of Macs? Are their browsers configured to use the right version of SSL/TLS?

RHochstenbach · September 11, 2015, 01:29:36 PM

Quote from: SimonV on September 11, 2015, 01:19:03 PM
Have they by chance tested from that exact same location with a Windows box instead of Macs? Are their browsers configured to use the right version of SSL/TLS?

Yes, that has been tested as well. Google Chrome shows the same error. Internet Explorer does not, and loads it normally. The appliance supports TLS 1.0 and above. Mac OS X supports this since 2002.

SimonV · September 11, 2015, 01:51:00 PM

Are they by chance using a proxy server in their browser? How about DNS, are they internally forwarding to your internal nameservers?

deanwebb · September 11, 2015, 02:05:14 PM

It was my experience (this was with a cert from another vendor, but still pre-installed on browsers) that if our guest wireless pre-auth ACL did not allow DNS to an external DNS server and HTTPS to the CA of the vendor, devices would get a cert error on the HTTPS connection to the guest logon webpage. When I saw internal Macs having no issue and Macs in a controlled area having an issue, that was my first thought.

Try opening up those ports, anyway, and see if it works. If not, well, I'll learn something new.

RHochstenbach · September 11, 2015, 03:46:01 PM

Quote from: SimonV on September 11, 2015, 01:51:00 PM
Are they by chance using a proxy server in their browser? How about DNS, are they internally forwarding to your internal nameservers?

I've verified the proxy configuration, and none is configured. Their DNS servers have been made authorative for our domain, having its records point to our internal IP addresses.

RHochstenbach · September 11, 2015, 03:51:11 PM

Quote from: deanwebb on September 11, 2015, 02:05:14 PM
It was my experience (this was with a cert from another vendor, but still pre-installed on browsers) that if our guest wireless pre-auth ACL did not allow DNS to an external DNS server and HTTPS to the CA of the vendor, devices would get a cert error on the HTTPS connection to the guest logon webpage. When I saw internal Macs having no issue and Macs in a controlled area having an issue, that was my first thought.

Try opening up those ports, anyway, and see if it works. If not, well, I'll learn something new.

I'll check with the provider to see if they can open this up. It's a huge telecom company in my country, and their engineers are noobs. I've one had an issue with them where traffic from one of our appliances was being sent to an unknown IP address. After investigating, we had to tell them that the IP address in question was the NAT address of their main firewall. Each segment of the network is being maintained by a different department. They even have firewalls within Trust zones...

AnthonyC · September 14, 2015, 08:41:07 PM

You don't need internet access if your appliance is doing SSL offload/termination provided that you have a certificate bundle that has a chain certificate issued by the CA and a signed certificate from the CA. You will need this to be stored on the trusted storage on that appliance.

https://en.wikipedia.org/wiki/Intermediate_certificate_authorities

You should able to find the process of how to do this from the appliance vendor config/manual. Often you will need to use openssl CLI to verify if the chain of trust is working or not.

RHochstenbach · September 15, 2015, 06:15:06 AM

Quote from: AnthonyC on September 14, 2015, 08:41:07 PM
You don't need internet access if your appliance is doing SSL offload/termination provided that you have a certificate bundle that has a chain certificate issued by the CA and a signed certificate from the CA. You will need this to be stored on the trusted storage on that appliance.

https://en.wikipedia.org/wiki/Intermediate_certificate_authorities

You should able to find the process of how to do this from the appliance vendor config/manual. Often you will need to use openssl CLI to verify if the chain of trust is working or not.

The chain has been loaded in the Trust Store. What's even more weird is when I plug that same computer in our local switch (circumventing the WAN), it's not having those issues.