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

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.

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.

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.

It's a public certificate that was purchased. Why should clients have to have that certificate installed??

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

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

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.

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

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.

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.

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

More Readings:- http://blogs.technet.com/b/exchange/archive/2008/09/29/3406352.aspx

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.

So set it to:

Set-OutlookProvider -Identity EXPR -CertPrincipalName $Null


Would that be the correct syntax?

yes looks good to me.