We help IT Professionals succeed at work.

Outlook 2016/365 & wrong certificates

it_medcomp
it_medcomp used Ask the Experts™
on
I have Outlook 2016/365, and we just started having this problem- Our DNS was compromised and I had to rebuild the zones from scratch. I get email, and everything seems to work... except something is still looking in the wrong place, and I don't know what. We get a nuisance pop-up when starting Outlook about a cPanel certificate - the CA is valid, the certificate is expired, and the certificate contains a valid name. This certificate is not on our Exchange servers- I have verified that the only certificates not self-signed (We are using on-prem Exchange 2013) on our Exchange servers are GoDaddy certificates. Our mail and MX records point to our public IP, and I have been using mxToolbox to verify those plus other DNS records. The autodiscover record has been a CNAME pointed to our domain's mail record, and I recently changed it to an A record pointing at this IP address. No change. I also have the SRV pointed to the mail record on the domain using port 443. The certificate message appears right when I start Outlook- Any idea which record is wrong? Any idea how to troubleshoot?
Thanks!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
What certificate comes up in a browser when you access your public IP address externally, either through name or IP etc.  Could be nothing to do with anything else and perhasthat has just expired - the certificate could be on your firewall which is reverse proxying the incoming HTTPS?

Author

Commented:
The problem is that when Outlook tries to Autodiscover, it is presented with the wrong certificate, which means it is pointing to the wrong IP address. Here is where I think the problem is- these are the related DNS records on our public DNS
domain.com 3600 A <ISP Website IP>
*.domain.com 3600 A <ISP Website IP>
mail.domain.com 3600 A <Mailserver IP>
domain.com 3600 MX <mail.domain.com>
autodiscover.domain.com 3600 CNAME mail.domain.com
domain.com 3600 TXT "v=spf1 +a +mx +ip4:<ISP Website IP> +ip4:<Mailserver IP> ~all"
_autodiscover._tcp.domain.com 3600 SRV 0 0 443 <Mailserver IP>

Is the wildcard record causing the problem? Is my SPF record named properly? Those are the first things that I am not sure of.... this is happening on about 12 domains that have these records set this way.

Commented:
What happens from browser though inside and out doing https://mail.domain.com 

You can send me private message with domain name of you want me to see what it says from here and not show it publically

Author

Commented:
It works... What are you looking for- I'm not sure what to send. The SSL icon shows correctly for both internal and external access to OWA/ECP. It looks like the message is coming from the domain.com... PM'ing a screenshot....

Commented:
That is probably OK then.  I was wondering what certificate was being sent back to the browser when you say there is no public certificate on the Exchange box -- have you tried https://testconnectivity.microsoft.com/  doing the autodiscover test?

Author

Commented:
I must have typo’ed. Exchange has a different public certificate on it- these errors are simply from the wrong cert.

Commented:
That certificate expired on 19th November for https:// to your main domain name but as you say the OWA certificate seems right.

Also have a look with outlook open, hold down control key and right click on the Outlook icon in the notification area, you should see option to "test email autoconfiguration".  That normally gives some good info on what is killing it.

Steve

Author

Commented:
the testconnectivity.Microsoft.com site just told me what we already know- sometimes it grabs the wrong certificate, which is expired, and since it is not valid, a valid certificate chain cannot be constructed. The Outlook autodiscover test shows it looking at https://domain.com/autodiscover/autodiscover.xml. I think what happens is that Outlook is tripping certificate errors when it hits the domain root- Check out the Autodiscover test I PM'med to you....
Thanks!

Commented:
Ok, I suspect you possibly had domain.com pointing at your mail server before then rather than your website?

Will have a better look later, on a customer site today.

Steve
Commented:
Difficult to work out what is going on exactly from just what i can see but your https://domain.com/autodiscover/autodiscover.xml is wanting authentication and certificate error then redirecting to mail.domain.com rather than failing.

It looks to me like that IS available, possibly through a redirect on your website address so accessing /autodiscover redirects to mail.domain.com but as your certificate has expired it still works but complains about the certificate.

So I think the key here is getting that certificate on domain.com not to be expired or remove the https access to the website and then it will skip to the next option.

Author

Commented:
that’s an angle I had not considered- the redirect never worked and we just didn’t know it because the certificate was not expired- I’m going to take a look but I think I have a couple of ideas!

Author

Commented:
Thanks for the suggestions! It turned out that the root website had an expired certificate, which was true for each affected domain. When the root domain cert was renewed, the problem disappeared from Outlook. Thanks so much for the help!

Commented:
No problem, glad it worked, and thanks for the comments.  Autodiscover seems like a black art sometimes but follows a clear path of options so those troubleshooting tools generally find the right answer when something has gone wrong.

Steve