• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 653
  • Last Modified:

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

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
roycbene
Asked:
roycbene
  • 9
  • 7
1 Solution
 
Satyendra SharmaCommented:
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
 
roycbeneAuthor Commented:
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
 
Satyendra SharmaCommented:
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
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
roycbeneAuthor Commented:
It's a public certificate that was purchased. Why should clients have to have that certificate installed??
0
 
Satyendra SharmaCommented:
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
 
roycbeneAuthor Commented:
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
 
Satyendra SharmaCommented:
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
 
roycbeneAuthor Commented:
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
 
Satyendra SharmaCommented:
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
 
roycbeneAuthor Commented:
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
 
Satyendra SharmaCommented:
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
 
Satyendra SharmaCommented:
0
 
roycbeneAuthor Commented:
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
 
Satyendra SharmaCommented:
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
 
roycbeneAuthor Commented:
So set it to:

Set-OutlookProvider -Identity EXPR -CertPrincipalName $Null


Would that be the correct syntax?
0
 
Satyendra SharmaCommented:
yes looks good to me.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 9
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now