When migrating to a new Exchange 2010 environment, I decided to use a wildcard certificate instead of a UC certificate. It cost about twice as much, but seeing as how I have several other services that currently require SSL certificates, it seemed like a good investment.
When running through the Exchange Remote Connectivity Analyzer, I noticed that my configuration kept failing the Outlook Anywhere test with the following error:
Testing SSL mutual authentication with the RPC proxy server.
Verification of mutual authentication failed.
> Additional Details
>> The certificate common name *.domain.com doesn't validate against the mutual authentication that was provided: msstd:mail.domain.com
The solution was relatively easy. Log into your Exchange CAS server and run the following cmdlet from the Exchange Command Shell:
Set-OutlookProvider -Identity EXPR -CertPrincipalName *.domain.com
I've seen some documentation that replaced the CertPrincipalName value with msstd:*.domain.com, but I believe that is incorrect. The name on the actual SSL certificate is *.domain.com, not msstd:*.domain.com. For giggles, I did try using msstd:*.domain.com as the CertPrincipalName value, but it did not allow me to pass ExRCA.
Run the Get-OutlookProvider cmdlet to review your settings:
RunspaceId : 841d7d59-e89c-42b4-9c3c-9388d40dcd95
CertPrincipalName : *.domain.com
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXPR
DistinguishedName : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=A
pex Digital Solutions,CN=Microsoft Exchange,CN=Services,
CN=Configuration,DC=domain,DC=com
Identity : EXPR
Guid : d81b1280-1843-4808-812c-48375ed744e0
ObjectCategory : domain.com/Configuration/Schema/ms-Exch-Auto-Discove
r-Config
ObjectClass : {top, msExchAutoDiscoverConfig}
WhenChanged : 11/5/2010 11:53:39 AM
WhenCreated : 1/30/2009 9:23:30 PM
WhenChangedUTC : 11/5/2010 3:53:39 PM
WhenCreatedUTC : 1/31/2009 2:23:30 AM
OrganizationId :
OriginatingServer : mydc03.domain.com
IsValid : True
Running a company inside Europe, I'd rather pick a GDPR compliant vendor from Europe ... much less trouble with data prodection authorities if anything goes wrong.
ReplyDelete