Outlook on Exchange using wrong certificate

 Many of us encountered this error:

The name on the security certificate is invalid or does not match the name of the site.

But this time, it was something different.

Not my image, but the exact error. (Source not found)

99% that it's not the solution you are looking for. But I will still fill the gap for the 1% that may encounter it.

I will explain every step I did until I found the problem. There are some solutions that I've tried that didn't work for me, but might for you, so you may try them.
*If you don't want to read it all, just jump directly to my solution down below.

The System:
SBS 2008 (server 2008 + exchange 2007)
*The solution may also apply for greater versions of exchange.

The problem:
As we began upgrading people to outlook 2010 there were errors popping about the certificate.
So the first thing I did was issuing a certificate from GoDaddy and installing it using the SBS console.
It didn't fix the problem.
The server is pretty old, and it wasn't me who installed it in the first place and it wasn't me who maintained it for several years, so I decided to go the manual way.



The steps before I found the cause:
So I went into installing the certificate using exchange shell:
First run:

Get-ExchangeCertificate

You will get a list of the certificates that may be used by exchange. Locate the right certificate's Thumbprint first. If you're having trouble locating it, then try going to "Administrative Tools" -> "Certificate Authority" -> "Issued Certificate", open each certificate until you find the one you have issued, then go to "Details" and locate the Thumbprint from there.
After that, run the command below, to install the certificate for all services:

Enable-ExchangeCertificate -Thumbprint -Services POP,IMAP,SMTP,IIS

Unfortunately, it still didn't fix the problem.

Let's check whether the certificate is used in IIS:

Image source: http://www.sslshopper.com/article...

The fastest way is to go to the web and see what certificate is being used inside your network for http over ssl site. e.g. https://yourdomain.local.
In case you see that a wrong certificate is being used, you can go to IIS Manager, choose your "Web Site" (Usually "SBS Web Applications" for SBS 2008 or "Default Web Site" for SBS 2011), then on the right choose "bindings", select "https" and then "edit" and there choose the right "SSL certificate".

In my case, IIS was using the right certificate.
So what's the matter with it?

The mistake:
Pretty funny of me, but we all make mistakes, and forget to look at things we should've looked in the first place. In my case, it was the certificate error itself.
As you see, the first raw, in the error, represents the address outlook is trying to connect through. In my case the address was fine, so I clicked on "View Certificate...".
And here I found the cause to the problem, the certificate was wrong. But not just wrong, I haven't seen such certificate on the server, and it was issued to some strange address: "my.firewall".
Wait, what?
Like I wrote above, I made sure exchange is the right certificate. So it's sending me some wrong certificate instead. You know what? Let's resolve the IP address, using the address outlook is connecting through:

ping address
my outside ip

What? But I'm connected locally. I should receive the local server's IP!
Ok, let's try nslookup:

nslookup
address
my local ip

Ok, now I get it. For some reason the client has fallen back to use the secondary DNS, which is configured to Google Public DNS.

Problem found:
What is going on, step by step:

1. Clients fall back, for some reason, to the secondary DNS IP.
2. The secondary DNS in our network is Google Public DNS, as a fall back in case the server goes down.
3. Client's machine first resolve the IP of the exchange using the given exchange domain address.
4. Google's DNS returns our outside IP.
5. Outlook is trying to connect to the given IP using HTTPS.
6. The router loopbacks to himself, because he received his own outside address
7. Router sees that the requesting address (the client's address) is inside the LAN, therefore treats it as such. And connects the client to himself.
8. The router return's his certificate, because he's configured for remote management inside the network on the 443 (HTTPS) port.
9. Client's outlook sees that the certificate is wrong, therefore the client receives the certificate error, before it actually tries to connect.

The solution:

1. The simplest way, is to disable the secondary DNS, and leave it with just the SBS IP, then it will always try to find the ip from the SBS. It solved my problem. You can either edit the DHCP server setting, so clients will get only the SBS IP as a DNS server, or just edit manually on the client's machine the network adapter properties.
2. You can go further and investigate the cause of the client's fall back to the secondary DNS. There can be many reasons for the cause of it. You should look into logs, such as "System" logs and "DNS Server" logs on both, client and server. I did find a problem on the server side, and currently investigating it. As soon as I'll find a solution I'll post another article with the solution.

Also, stay tuned to my second post with a very similar problem (will put a link here).