Resolving Outlook Certificate Mismatch Error in Exchange 2007 with Multiple SMTP Domains


3 views

When configuring Outlook for remote access to secondary email domains (companyB.com and companyC.com) in an Exchange 2007 environment, the certificate error occurs because Outlook validates the server name against the certificate's Subject Alternative Names (SANs). The current certificate only includes companyA.com variations, causing validation failures for other domains.

For a proper solution, your SSL certificate should include all SMTP domains used in your organization. The minimum SAN requirements would be:

- webmail.companyA.com
- webmail.companyB.com
- webmail.companyC.com
- autodiscover.companyA.com
- autodiscover.companyB.com
- autodiscover.companyC.com
- CORP-SBS (NetBIOS name)
- CORP-SBS.local (internal FQDN)

The CEO mentioned an SRV record previously fixing the issue. Here's how to properly configure SRV records for each domain in DNS (PowerShell example for Windows DNS):

Add-DnsServerResourceRecord -Srv -DomainName "companyB.com" -Name "_autodiscover._tcp" -Priority 0 -Weight 0 -Port 443 -Target "webmail.companyA.com"
Add-DnsServerResourceRecord -Srv -DomainName "companyC.com" -Name "_autodiscover._tcp" -Priority 0 -Weight 0 -Port 443 -Target "webmail.companyA.com"

Modify your Exchange configuration to properly handle multiple domains:

# PowerShell to configure Accepted Domains
Get-AcceptedDomain | Set-AcceptedDomain -DomainType Authoritative

# Add email address policies for secondary domains
New-EmailAddressPolicy -Name "CompanyB Policy" -IncludedRecipients AllRecipients -EnabledPrimarySMTPAddressTemplate "SMTP:@companyB.com"
New-EmailAddressPolicy -Name "CompanyC Policy" -IncludedRecipients AllRecipients -EnabledPrimarySMTPAddressTemplate "SMTP:@companyC.com"

For immediate relief while implementing the proper fix, you can modify the Outlook profile XML:

<ExchangeConnection>
  <OverrideCertCN>webmail.companyA.com</OverrideCertCN>
  <SSL>On</SSL>
  <AuthRequired>On</AuthRequired>
</ExchangeConnection>

After implementation, verify connectivity using these PowerShell commands:

Test-OutlookConnectivity -ProbeIdentity OutlookMapiHttp.Protocol\OutlookMapiHttpSelfTestProbe
Test-ExchangeConnectivity -ClientAccessServer CORP-SBS -MonitoringContext $true

When renewing certificates, ensure you:

  • Include all public and private names
  • Use wildcards when appropriate (*.companyA.com)
  • Maintain a consistent certificate update schedule
  • Document all SAN entries for future reference

When dealing with multi-tenant Exchange 2007 setups on SBS 2008, certificate warnings can become particularly tricky. Here's what's happening in this environment:

  • Primary domain: companyA.com (authentication domain)
  • Secondary domains: companyB.com and companyC.com (email-only)
  • Certificate SAN includes only companyA.com variants

The core issue stems from Outlook's validation behavior when connecting to Exchange:

// Pseudo-code of Outlook's certificate validation
if (requestedServerName != certificateSubject) {
    if (certificateSAN.Contains(requestedServerName)) {
        proceedNormally();
    } else {
        showSecurityWarning();
    }
}

In this case, Outlook tries to connect using companyB.com or companyC.com domains, but these aren't present in the SAN list.

The CEO's DNS provider change likely affected critical records:

;; Correct SRV record example for Autodiscover
_autodiscover._tcp.companyA.com. 3600 IN SRV 10 10 443 CORP-SBS.companyA.com.

Without proper SRV records, Outlook falls back to guessing endpoints, potentially using the wrong domain names.

Here are the technical steps to resolve this:

Option 1: Certificate SAN Extension

Update your certificate to include all email domains:

New-ExchangeCertificate -GenerateRequest -SubjectName "CN=CORP-SBS" 
-DomainName webmail.companyA.com,autodiscover.companyA.com,companyB.com,companyC.com 
-PrivateKeyExportable $true -Path C:\certreq.txt

Option 2: DNS Redirection

Configure CNAME records for all domains to point to your primary:

;; DNS Zone File Example
autodiscover.companyB.com. IN CNAME autodiscover.companyA.com.
webmail.companyB.com.      IN CNAME webmail.companyA.com.

Option 3: Registry Workaround (Temporary)

For testing purposes, you can disable certificate name checking:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Security]
"SupressNameChecks"=dword:00000001

Warning: This should only be used temporarily as it reduces security.

For a production environment, consider these architectural improvements:

  • Upgrade to a newer Exchange version that better supports multiple domains
  • Implement split-brain DNS if internal/external resolution differs
  • Use PowerShell to validate your configuration:
Test-OutlookWebServices -Identity user@companyB.com | fl
Test-AutoDiscoverConnectivity -MailboxCredential (Get-Credential) -TargetAddress user@companyC.com

After implementing changes, verify with:

# Check certificate bindings in IIS
Get-ChildItem IIS:\SslBindings

# Test remote connectivity
Test-OutlookConnectivity -ProbeIdentity OutlookMapiHttp.Protocol.Doc