Medhacloud Logo
CERTIFICATE_NAME_MISMATCH

Event ID 1035: Certificate Name Mismatch

Complete troubleshooting guide for Exchange Server Event ID 1035 certificate name mismatch errors causing Outlook connectivity issues, SSL warnings, and Autodiscover failures.

Medha Cloud
Medha Cloud Exchange Server Team
Exchange Database Recovery Team••8 min read

Table of Contents

Reading Progress
0 of 10

Error Overview

Event ID 1035: Certificate Name Mismatch

"The certificate does not match the name of the site to which you are connecting. The name on the security certificate is invalid or does not match the name of the target site."

What This Error Means

Certificate name mismatch errors occur when Exchange clients attempt to connect using a hostname that doesn't match any name listed in the server's SSL certificate. This security mechanism prevents man-in-the-middle attacks but causes connectivity issues when certificates are misconfigured.

Affected Services

  • • Outlook connectivity
  • • Autodiscover
  • • OWA/ECP access
  • • ActiveSync
  • • EWS applications

Impact Level

  • • Security warnings displayed
  • • Connection failures
  • • Autodiscover broken
  • • User productivity impacted
  • • Trust concerns raised
⚠️

Version Notice

This guide applies to Exchange Server 2016, 2019, and Exchange Online hybrid configurations. Certificate requirements vary slightly between versions, with Exchange 2019 requiring TLS 1.2 compatible certificates.

Symptoms & Detection

User-Reported Symptoms

  • ✗"The security certificate was issued by a company you have not chosen to trust"
  • ✗"The name on the security certificate is invalid"
  • ✗Certificate warning popups on Outlook launch
  • ✗Browser warnings accessing OWA
  • ✗Mobile devices failing to sync

Administrator Detection

  • →Event ID 1035 in Application log
  • →Autodiscover test failures
  • →Certificate validation errors in IIS
  • →SSL handshake failures in network traces
  • →HTTPS connectivity test warnings

Event Log Entry Example

Log Name:      Application
Source:        MSExchange Autodiscover
Event ID:      1035
Level:         Error
Description:   The certificate associated with the site does not have a
               subject name or subject alternative name that matches the
               requested URL https://mail.contoso.com/autodiscover/autodiscover.xml.

               Expected name: mail.contoso.com
               Certificate CN: EXCH01.corp.local
               Certificate SANs: EXCH01.corp.local, EXCH01

Common Causes

1

Self-Signed Certificate in Production

Exchange setup creates a self-signed certificate with just the server name, not external hostnames. Using this certificate for client access causes immediate mismatch errors.

Solution: Replace with a certificate from a trusted CA that includes all required names.
2

Missing Subject Alternative Names

Certificate was issued with some hostnames but missing others needed for Exchange services. Common omissions include autodiscover.domain.com or internal server FQDNs.

Required SANs: External hostname, Autodiscover hostname, internal FQDN, legacy namespace.
3

Virtual Directory URL Mismatch

Exchange virtual directories configured with URLs that don't match certificate names. InternalURL and ExternalURL settings must align with certificate SANs.

Common Issue: ExternalURL uses mail.domain.com but certificate only has server FQDN.
4

Certificate Not Assigned to Services

New certificate imported but not enabled for Exchange services (IIS, SMTP, POP, IMAP). The old certificate with wrong names may still be in use.

Verification: Use Enable-ExchangeCertificate to assign services after import.
5

Split-Brain DNS Not Configured

Internal clients resolve different IP/hostname than external clients. If internal DNS returns the server FQDN instead of the external hostname, certificate mismatch occurs.

Best Practice: Configure split-brain DNS so internal clients use same hostname as external.

Diagnostic Steps

Step 1: Check Current Certificate Configuration

# View all Exchange certificates
Get-ExchangeCertificate | Format-List Subject, CertificateDomains, Services, Thumbprint, NotAfter

# Check certificate assigned to IIS
Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"} |
    Format-List Subject, CertificateDomains, Thumbprint

# View certificate details by thumbprint
$thumb = "ABC123..."  # Replace with actual thumbprint
Get-ExchangeCertificate -Thumbprint $thumb | Format-List *

Step 2: Identify All Required Hostnames

# Get all virtual directory URLs
$VDirs = @("AutodiscoverVirtualDirectory", "OWAVirtualDirectory", "ECPVirtualDirectory",
           "WebServicesVirtualDirectory", "OABVirtualDirectory", "ActiveSyncVirtualDirectory",
           "MAPIVirtualDirectory", "PowerShellVirtualDirectory")

foreach ($VDir in $VDirs) {
    $cmd = "Get-$VDir | Select-Object Identity, InternalUrl, ExternalUrl"-Object Identity, InternalUrl, ExternalUrl"
    Write-Host "=== $VDir ===" -ForegroundColor Yellow
    Invoke-Expression $cmd | Format-Table -AutoSize
}

# Get Outlook Anywhere configuration
Get-OutlookAnywhere | Select-Object Identity, InternalHostname, ExternalHostname

# Get client access service URIs
Get-ClientAccessService | Select-Object Identity, AutoDiscoverServiceInternalUri

Step 3: Test Certificate Validation

# Test-OutlookConnectivity includes certificate checks
Test-OutlookConnectivity -ProbeIdentity "OutlookRpcCtpProbe" |
    Format-List Result, Error, LatencyInMilliseconds

# Test Autodiscover certificate
$cred = Get-Credential
Test-OutlookWebServices -Identity "user@contoso.com" -TargetAddress "user@contoso.com" -MailboxCredential $cred

# Check certificate from command line
# Run this from a client machine:
# certutil -verify -urlfetch https://mail.contoso.com-urlfetch https://mail.contoso.com

# PowerShell certificate check
$url = "https://mail.contoso.com"
$request = [System.Net.HttpWebRequest]::Create($url)
$request.AllowAutoRedirect = $false
$request.ServerCertificateValidationCallback = { $true }
try {
    $response = $request.GetResponse()
    $cert = $request.ServicePoint.Certificate
    Write-Host "Subject: $($cert.Subject)"
    Write-Host "Issuer: $($cert.Issuer)"
    Write-Host "Valid: $($cert.GetEffectiveDateString()) to $($cert.GetExpirationDateString())"$cert.GetExpirationDateString())"
} catch {
    Write-Host "Error: $_"
}

Step 4: Check DNS Resolution

# Check what names resolve to (run on client)
$hostnames = @("mail.contoso.com", "autodiscover.contoso.com", "owa.contoso.com")

foreach ($hostname in $hostnames) {
    Write-Host "=== $hostname ===" -ForegroundColor Cyan
    try {
        $result = Resolve-DnsName $hostname -ErrorAction Stop
        $result | Format-Table Name, Type, IPAddress, NameHost
    } catch {
        Write-Host "Failed to resolve: $_" -ForegroundColor Red
    }
}

# Check SRV records for Autodiscover
Resolve-DnsName -Name "_autodiscover._tcp.contoso.com" -Type SRV

# Verify internal vs external resolution
nslookup mail.contoso.com    # Should return Load Balancer VIP or Exchange IP
nslookup mail.contoso.com 8.8.8.8   # External DNS check
💡

Pro Tip

Use online SSL checker tools like SSL Labs (ssllabs.com/ssltest) to get a comprehensive view of your certificate configuration including all SANs, chain validity, and protocol support.

Quick Fix

Fastest Resolution Path

If you have a valid certificate that just isn't properly assigned, or need to quickly identify the issue, follow these steps:

# Step 1: List all certificates and their service assignments
Get-ExchangeCertificate | Format-Table Subject, CertificateDomains, Services, Status -AutoSize

# Step 2: Find certificate with correct SANs (if it exists)
Get-ExchangeCertificate | Where-Object {$_.CertificateDomains -contains "mail.contoso.com"} |
    Format-List Thumbprint, Subject, CertificateDomains, Services

# Step 3: Enable the correct certificate for services
$thumbprint = "PASTE_THUMBPRINT_HERE"
Enable-ExchangeCertificate -Thumbprint $thumbprint -Services IIS,SMTP -Force

# Step 4: Restart IIS to apply changes
iisreset /noforce

# Step 5: Verify certificate is now in use
Get-ExchangeCertificate -Thumbprint $thumbprint | Format-List Services

Note: If no certificate with correct SANs exists, you'll need to request a new certificate. See Detailed Solutions below for certificate request procedures.

Detailed Solutions

Solution 1: Generate New Certificate Request

Create a new certificate signing request (CSR) with all required Subject Alternative Names:

# Create certificate request with all required SANs
$ReqFile = "C:\Certs\ExchangeCertRequest.req"

# Define all required domain names
$DomainNames = @(
    "mail.contoso.com",              # Primary external hostname
    "autodiscover.contoso.com",       # Autodiscover (required)
    "owa.contoso.com",               # OWA if different
    "EXCH01.corp.local",             # Internal server FQDN
    "EXCH02.corp.local"              # Additional servers if DAG
)

# Generate certificate request
New-ExchangeCertificate -GenerateRequest \
    -SubjectName "CN=mail.contoso.com, O=Contoso Ltd, L=Seattle, S=Washington, C=US" \
    -DomainName $DomainNames \
    -PrivateKeyExportable $true \
    -KeySize 2048 \
    -RequestFile $ReqFile

Write-Host "Certificate request saved to: $ReqFile" -ForegroundColor Green
Write-Host "Submit this file to your Certificate Authority" -ForegroundColor Yellow

Important: Submit the .req file to your Certificate Authority (CA). For public CAs like DigiCert, GoDaddy, or Let's Encrypt, follow their specific submission process.

Solution 2: Import and Enable New Certificate

Once you receive the certificate from your CA, import and enable it:

# Import the completed certificate
$CertFile = "C:\Certs\mail_contoso_com.cer"

# Find the pending request and complete it
$PendingCert = Get-ExchangeCertificate | Where-Object {$_.Status -eq "PendingRequest"}
Import-ExchangeCertificate -FileName $CertFile -PrivateKeyExportable $true

# Or if importing a PFX file with private key
$PfxFile = "C:\Certs\mail_contoso_com.pfx"
$PfxPassword = Read-Host "Enter PFX password" -AsSecureString
Import-ExchangeCertificate -FileName $PfxFile -Password $PfxPassword -PrivateKeyExportable $true

# Get the thumbprint of the new certificate
$NewCert = Get-ExchangeCertificate | Where-Object {$_.Subject -match "mail.contoso.com"} |
    Sort-Object NotAfter -Descending | Select-Object -First 1

Write-Host "New certificate thumbprint: $($NewCert.Thumbprint)"

# Enable certificate for Exchange services
Enable-ExchangeCertificate -Thumbprint $NewCert.Thumbprint -Services IIS,SMTP,POP,IMAP -Force

# Verify assignment
Get-ExchangeCertificate -Thumbprint $NewCert.Thumbprint | Format-List Services, Status

Solution 3: Configure Split-Brain DNS

Ensure internal clients use the same hostname as external clients to avoid certificate mismatch:

# On your internal DNS server, create a zone for your external domain
# This allows internal clients to resolve mail.contoso.com to the internal IP

# PowerShell DNS commands (run on DNS server):
Add-DnsServerPrimaryZone -Name "contoso.com" -ZoneFile "contoso.com.dns" -DynamicUpdate None

# Add A record for mail.contoso.com pointing to Exchange server(s)
Add-DnsServerResourceRecordA -ZoneName "contoso.com" -Name "mail" -IPv4Address "192.168.1.10"168.1.10"

# Add A record for autodiscover
Add-DnsServerResourceRecordA -ZoneName "contoso.com" -Name "autodiscover" -IPv4Address "192.168.1.10"168.1.10"

# Verify resolution from internal client
nslookup mail.contoso.com
# Should return: 192.168.1.10 (internal Exchange IP)168.1.10 (internal Exchange IP)

# Alternative: Use Group Policy to configure DNS suffix search
# This is useful if you want clients to resolve short names correctly

Solution 4: Update Virtual Directory URLs

Align virtual directory URLs with certificate names:

# Set consistent InternalURL and ExternalURL across all virtual directories
$InternalFQDN = "mail.contoso.com"
$ExternalFQDN = "mail.contoso.com"

# Autodiscover
Set-ClientAccessService -Identity "EXCH01" -AutoDiscoverServiceInternalUri "https://$InternalFQDN/autodiscover/autodiscover.xml"

# OWA
Get-OwaVirtualDirectory -Server EXCH01 | Set-OwaVirtualDirectory -InternalUrl "https://$InternalFQDN/owa" -ExternalUrl "https://$ExternalFQDN/owa"

# ECP
Get-EcpVirtualDirectory -Server EXCH01 | Set-EcpVirtualDirectory -InternalUrl "https://$InternalFQDN/ecp" -ExternalUrl "https://$ExternalFQDN/ecp"

# EWS
Get-WebServicesVirtualDirectory -Server EXCH01 | Set-WebServicesVirtualDirectory -InternalUrl "https://$InternalFQDN/EWS/Exchange.asmx" -ExternalUrl "https://$ExternalFQDN/EWS/Exchange.asmx"

# ActiveSync
Get-ActiveSyncVirtualDirectory -Server EXCH01 | Set-ActiveSyncVirtualDirectory -InternalUrl "https://$InternalFQDN/Microsoft-Server-ActiveSync"-Server-ActiveSync" -ExternalUrl "https://$ExternalFQDN/Microsoft-Server-ActiveSync"-Server-ActiveSync"

# OAB
Get-OabVirtualDirectory -Server EXCH01 | Set-OabVirtualDirectory -InternalUrl "https://$InternalFQDN/OAB" -ExternalUrl "https://$ExternalFQDN/OAB"

# MAPI
Get-MapiVirtualDirectory -Server EXCH01 | Set-MapiVirtualDirectory -InternalUrl "https://$InternalFQDN/mapi" -ExternalUrl "https://$ExternalFQDN/mapi"

# Outlook Anywhere
Get-OutlookAnywhere -Server EXCH01 | Set-OutlookAnywhere -InternalHostname $InternalFQDN -ExternalHostname $ExternalFQDN -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
🚨

Danger Zone

Changing virtual directory URLs requires Outlook profile recreation for affected users. Plan URL changes during maintenance windows and communicate to users beforehand. Consider using Autodiscover to minimize impact.

Verification Steps

Verify Certificate Configuration

# 1. Verify certificate is assigned to all services
Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"} |
    Format-List Subject, CertificateDomains, Services, NotAfter, Status

# 2. Test HTTPS connectivity to all endpoints
$endpoints = @(
    "https://mail.contoso.com/owa",
    "https://mail.contoso.com/ecp",
    "https://autodiscover.contoso.com/autodiscover/autodiscover.xml",
    "https://mail.contoso.com/EWS/Exchange.asmx",
    "https://mail.contoso.com/Microsoft-Server-ActiveSync"-ActiveSync"
)

foreach ($url in $endpoints) {
    Write-Host "Testing: $url" -ForegroundColor Cyan
    try {
        $request = [System.Net.WebRequest]::Create($url)
        $request.Method = "HEAD"
        $request.Timeout = 10000
        $response = $request.GetResponse()
        Write-Host "  Status: $($response.StatusCode)" -ForegroundColor Green
        $response.Close()
    } catch {
        Write-Host "  Error: $($_.Exception.Message)" -ForegroundColor Red
    }
}

# 3. Test Autodiscover
Test-OutlookWebServices -Identity "testuser@contoso.com" -TargetAddress "testuser@contoso.com" -MailboxCredential (Get-Credential)

# 4. Verify from client perspective (run from Outlook client)
# Open Outlook > Hold Ctrl + right-click System Tray icon > "Test E-mail AutoConfiguration""Test E-mail AutoConfiguration"

# 5. Check Event Log for certificate errors
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MSExchange*'; Level=2; StartTime=(Get-Date).AddHours(-1)} |
    Where-Object {$_.Message -match "certificate"} | Format-List TimeCreated, Message

✓ Success Indicators

  • • No certificate warnings in browsers
  • • Outlook connects without prompts
  • • Autodiscover test passes
  • • Mobile devices sync successfully

⚠ Warning Signs

  • • Intermittent warnings
  • • Some clients work, others don't
  • • Internal vs external different
  • • Certificate expiry approaching

✗ Failure Indicators

  • • Persistent certificate errors
  • • SSL handshake failures
  • • Event ID 1035 continues
  • • Autodiscover completely fails

Prevention Strategies

Certificate Best Practices

  • ✓
    Plan SANs carefully

    Document all hostnames before ordering certificate

  • ✓
    Use trusted CA

    Avoid self-signed certificates in production

  • ✓
    Include internal FQDNs

    Add server.domain.local names for internal clients

  • ✓
    Track expiration

    Set calendar reminders 60/30/14 days before expiry

Certificate Monitoring Script

# Schedule this script to run weekly
$WarningDays = 30
$CriticalDays = 14

$Certs = Get-ExchangeCertificate |
    Where-Object {$_.Services -ne "None"}

foreach ($cert in $Certs) {
    $daysRemaining = ($cert.NotAfter - (Get-Date)).Days
    $status = if ($daysRemaining -le $CriticalDays) {"CRITICAL"}
              elseif ($daysRemaining -le $WarningDays) {"WARNING"}
              else {"OK"}

    [PSCustomObject]@{
        Subject = $cert.Subject
        Services = $cert.Services
        Expires = $cert.NotAfter
        DaysRemaining = $daysRemaining
        Status = $status
    }
} | Format-Table -AutoSize

# Send alert email if expiring soon
# Add email notification logic here

Certificate Planning Checklist

Required SANs

  • ☐ mail.domain.com (primary external)
  • ☐ autodiscover.domain.com
  • ☐ owa.domain.com (if separate)
  • ☐ Internal server FQDN(s)
  • ☐ Legacy namespace (if migrating)

Pre-Deployment Testing

  • ☐ Verify all SANs present
  • ☐ Test in staging environment
  • ☐ Validate certificate chain
  • ☐ Plan deployment window
  • ☐ Prepare rollback procedure

When to Escalate

Escalate to Microsoft or Exchange Specialist When:

  • →Certificate appears correctly configured but errors persist
  • →Hybrid configuration causing certificate conflicts
  • →Complex multi-domain or multi-forest certificate requirements
  • →Third-party load balancer SSL offloading issues
  • →Internal CA certificate deployment challenges

Need Expert Exchange Certificate Help?

Our Exchange Server specialists have resolved thousands of certificate configuration issues. We can help you design, implement, and maintain proper certificate infrastructure.

Get Certificate SupportCall: 1-800-555-1234

15 Minutes average response time for certificate emergencies

Frequently Asked Questions

A certificate name mismatch occurs when the hostname clients use to connect doesn't match any of the Subject Name (CN) or Subject Alternative Names (SANs) on the SSL certificate. This causes security warnings and connection failures because the certificate cannot be validated for the requested hostname.

Related Exchange Server Errors

Event ID 1035: Autodiscover Service Failed

Read Fix Guide

Error 0x80040115: Connection to Server Failed

Read Fix Guide

Event ID 1053: MAPI over HTTP Connection Failed

Read Fix Guide
View All Exchange Services

Can't Resolve CERTIFICATE_NAME_MISMATCH?

Exchange errors can cause data loss or extended downtime. Our specialists are available 24/7 to help.

Emergency help - Chat with us
Medha Cloud

Medha Cloud Exchange Server Team

Microsoft Exchange Specialists

Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.

15+ Years ExperienceMicrosoft Certified99.7% Success Rate24/7 Support
Contact TeamFollow on LinkedIn