Solved

External (Outlook Anywhere) clients are getting certificate error with a public certificate

Posted on 2015-01-26
16
505 Views
Last Modified: 2015-02-01
Hi guys,

This weekend, I changed out a certificate in Exchange. I got a public cert and used all the proper subject alternative names. However, the former cert, installed before my time, was a wildcard and I am not a proponent of a wildcard cert in Exchange. I got a standard UCC cert and gave the common name 'mail.mydomain.com'. Everything went well and the change was transparent for the most part. However, the Outlook Anywhere clients in my China office are experiencing the following error when trying to open Outlook (keep in mind that if they VPN in and open Outlook or simply go to webmail.mydomain.com or mail.mydomain.com/owa externally they have no issues):

"There is a problem with the proxy server's security certificate. The name on the security certificate is invalid or does not match the name of the site. Outlook is unable to connect to this proxy server."

To me, this means there may be a manual certificate installed on these external boxes for some reason? The configuration of their Outlook anywhere setting is 'webmail.mydomain.com' as the server to connect to. However, the public certificate works (i.e. there are no certificate errors either internally or externally when attempting to connect via webmail.mydomain.com) with no issues.

As usual, any help is greatly appreciated. Thanks!

-Roy
0
Comment
Question by:roycbene
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 9
  • 7
16 Comments
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570542
Is that the only office affected with this problem?
Here is a published KB but I am sure you have validated all the steps mentioned - http://support.microsoft.com/kb/923575
From one of the affected client have you performed connection test - https://testconnectivity.microsoft.com/

Is there any restriction on the client side compared to other unaffected office (proxy or something?)
I would also recommend to run web debugger (fiddler) and repro the issue and see what's going on.
0
 
LVL 3

Author Comment

by:roycbene
ID: 40570593
Thanks for the reply. It does not seem to be the only office affected, no. Again, if they VPN in or go to webmail.mydomain.com or mail.mydomain.com/owa they get in with no problems. There is nothing wrong with the certificate.

there is nothing wrong with the connection, as they are able to connect when not using Outlook anywhere with no issues. Also, no restrictions on the client side that I know of. I have to look at that to be sure, and I will definitely look at that.
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570670
Also make sure the clients have the root certificate of the CA authority you are using and that it trusts the entire chain if applicable.  The web debugger should show you exactly where the client is trying to connect.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 3

Author Comment

by:roycbene
ID: 40570673
It's a public certificate that was purchased. Why should clients have to have that certificate installed??
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570684
Just the root cert has to be trusted by the clients.

This might help you understand the trust model
https://technet.microsoft.com/en-us/library/cc962065.aspx
https://technet.microsoft.com/en-us/library/cc778623(v=WS.10).aspx
0
 
LVL 3

Author Comment

by:roycbene
ID: 40570734
My confusion is not with the trust model.

My confusion lies with what you're saying regarding public Exchange certificates having to be trusted. I have an intermediate certificate and a primary certificate. The intermediate certificate is installed in the Exchange server's intermediate certification authorities store. The primary certificate is then installed (through EMC) and enabled (with services IIS and SMTP) in Exchange. That's where the trusting should end. If you go to https://mail.mydomain.com/owa, there is no certificate error. Whereas, if the certificate were not trusted or there was an issue with the certificate, you'd get the infamous (proceed to website) certificate block page. This is not the case here. It goes straight to the OWA login console - same with webmail.mydomain.com So, if Outlook Anywhere is configured with webmail.mydomain.com, then there should be no issues trusting it on that client if that client can hit it with no issues in their web browser, correct?

My suspicion is that there was a certificate installed manually on these machines, or maybe, as you said earlier, there is something in the proxy settings of their Outlook setup that is keeping the connection from happening seamlessly. I'm not sure yet and I need to check that. If I could be missing anything else, please let me know.

Thanks.

-R
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570763
You are on right track, if you can manually connect to the url without any problem then the cert validation should not be the problem.
0
 
LVL 3

Author Comment

by:roycbene
ID: 40570805
I think I found the issue. There is a setting in the Exchange proxy settings that allows you to specify a certificate name. This was checked (it looks like it was pushed from Exchange???) and had the wrong certificate. If this was, indeed, configured in Exchange, I've not ever configured it. Perhaps you can shed some light on where that comes from??

Thanks!

-R
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570831
Are you talking about the one under 'More Settings' under Outlook Account settings?
Those values are normally manually specified so i would guess someone would have instructed the users or pushed the configuration with a different name and since you use to use wild card cert before it was never a problem but now that the cert is specifically published with particular the name match becomes important factor for successful connection.
0
 
LVL 3

Author Comment

by:roycbene
ID: 40570846
Actually, it says:

Connect using SSL only
Only connect to proxy servers that have this principal name in their certificate:
msstd: *.mydomain.com

This, in my experience, comes from a group policy setting and is pushed out at the Exchange level. However, I am unable to locate this GPO. Making progress, but still stuck.
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570912
You can run Get-OutlookProvider and see the certprincipalname  is going to be the wildcard name since you aren't using the wild card cert you will have to change it to the actual name you are using for outlook anywhere connection.

This is what you need to set for your Outlook Provider:-
Set-OutlookProvider EXPR -CertPrincipalName msstd:webmail.mydomain.com
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40570924
0
 
LVL 3

Author Comment

by:roycbene
ID: 40571439
This doesn't really help me. Shouldn't the CertPrincipalName be the common name of the certificate? For example, the url that is configured in my Outlook Anywhere is webmail.mydomain.com. This is a Subject Alternative Name in the cert, yes; but the certificate name is mail.mydomain.com. Regardless, neither one worked. I guess I don't understand why this flag is even set. The default option is null. Is there a problem with leaving it set to Null? Webmail.mydomain.com as the CertPrincipalName is not working. I've also checked auto configuration settings after restarting the Worldwide Publishing Service to ensure the new msstd setting propagated.

Still stuck I'm afraid.
0
 
LVL 7

Accepted Solution

by:
Satyendra Sharma earned 500 total points
ID: 40571476
Ok so in your case since you are not using wild card you would have to set the certprincipalname to $null that way whatever url you have specified in the Outlook Anywhere configuration will be used i.e. webmail.mydomain.com

Here is more info - http://blogs.technet.com/b/umutg/archive/2011/01/31/all-about-set-outlookprovider.aspx
0
 
LVL 3

Author Comment

by:roycbene
ID: 40571506
So set it to:

Set-OutlookProvider -Identity EXPR -CertPrincipalName $Null


Would that be the correct syntax?
0
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40572784
yes looks good to me.
0

Featured Post

Free eBook: Backup on AWS

Everything you need to know about backup and disaster recovery with AWS, for FREE!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A list of top three free exchange EDB viewers that helps the user to extract a mailbox from an unmounted .edb file and get a clear preview of all emails & other items with just a single click on mailboxes.
Changing a few Outlook Options can help keep you organized!
This Experts Exchange video Micro Tutorial shows how to tell Microsoft Office that a word is NOT spelled correctly. Microsoft Office has a built-in, main dictionary that is shared by Office apps, including Excel, Outlook, PowerPoint, and Word. When …
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…

717 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question