Outlook certificate mismatch error

Hi R-R, thanks for your comment. Certificate is fine, I've checked all the URLs and none have double .com. We do have a forward lookup zone for domain.com with the correct A record for webmail pointing to the Exchange server. Any other ideas?

Check OA url.
Check activesync/ecp/owa urls

I've checked all URLs on the Exchange server. None have .com.com

Also, this isn't a new Exchange install. It's been running along nicely for 2 years until this error popped up! :)

Check if there is any certificate with SAN entries com.com is present.
Check if the proper certificate which do not have com.com is binded in IIS default web site.

com.com is actually a valid domain name.
Therefore this sounds like there is a DNS error somewhere.

If you have changed all entries in Exchange to use the external host name, then check that you have a proper zone on your internal DNS for that entry.
It could be that for some reason the clients are appending the domain suffix .com to the DNS lookup.

As it appears that everything is correct within Exchange, this looks like it is a DNS/domain configuration error.

Simon.

Hi Simon, that's correct. The certificate that pops up is a RapidSSL one which we don't have installed anywhere so it's related to the .com.com domain.

Exchange is configured to use the external host name and we do have a forward lookup zone with that entry in it (see screenshot)

Any other DNS checks you can recommend?

Does this happen for all clients? Have you checked the cert itself to see if it has been replcaed or modified some how?

Will.

Please run the below commands in Exchange powershell and paste all output here (Feel free to remove the domain name as you did, but please leave as much info as possible.)

get-OwaVirtualDirectory | fl *url*
get-EcpVirtualDirectory | fl *url*
get-ActiveSyncVirtualDirectory | fl *url*
get-OabVirtualDirectory | fl *url*
get-ClientAccessServer | fl *uri*
get-WebServicesVirtualDirectory | fl *url*
get-OABVirtualDirectory | fl *url*

Please also paste a screen shot of the alternative names for your cert.  See example attached.
SS.png

This does happen for all clients. We've checked the cert and it's ok. It's also the only one on the Exchaneg server so no phantom certs lurking about.

Welcome to the Exchange Management Shell!

Full list of cmdlets: Get-Command
Only Exchange cmdlets: Get-ExCommand
Cmdlets that match a specific string: Help *<string>*
Get general help: Help
Get help for a cmdlet: Help <cmdlet name> or <cmdlet name> -?
Show quick reference guide: QuickRef
Exchange team blog: Get-ExBlog
Show full output for a command: <command> | Format-List

Tip of the day #40:

Has one of your users asked you to recover their mobile device synchronization password? To return the user's password,
type:

 Get-ActiveSyncDeviceStatistics -ShowRecoveryPassword

VERBOSE: Connecting to TSXNG.domain.com
VERBOSE: Connected to TSXNG.domain.com.
[PS] C:\Windows\system32>get-OwaVirtualDirectory | fl *url*


Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://webmail.domain.com/owa
ExternalUrl     : https://webmail.domain.com/owa

Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://cas-dr.domain.com/owa
ExternalUrl     : https://webmaildr.domain.com/owa



[PS] C:\Windows\system32>get-EcpVirtualDirectory | fl *url*


InternalUrl : https://webmail.domain.com/ecp
ExternalUrl : https://webmail.domain.com/ecp

InternalUrl : https://cas-dr.domain.com/ecp
ExternalUrl : https://webmaildr.domain.com/ecp



[PS] C:\Windows\system32>get-ActiveSyncVirtualDirectory | fl *url*


MobileClientCertificateAuthorityURL :
InternalUrl                         : https://webmail.domain.com/Microsoft-Server-ActiveSync
ExternalUrl                         : https://webmail.domain.com/Microsoft-Server-ActiveSync

MobileClientCertificateAuthorityURL :
InternalUrl                         : https://cas-dr.domain.com/Microsoft-Server-ActiveSync
ExternalUrl                         : https://webmaildr.domain.com/Microsoft-Server-ActiveSync



[PS] C:\Windows\system32>get-OabVirtualDirectory | fl *url*


InternalUrl : https://webmail.domain.com/OAB
ExternalUrl : https://webmail.domain.com/OAB

InternalUrl : http://cas-dr.domain.com/OAB
ExternalUrl : https://webmaildr.domain.com/OAB



[PS] C:\Windows\system32>get-ClientAccessServer | fl *uri*


AutoDiscoverServiceInternalUri : https://webmail.domain.com.com/autodiscover/autodiscover.xml

AutoDiscoverServiceInternalUri : https://cas-dr.domain.com.com/autodiscover/autodiscover.xml



[PS] C:\Windows\system32>get-WebServicesVirtualDirectory | fl *url*


InternalNLBBypassUrl : https://tsxng.domain.com/ews/exchange.asmx
InternalUrl          : https://cas-hq.domain.com/EWS/Exchange.asmx
ExternalUrl          : https://webmail.domain.com/ews/exchange.asmx

InternalNLBBypassUrl : https://tsdrxng.domain.com/ews/exchange.asmx
InternalUrl          : https://cas-dr.domain.com/EWS/Exchange.asmx
ExternalUrl          : https://webmaildr.domain.com/ews/exchange.asmx



[PS] C:\Windows\system32>get-OABVirtualDirectory | fl *url*


InternalUrl : https://webmail.domain.com/OAB
ExternalUrl : https://webmail.domain.com/OAB

InternalUrl : http://cas-dr.domain.com/OAB
ExternalUrl : https://webmaildr.domain.com/OAB



[PS] C:\Windows\system32>

I don't think it is your Exchange configuration - as the first screenshot posted with the results of Autodiscover are showing the correct information.
This is DNS resolution.

If you do an nslookup, does that return the correct results?
Same for a ping?

My instinct is that someone has changed something outside of Exchange, possibly to force .com to be put on to the end of any domains, something like that.

Simon.

Hey Dipersp you are correct.. That the one i asked to check in my earlier comments.

Yeh, the URL and URI can be confusing, which is why I explicitly spell it out (hoping they'll cut and paste) so we actually can see the uri as opposed to url values on that one.  URI just looks like someone didn't capitalize the L!

Thanks guys, I think my brain didn't process the double .com in the output as I didn't spot it at all. Without the *uri* it's quite a hefty output.

This was such an unusual one as this value must have been set a while back when Exchange was installed and it's been working fine. I think that last month the *.com.com domain must have been registered with a certificate so since then the Exchange server has been able to resolve it and has been giving the error.

Thanks again for the perseverance. I'll split the points 50/50. R-R did point me in the right direction first (but I was blind!) but dipersp went the extra mile by requesting the output and spotting the problem. Hope that's ok?

That's fine with me. In-fact i am glad that the issue is resolved.

Not sure i am clear on what the issue was?

the *.com.com domain must have been registered with a certificate so since then the Exchange server has been able to resolve it and has been giving the error.

My comment...
2015-06-26 at 09:50:39ID: 40853024
Does this happen for all clients? Have you checked the cert itself to see if it has been replcaed or modified some how?

 Will.

Was it not the cert that was the issue. Based on all of your testing the virtual directories were all correct.

Will.

Sounds like a plan.  Glad that did it for you.

Hi Will,

It turns out there was a typo on a couple of the virtual directory entries. The certificate was ok.