Exchange Server SSL Certificate: Replacement, Renewal, and Binding Configuration

Exchange Server uses TLS certificates for multiple services: OWA, ActiveSync, Autodiscover, SMTP (internal and external), IMAP, and POP3. Replacing an expiring certificate in Exchange involves importing the new certificate, assigning it to the correct services, and removing the old one — without interrupting mail flow during the process. This article walks through every step, including certificate request generation, import, service binding, and validation.

Exchange certificate architecture

Exchange uses certificates in several places:

Service	What it protects	Port
IIS (OWA, ECP, ActiveSync, OAB, EWS)	HTTPS for web clients and mobile devices	443
Autodiscover	Client configuration endpoint	443
SMTP (Internal/Hub transport)	TLS between Exchange servers and to smarthosts	25
Client SMTP submission	TLS for SMTP clients	587
IMAP4	TLS for IMAP clients	993
POP3	TLS for POP clients	995

Each service can use the same certificate (if it covers all required names) or separate certificates.

Certificate requirements for Exchange

The certificate must have Subject Alternative Names (SANs) for:

• The external hostname clients use for OWA: mail.example.com
• Autodiscover: autodiscover.example.com
• Internal FQDN (for internal clients): exchange01.corp.example.com
• (Optional) Exchange Online hybrid names if configured

If you are using split DNS or have different internal and external namespaces, you may need both names.

Step 1: Generate a Certificate Signing Request in Exchange

You can generate the CSR from the Exchange Admin Center (EAC) or from the Exchange Management Shell (EMS).

Via Exchange Admin Center (EAC)

1. Open EAC at https://localhost/ecp.
2. Go to Servers → Certificates.
3. Select the server and click + (New).
4. Choose Create a request for a certificate from a certification authority.
5. Give the request a Friendly Name (e.g., Exchange-2024).
6. Click Next.
7. On Store Certificate Request on this server, leave selected.
8. Configure the domains/SANs. Click Add for each:

• mail.example.com
• autodiscover.example.com
• exchange01.corp.example.com
• webmail.example.com (if applicable)

1. Set the Subject Name fields (Organization, Common Name, etc.).
2. Choose the Server to store the request on.
3. Specify a File path to save the CSR (e.g., C:\Certs\exchange-csr.txt).
4. Click Finish.

Via Exchange Management Shell

$domains = @(
    "mail.example.com",
    "autodiscover.example.com",
    "exchange01.corp.example.com"
)

New-ExchangeCertificate `
    -GenerateRequest `
    -SubjectName "CN=mail.example.com, O=Example Corp, C=US" `
    -DomainName $domains `
    -KeySize 2048 `
    -Path "C:\Certs\exchange-csr.txt" `
    -Server EXCHANGE01

Submit the content of exchange-csr.txt to your CA (internal AD CS or commercial CA like Digicert/Sectigo).

Step 2: Import the signed certificate

Once the CA returns the signed certificate (usually a .cer, .crt, or .pfx file):

If you received a PFX (PKCS#12) file

Import-ExchangeCertificate `
    -Server EXCHANGE01 `
    -FileData ([System.IO.File]::ReadAllBytes("C:\Certs\new-cert.pfx")) `****** -String "PFX-password" -AsPlainText -Force)

If you received a CER/CRT file (needs to be combined with the pending request)

First, if you generated the request from EAC, complete it there:

1. Go to Servers → Certificates.
2. Select the pending request (shows as “Pending request”).
3. Click Complete (the ribbon icon).
4. Enter the path to the certificate file received from the CA.

Or via EMS:

# Note the thumbprint of the pending request
Get-ExchangeCertificate | where {$_.Status -eq "PendingRequest"} | fl Thumbprint, Subject

Import-ExchangeCertificate `
    -Server EXCHANGE01 `
    -FileData ([System.IO.File]::ReadAllBytes("C:\Certs\signed-cert.cer"))

Step 3: Assign the certificate to Exchange services

After import, the certificate must be explicitly assigned to services.

Via EAC

1. Go to Servers → Certificates.
2. Select the new certificate.
3. Click the Edit (pencil) icon.
4. Go to the Services tab.
5. Check the services: IIS, SMTP, IMAP (if used), POP (if used).
6. Click Save.

Exchange will warn you that you are replacing the existing certificate for those services. Confirm.

Via EMS

# Get the thumbprint of the new certificate
$thumb = (Get-ExchangeCertificate | where {$_.Subject -like "*mail.example.com*"} | Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint

# Assign to services
Enable-ExchangeCertificate `
    -Server EXCHANGE01 `
    -Thumbprint $thumb `
    -Services "IIS, SMTP, IMAP, POP" `
    -Force

The -Force flag suppresses the confirmation prompt.

Step 4: Assign the certificate for internal SMTP (STARTTLS)

For internal SMTP TLS between Exchange servers, assignment via Enable-ExchangeCertificate with the SMTP service flag is usually sufficient. Verify:

# Check which certificate is used for SMTP
Get-TransportService | Select-Object -Property Identity, InternalTransportCertificateThumbprint

# Or check the receive connector
Get-ReceiveConnector | where {$_.Server -eq "EXCHANGE01"} | Select-Object -Property Name, TlsCertificateName

For specific receive connectors, you can set the certificate explicitly:

Set-ReceiveConnector `
    -Identity "EXCHANGE01\Default Frontend EXCHANGE01" `
    -TlsCertificateName "<I>CN=Internal CA<S>CN=mail.example.com"

Step 5: Verify the new certificate is in use

Check which certificate IIS is using for the default website:

# On the Exchange server
netsh http show sslcert ipport=0.0.0.0:443

Look for the certificate hash matching your new certificate’s thumbprint.

Test from a client:

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>&1 \
  | openssl x509 -noout -subject -dates -issuer

Test Autodiscover:

openssl s_client -connect autodiscover.example.com:443 -servername autodiscover.example.com </dev/null 2>&1 \
  | openssl x509 -noout -subject -dates

Test SMTP STARTTLS:

openssl s_client -connect mail.example.com:25 -starttls smtp -servername mail.example.com </dev/null 2>&1 \
  | openssl x509 -noout -subject -dates

Step 6: Remove the old certificate

After confirming the new certificate is working:

# List all certificates
Get-ExchangeCertificate | Select-Object -Property Thumbprint, Subject, NotAfter, Services

# Remove the old one (replace with actual thumbprint)
Remove-ExchangeCertificate -Thumbprint "OLD_THUMBPRINT" -Server EXCHANGE01 -Confirm:$false

Do not remove the old certificate until you are certain the new one is serving all services correctly. Removing an active certificate immediately disrupts services.

Handling multi-server Exchange environments

In Exchange environments with multiple Mailbox servers and/or Edge Transport servers, each server needs the certificate installed:

# Export the certificate with private key
$pwd = ConvertTo-SecureString -String "export-password" -AsPlainText -Force
$thumb = "YOUR_NEW_THUMBPRINT"

Export-ExchangeCertificate -Thumbprint $thumb -FileName "C:\Certs\exchange-cert.pfx"****** -Server EXCHANGE01

# Import on each additional server
foreach ($server in @("EXCHANGE02", "EXCHANGE03")) {
    Import-ExchangeCertificate `
        -Server $server `
        -FileData ([System.IO.File]::ReadAllBytes("C:\Certs\exchange-cert.pfx")) `******

    Enable-ExchangeCertificate `
        -Server $server `
        -Thumbprint $thumb `
        -Services "IIS, SMTP" `
        -Force
}

Certificate renewal timing

Exchange certificates should be renewed at least 30 days before expiry. Check expiry:

Get-ExchangeCertificate | Select-Object -Property Subject, NotAfter, Services, Thumbprint | 
    Where-Object { $_.NotAfter -lt (Get-Date).AddDays(60) } |
    Format-Table

Using DigiCert or Sectigo automated renewal with Exchange

Commercial CAs like DigiCert and Sectigo provide certificate management tools that can automate renewal. Their tools typically:

1. Detect that a certificate on IIS is expiring.
2. Auto-generate a new CSR.
3. Submit for renewal and receive the signed certificate.
4. Import and bind to IIS automatically.

For Exchange, these tools work for the IIS binding. The SMTP service binding must still be done via Enable-ExchangeCertificate.

Troubleshooting

Problem	Cause	Fix
OWA shows old certificate after import	IIS not restarted / binding not updated	Run Enable-ExchangeCertificate with -Services IIS
Mobile devices show certificate error	Autodiscover returning old cert	Assign cert to IIS service; check Autodiscover DNS
SMTP TLS fails after cert change	SMTP service not assigned new cert	Re-run Enable-ExchangeCertificate -Services SMTP
Certificate is not valid for Exchange services	SANs do not cover required names	Request new certificate with correct SANs
Cannot remove old cert	Old cert still assigned to a service	Assign new cert to all services first, then remove

Summary

Exchange certificate replacement follows a consistent pattern: generate CSR → get it signed → import → assign services → verify → remove old certificate. Use Enable-ExchangeCertificate with -Services "IIS, SMTP" (and IMAP/POP if in use) to activate the new certificate. In multi-server environments, export the certificate as PFX and import it on each server individually. Always verify with openssl s_client against each hostname before removing the old certificate.