When Exchange Stops Working: The Hidden Certificate Cause

The Monday Morning Scenario

It’s 7:15 AM Monday. The helpdesk starts getting calls. Outlook is showing certificate errors. Mobile phones can’t sync. External partners report email delivery failures.

The Exchange team checks the server — services are running, databases are mounted, network is fine. But users can’t connect. The culprit? A certificate expired over the weekend.

This isn’t hypothetical. Exchange has deep certificate dependencies that, when broken, can take down email for an entire organization while the server appears healthy from every other metric.

Exchange Certificate Dependencies

Exchange Server uses certificates for far more than just HTTPS. Here’s the full dependency map:

Exchange Certificate Usage:

Service	Certificate Purpose
IIS (HTTPS)	OWA, ECP, ActiveSync, EWS, MAPI
SMTP	TLS for mail flow (send/receive)
POP3/IMAP	Client connections
Unified Messaging	SIP/TLS communications
Federation	Organization relationships
OAuth	Server-to-server auth
SMTP TLS (Partner)	Forced TLS with specific domains

A single certificate often covers multiple services. When it expires, everything breaks simultaneously.

VPN Certificate Outage Analysis

Where time is spent and what actually causes failures

Time Spent During Incident

Root Causes of VPN Cert Failures

75%

of incident time spent finding the problem

10%

of time is the actual fix

The Real Outage: What Happened

Timeline of Events

Time	Events
Friday 17:00	Certificate “mail.company.com” expires (valid: 2025-07-18 to 2026-07-17). No alert fired — monitoring checks HTTP 200 only
Saturday	Weekend, nobody notices. SMTP TLS connections start failing. External mail from TLS-enforcing partners queues
Sunday 22:00	Mobile ActiveSync stops working. Some users notice but assume “weekend maintenance”
Monday 07:15	Staff arrive, Outlook throws cert warnings. OWA shows “Certificate Error” page. Helpdesk overwhelmed with tickets
Monday 07:45	Exchange admin identified certificate expiry
Monday 08:30	Emergency certificate renewal initiated
Monday 09:15	New certificate installed on Exchange. Services restart required for SMTP binding
Monday 09:45	Full email functionality restored. Queued mail begins delivering (backlog: ~2,400 messages)

Total downtime: ~62 hours (from expiry to full restoration) User impact: 2,100 mailboxes Business impact: $180,000 (estimated based on productivity loss + partner SLA penalties)

Why It Went Undetected

Check	What It Tested	Result During Outage
Server ping	Network connectivity	✓ Pass
Service status	Windows services running	✓ Pass
Database mount	Mailbox DB availability	✓ Pass
HTTP 200 check	Port 443 responding	⚠️ Pass (returned error page)
Certificate validity	Cert expiry date	✗ Not monitored
TLS handshake	Successful TLS connection	✗ Not monitored
Mail flow test	End-to-end email delivery	✗ Not monitored

The monitoring system was checking that Exchange was running — not that it was working.

Exchange Certificate Architecture

How Certificates Are Bound in Exchange

# View current Exchange certificate assignments
Get-ExchangeCertificate | Format-List `
  Subject, CertificateDomains, NotAfter, Services, Status, Thumbprint

# Example output:
# Subject       : CN=mail.company.com
# CertDomains   : {mail.company.com, autodiscover.company.com, 
#                  company.com, *.company.com}
# NotAfter      : 7/17/2026 11:59:59 PM
# Services      : IIS, SMTP, POP, IMAP
# Status        : Valid
# Thumbprint    : A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0

Certificate-to-Service Mapping

Certificate: mail.company.com (SAN: mail, autodiscover, owa)

• IIS Binding (port 443)
  • OWA Virtual Directory
  • ECP Virtual Directory
  • ActiveSync Virtual Directory
  • EWS Virtual Directory
  • MAPI Virtual Directory
  • OAB Virtual Directory
  • Autodiscover Virtual Directory
• SMTP Service
  • Default Frontend Receive Connector
  • Client Frontend Receive Connector
  • Outbound Send Connectors (STARTTLS)
• POP3 Service (port 995)
  • Client POP connections
• IMAP4 Service (port 993)
  • Client IMAP connections

Troubleshooting Exchange Certificate Issues

Step 1: Identify the Problem

# Check certificate status
Get-ExchangeCertificate | Where-Object {$_.NotAfter -lt (Get-Date)} | 
  Select-Object Subject, NotAfter, Services, Thumbprint

# Check IIS bindings
Get-WebBinding -Protocol https | 
  Select-Object bindingInformation, certificateHash

# Test TLS handshake
openssl s_client -connect mail.company.com:443 -servername mail.company.com

# Check SMTP STARTTLS
openssl s_client -connect mail.company.com:25 -starttls smtp

Step 2: Verify Certificate Chain

# Full chain validation
$cert = Get-ExchangeCertificate -Thumbprint "A1B2C3D4..."
certutil -verify -urlfetch "$($cert.Thumbprint).cer"

# Check if intermediates are installed
Get-ChildItem Cert:\LocalMachine\CA | 
  Where-Object {$_.Issuer -like "*DigiCert*"} |
  Select-Object Subject, NotAfter

Step 3: Emergency Certificate Replacement

# Generate new CSR if needed
$request = New-ExchangeCertificate -GenerateRequest `
  -SubjectName "C=US, O=Company, CN=mail.company.com" `
  -DomainName "mail.company.com","autodiscover.company.com","owa.company.com" `
  -PrivateKeyExportable $true `
  -KeySize 2048

# After receiving the new certificate:
Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes("C:\cert\mail.cer"))

# Assign to services
Enable-ExchangeCertificate -Thumbprint "NEWTHUMBPRINT" `
  -Services IIS,SMTP,POP,IMAP -Force

# Restart affected services
Restart-Service MSExchangeTransport
Restart-Service MSExchangePOP3
Restart-Service MSExchangeIMAP4

# IIS reset for web services
iisreset /noforce

Step 4: Validate Recovery

# Test OWA access
Invoke-WebRequest -Uri "https://mail.company.com/owa" -UseBasicParsing | 
  Select-Object StatusCode

# Test ActiveSync
$headers = @{
  "Authorization" = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('user:pass')))"
  "MS-ASProtocolVersion" = "14.0"
}
Invoke-WebRequest -Uri "https://mail.company.com/Microsoft-Server-ActiveSync" `
  -Headers $headers -Method OPTIONS

# Test mail flow
Send-MailMessage -From "test@company.com" -To "test@company.com" `
  -Subject "Mail Flow Test $(Get-Date)" -SmtpServer "mail.company.com" -UseSsl

# Verify SMTP TLS
openssl s_client -connect mail.company.com:25 -starttls smtp 2>/dev/null | 
  openssl x509 -noout -dates

The Hidden Dependencies

Autodiscover and Certificate Names

Outlook clients use Autodiscover to find Exchange settings. If the certificate doesn’t include the Autodiscover name, clients get errors even if Exchange is technically working:

Required SAN entries for Exchange:

• mail.company.com (primary access)
• autodiscover.company.com (client configuration)
• company.com (for Autodiscover fallback)
• Internal FQDN (for internal clients)

Federation and OAuth Certificates

# Federation certificate (separate from main Exchange cert)
Get-FederationTrust | Select-Object Name, TokenIssuerCertificate, 
  TokenIssuerPrevCertificate, ApplicationIdentifier

# OAuth certificate for server-to-server
Get-AuthConfig | Select-Object CurrentCertificateThumbprint, 
  PreviousCertificateThumbprint, ServiceName

These certificates are often forgotten because they don’t affect daily mail flow — until they expire and hybrid/cloud features break.

Send Connector TLS Requirements

# Check connectors with forced TLS
Get-SendConnector | Where-Object {$_.TlsDomain -or $_.RequireTLS} |
  Select-Object Name, TlsDomain, RequireTLS, TlsAuthLevel

# Example: Partner requires TLS
# Name: "To Partner - Forced TLS"
# TlsDomain: partner.com
# RequireTLS: True
# TlsAuthLevel: DomainValidation

When the Exchange certificate expires, partner mail flow with forced TLS silently queues — no bounce, no error to users, just delayed delivery until someone notices.

Prevention Strategy

Monitoring That Actually Works

# cert-monitor-exchange.ps1 - Weekly Exchange certificate check
$threshold = 30  # days
$alerts = @()

# Check Exchange certificates
$certs = Get-ExchangeCertificate | Where-Object {$_.Services -ne "None"}
foreach ($cert in $certs) {
    $daysLeft = ($cert.NotAfter - (Get-Date)).Days
    if ($daysLeft -lt $threshold) {
        $alerts += [PSCustomObject]@{
            Subject = $cert.Subject
            Expiry = $cert.NotAfter
            DaysLeft = $daysLeft
            Services = $cert.Services -join ", "
            Thumbprint = $cert.Thumbprint
        }
    }
}

# Check Federation/OAuth certs
$authConfig = Get-AuthConfig
$oauthCert = Get-ChildItem "Cert:\LocalMachine\My\$($authConfig.CurrentCertificateThumbprint)"
$oauthDays = ($oauthCert.NotAfter - (Get-Date)).Days
if ($oauthDays -lt $threshold) {
    $alerts += [PSCustomObject]@{
        Subject = "OAuth Auth Certificate"
        Expiry = $oauthCert.NotAfter
        DaysLeft = $oauthDays
        Services = "OAuth/Server-to-Server"
        Thumbprint = $oauthCert.Thumbprint
    }
}

# Send alert if any certificates expiring
if ($alerts.Count -gt 0) {
    $body = $alerts | ConvertTo-Html -Fragment
    Send-MailMessage -From "monitoring@company.com" `
      -To "exchange-team@company.com" `
      -Subject "⚠️ Exchange Certificate Expiry Warning" `
      -Body $body -BodyAsHtml -SmtpServer "localhost"
}

Exchange Certificate Lifecycle Calendar

Month	Activity	Owner
M-3	Certificate expiry alert triggers	Monitoring system
M-2	Renewal request submitted to CA	Exchange admin
M-1	New certificate received, tested in staging	Exchange admin
M-0.5	Change request submitted for production	Change management
M-0.25	Certificate installed, old cert remains active	Exchange admin
Expiry Day	Old certificate removed, new confirmed active	Exchange admin
M+1	Post-change validation	Operations

Key Exchange Certificate Best Practices

✓ DO:

• Include ALL required SANs (mail, autodiscover, internal FQDN)
• Monitor certificate expiry separately from service health
• Test mail flow end-to-end (not just port availability)
• Keep previous certificate available for rollback
• Document all certificate-to-service bindings
• Set calendar reminders 90, 60, and 30 days before expiry
• Monitor OAuth/Federation certs separately

✗ DON’T:

• Rely on a single monitoring check (HTTP 200 ≠ working email)
• Assume auto-enrollment covers Exchange certificates
• Forget about partner forced-TLS configurations
• Ignore mobile device certificate trust requirements
• Wait for users to report the problem
• Schedule certificate changes over weekends without monitoring

---

About QCecuring

QCecuring monitors Exchange certificate health as part of our comprehensive lifecycle management platform. We provide proactive alerts, automated discovery of all Exchange-related certificates, and integration with change management workflows to prevent email outages caused by certificate expiry.

Tags: Exchange Server, certificate expiry, email outage, Outlook, ActiveSync, SMTP TLS, certificate troubleshooting, Exchange certificates, mail flow, OWA, enterprise email