Thursday, October 9, 2014

Windows XP clients must match the Certificate Common Name in Outlook for RPC over HTTP

Back in 2009 I wrote an article called "Configuring Outlook Anywhere Settings via Autodiscover" which can be found at the following URL:

Also in 2009 I wrote an article called "Outlook Anywhere keeps prompting for Password" which can be found at the following URL:

In this blog post I am going to touch on these two topics a bit further as this issue will impact many organisations moving to Exchange 2013 for those still running Windows XP (despite the fact it is no longer supported) seeming Exchange 2013 only supports RPC over HTTP or MAPI over HTTP (out of scope for this article).  To recap what I wrote about in the previous articles 5 years ago, for RPC over HTTP(s) aka Outlook Anywhere to work on any version of the Outlook Client on the XP, the MSSTD value must match the "Common Name" on the certificate.  What am I talking about?  Well let me show you...

The MSSTD is specified under "Only connect to proxy servers that have this principal name in their certificate" which can be found within Outlook under Account Settings, Open the Account, More Settings, Connection Tab and finally Exchange Proxy Settings.

This value must match the "Common Name" of the certificate which in this example is as shown below next to "Issued to:"
From Windows Vista onwards the MSSTD can match any name in the Certificate which includes the Certificate Common Name as shown above and any Subject Alternative Names (SAN) which may exist on the certificate.  These are often used and can be easily located on the details tab of a certificate in Microsoft Windows as shown below:
For Windows XP the "Only connect to proxy servers that have this principal name in their certificate" value MUST MATCH the common name on the Certificate.  The symptom for having this not matching is the user continuously being prompted for credentials in an infinite loop as I addressed under the article Outlook Anywhere keeps prompting for Password.
 Note: This also applies to Windows Server 2003 for people with legacy Terminal Server / Citrix environments.
What about for Wild Card certificates, how do I set the "Only connect to proxy servers that have this principal name in their certificate" MSSTD value for these for legacy Windows XP clients?
For Wild Card certificates the MSSTD value must be set to:
You must actually put the astricts in the DNS name instead of the name the client is connecting to in order for Windows XP to be happy so it matches the exact name of the Wildcard certificate.
What about Autodiscover?
Now that we understand that the MSSTD must match the common name of the certificate for our legacy Windows XP clients, how do we automatically push this out to our clients via Autodiscover?
Exchange 2013 no longer directly uses EXPR/EXCH Outlook Providers which we configured in Exchange 2007/2010, it has two different dynamically generated EXHTTP providers. Users with mailboxes on 2013 will get one set of EXHTTP settings for internal usage and one set of EXHTTP settings for external usage.  You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP.
However ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings.  The concept of internal Outlook Anywhere and External Outlook Anywhere is new in Exchange 2013 as we
got rid of direct RPC to the Exchange server.  We want the ability to set NTLM authentication for internal and Basic authentication for External as well as different connection URLs.
To change the internal MSSTD returned value from Autodiscover use the following command:
Internal Outlook Anywhere:
Get-OutlookProvider "EXCH" | Set-OutlookProvider -CertPrincipalName ""
External Outlook Anywhere:
Get-OutlookProvider "EXPR" | Set-OutlookProvider -CertPrincipalName ""
If you have a private internal namespace such as .local, .lan or .internal you may also need to setup split horizon DNS so that you can make the Certificate Common Name match the MSSTD!
Hope this article has been helpful.


  1. Thanks Clint, this was a life saver.

    A Client got a new cert where the Common Name was replaced to a new one, and the previous Common Name become one of the SANs. And indeed the Outlook 2010 clients on XP(!) started to prompt for passwords, while the rest of the clients (Win7 / Win8) worked happily afterwards.

    Setting the CertPrincipalName with the PS command that you suggested made the XP clients work, too.


    1. windows key for windows 7 ultimate for windows for ultimate key , serial key of microsoft office project standard 2007 , windows 7 professional key cheap , microsoft office professional plus 2010 genuine product key 2012 , windows 10 product key , product key for microsoft office project standard 2007 , windows 2003 standard sp2 product key , office 2016 product key , lLqmBf

  2. Hi Clint. nice article. i have a client that has Exchange 2013, and Windows 8, 10 and XP. Recently they have an issue that the Certificate got expired, we created a new certificate, since they use an internal ssl certificate (not externall ssl, or from AD, just pure SSL created by mmc console), after that change the clients using Windows XP could not connect to Exchange, OWA and other clients works ok, i have tried those commands and after reboot, IIS reset and 3 hours the XP client did not were able to connect Outlook 20007, and keep asking credentials. They use authonegotiation. What else can be or check?