Why does Outlook still warn about the certificate after I installed it?

Almost always because the certificate was imported but never bound to IIS, or because Outlook is reaching a name the certificate does not carry. Run Get-ExchangeCertificate and look at the Services column: if it does not include IIS, nothing you did is being served yet. If IIS is there, check what name Outlook is connecting to. Exchange publishes its internal URLs from Active Directory, and those often still point at the server's own FQDN rather than the public name on your certificate.

Can I put my internal server name on a public certificate?

No. Publicly trusted certificate authorities stopped issuing names that cannot be validated in public DNS on 1 November 2015, which rules out EX01.contoso.local and bare hostnames. The fix is split DNS: publish the same public name, mail.contoso.com, in your internal DNS pointing at the internal IP address, then set every Exchange virtual directory URL to that name. Internal clients and external clients then reach the same name and the same certificate.

Do I need autodiscover.contoso.com on the certificate?

Not necessarily. It is the simplest route and what most administrators do, but you can point Autodiscover at your existing mail host with an SRV record in public DNS instead, at the cost of a client prompt on first configuration in some Outlook versions. Adding the name to the certificate avoids that prompt and avoids one more DNS record to explain to whoever inherits the system. Decide before you generate the request, because adding a name later means reissuing.

Does importing a PFX install the certificate?

It puts the certificate and its private key in the server's certificate store, which is only half the job. Exchange keeps its own record of which certificate serves which protocol, and that record is not touched by an import. Until you run Enable-ExchangeCertificate with the services you want, Outlook on the web keeps presenting whatever was bound before, usually the self-signed certificate Exchange generated during setup.

Which services should I enable on the certificate?

IIS and SMTP cover the great majority of deployments. IIS carries Outlook on the web, the Exchange admin center, Exchange Web Services, Autodiscover and Outlook connectivity, so it is the one users notice. SMTP covers mail transport. Add POP and IMAP only if you actually run those protocols, because enabling a service you do not use gives you one more thing to rebind at every renewal for no benefit.

Will Enable-ExchangeCertificate interrupt mail flow?

Binding SMTP prompts you to confirm that you want to replace the certificate currently in use, and answering yes swaps it for new connections. Existing sessions finish on the old one. The genuine interruption is on the IIS side, where the change may need an IIS restart before every client picks it up, so the safe window is the same one you would use for any IIS restart rather than a full maintenance outage.

How often will I have to redo this now?

Twice a year, and more later. The CA/Browser Forum reduced the maximum lifetime for publicly trusted TLS certificates to 200 days on 15 March 2026, with 100 days arriving on 15 March 2027 and 47 days on 15 March 2029. Most certificate authorities issue slightly under the ceiling, so plan on renewing, importing and rebinding roughly every six months until the next step down. Writing the import-and-enable sequence into a script now saves the person doing it in March.

Install an SSL Certificate on Exchange Server

The short answer

Two commands do the work. Import-ExchangeCertificate puts the issued certificate and its private key into the server's store, and Enable-ExchangeCertificate -Services IIS,SMTP is what actually puts it in front of clients. Importing on its own changes nothing anyone can see. The request needs mail.example.com and usually autodiscover.example.com as names, and it cannot carry an internal name such as EX01.example.local, which no public CA has issued since 2015. Exchange Server SE and Exchange 2019 CU15 can do the same job from the admin center; PowerShell is still what works on every server in a database availability group.

The gap between these two stages is where most Exchange certificate tickets come from: the file was imported, the change looked complete, and Outlook kept showing the old warning because nothing had been bound.

What you need before you start

Administrator access to the Exchange server, the Exchange Management Shell open on that server, and a decision about which host names the certificate will carry. You also need to know which build you are on, because Exchange 2016 and Exchange 2019 left support on 14 October 2025 and Exchange Server Subscription Edition is now the only on-premises version Microsoft supports. Everything below works identically on both.

One number shapes the whole job. Since 15 March 2026 the CA/Browser Forum caps publicly trusted TLS certificates at 200 days, so an Exchange certificate that used to be a yearly errand is now a twice-yearly one, and the schedule tightens again to 100 days in March 2027. Nothing in Exchange renews or rebinds a certificate on its own, which makes the sequence you are about to run worth saving as a script rather than a memory.

A note on the admin center. Microsoft removed certificate creation, import and export from the Exchange admin center in Exchange 2016 CU23 and Exchange 2019 CU12, then restored them in Exchange 2019 CU15, and they are present in Exchange Server SE. If your EAC has no certificates page, that is the reason, and PowerShell is the way through regardless of build.

Which names belong on the certificate

A standard Exchange deployment needs two: the name your clients connect to, usually mail.example.com, and the Autodiscover name, autodiscover.example.com. Both must resolve in public DNS. Internal names such as EX01.example.local, bare host names and private IP addresses cannot appear on a publicly trusted certificate, because certificate authorities stopped issuing them on 1 November 2015.

Exchange deployments that still warn internally almost always kept the server's own Active Directory name in their virtual directory URLs, which no public certificate can ever cover.

Two names means the request is a multi-domain certificate rather than a single-name one. That is the normal shape for Exchange, and it is worth listing every name you will need in the same request: a legacy name kept for an old client, a second mail domain, an owa.example.com someone bookmarked years ago. Adding a name after issuance is a reissue, not an edit.

If you have not ordered yet, this is the point to do it, because validation runs while you are still deciding the rest. Multi-domain SSL certificates from My-SSL cover several host names on one certificate and one renewal, which is what keeps an Exchange rebind to a single pass rather than three.

The internal-name trap. Exchange publishes URLs to clients from Active Directory, and after setup those URLs name the server itself. Fix that before you blame the certificate: point every virtual directory and the Autodiscover service URI at your public name, and publish that name in internal DNS. The detail of which names a mail host needs is covered in which certificate a mail server needs.

# Point Exchange at the public name instead of the server's own FQDN
$name = "mail.contoso.com"

Get-ClientAccessService | Set-ClientAccessService `
  -AutoDiscoverServiceInternalUri "https://$name/Autodiscover/Autodiscover.xml"

Get-OwaVirtualDirectory  | Set-OwaVirtualDirectory  -InternalUrl "https://$name/owa"  -ExternalUrl "https://$name/owa"
Get-EcpVirtualDirectory  | Set-EcpVirtualDirectory  -InternalUrl "https://$name/ecp"  -ExternalUrl "https://$name/ecp"
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory `
  -InternalUrl "https://$name/EWS/Exchange.asmx" -ExternalUrl "https://$name/EWS/Exchange.asmx"
Get-ActiveSyncVirtualDirectory  | Set-ActiveSyncVirtualDirectory `
  -InternalUrl "https://$name/Microsoft-Server-ActiveSync" -ExternalUrl "https://$name/Microsoft-Server-ActiveSync"

Generating the request on the server

Generate the CSR on the Exchange server itself so the private key is created there and never travels. New-ExchangeCertificate with -GenerateRequest returns the request as text, which you then write to a file. There is no -RequestFile parameter on Exchange 2016 and later, which is the first place older walkthroughs go wrong.

$req = New-ExchangeCertificate `
  -GenerateRequest `
  -FriendlyName "mail.contoso.com 2026" `
  -SubjectName "C=DE,O=Contoso GmbH,CN=mail.contoso.com" `
  -DomainName mail.contoso.com,autodiscover.contoso.com `
  -KeySize 2048 `
  -PrivateKeyExportable $true

[System.IO.File]::WriteAllBytes('C:\certs\mail-contoso.req',
  [System.Text.Encoding]::UTF8.GetBytes($req))

Microsoft's own example writes the file with Unicode.GetBytes, which produces UTF-16 with a null byte between every character. Plenty of CA order forms and OpenSSL itself refuse that file, and the error you get back says nothing useful about encoding. Writing UTF-8, as above, avoids the round trip.

Keep -PrivateKeyExportable $true if you have more than one Exchange server or any load balancer that terminates TLS, because you will need to export the finished certificate as a PFX to put it on the others. Set -KeySize 2048 unless you have a policy reason for 4096; the larger key costs handshake time on every Outlook connection and buys nothing a CA requires. What goes into the subject line is explained in what a CSR contains.

Submit the contents of the .req file to your certificate authority. A domain-validated certificate comes back in minutes, an organization-validated one after the CA has confirmed the company exists, which is usually one to three working days.

Importing the issued certificate

Completing a pending request and importing a PFX are the same cmdlet with different inputs. If the CSR was generated on this server, import the issued certificate file and Exchange pairs it with the waiting private key. If the certificate came from somewhere else, import a PFX and supply its password.

# Completing a request generated on this server (.cer or .p7b from the CA)
Import-ExchangeCertificate `
  -FileData ([System.IO.File]::ReadAllBytes('C:\certs\mail-contoso.cer'))

# Importing a PFX exported from another server
Import-ExchangeCertificate `
  -FileData ([System.IO.File]::ReadAllBytes('C:\certs\mail-contoso.pfx')) `
  -Password (Read-Host "PFX password" -AsSecureString) `
  -PrivateKeyExportable $true

# Note the thumbprint that comes back — the next step needs it
Get-ExchangeCertificate | Format-List FriendlyName,Subject,CertificateDomains,Thumbprint,Services,NotAfter

Ask the CA for the chain, not just the leaf. If the intermediate is missing from the Windows store, the server sends an incomplete chain and the failure is intermittent in the worst way: desktops that cached the intermediate previously work fine while a fresh phone does not. Importing a P7B bundle brings the intermediates along; the guide to certificate formats covers converting whatever your CA actually sent.

Look at the Services column in that last command's output. On a freshly imported certificate it is empty, and it stays empty until the next step.

Binding the certificate to services

Enable-ExchangeCertificate takes the thumbprint and a list of services, and this is the step that changes what a client is shown. IIS covers Outlook on the web, the admin center, Exchange Web Services, Autodiscover and Outlook connectivity. SMTP covers mail transport. POP and IMAP are worth adding only if you run them.

$tp = (Get-ExchangeCertificate |
  Where-Object { $_.FriendlyName -eq "mail.contoso.com 2026" }).Thumbprint

Enable-ExchangeCertificate -Thumbprint $tp -Services IIS,SMTP

# Confirm the binding landed
Get-ExchangeCertificate -Thumbprint $tp | Format-List Services,NotAfter

# Let IIS pick up the new binding
Restart-Service -Name W3SVC,WAS -Force

Enabling SMTP prompts you to confirm that you want to replace the certificate currently serving it, which on most servers is the self-signed one Exchange created during setup. Say yes. Leaving the self-signed certificate on SMTP is what produces the TLS complaints from partner mail systems that nobody connects to the certificate work done that morning.

Do not delete the old certificate yet. Keep it in the store until the new one is confirmed working everywhere, including on connectors and on any other server. Removing it the same hour turns a five-minute rollback into a reissue.

Connectors, hybrid, and the name string

Send connectors and Exchange hybrid do not follow the SMTP binding. They name a certificate explicitly through TlsCertificateName, a string built from the certificate's issuer and subject. Renew the certificate without updating that string and outbound mail keeps trying to present a certificate that is no longer there, which usually surfaces as mail queueing to Microsoft 365 rather than as an error anyone reads.

$cert = Get-ExchangeCertificate -Thumbprint $tp
$tlsName = "<i>$($cert.Issuer)<s>$($cert.Subject)"

Set-SendConnector -Identity "Outbound to Office 365" -TlsCertificateName $tlsName

# Check what each connector currently names
Get-SendConnector | Format-List Name,TlsCertificateName

Receive connectors work the same way when they specify a certificate. If you run the Hybrid Configuration Wizard after renewing, it will offer to update the connectors for you, which is the easier route on a hybrid server as long as you are ready for it to touch the rest of the hybrid configuration at the same time.

More than one server

A certificate binding is per server. In a database availability group, or behind any load balancer that passes TLS through, every Exchange server needs the same certificate imported and enabled individually. Export once as a PFX, import on each, then run the enable command against each server. Missing one produces the failure that only some users see, only sometimes.

# Export from the server that holds the private key
$pfx = Export-ExchangeCertificate -Thumbprint $tp -BinaryEncoded `
  -Password (Read-Host "Set a PFX password" -AsSecureString)
[System.IO.File]::WriteAllBytes('C:\certs\mail-contoso.pfx', $pfx.FileData)

# On every other Exchange server
Import-ExchangeCertificate -Server EX02 `
  -FileData ([System.IO.File]::ReadAllBytes('\\fs01\certs\mail-contoso.pfx')) `
  -Password (Read-Host "PFX password" -AsSecureString)

Enable-ExchangeCertificate -Server EX02 -Thumbprint $tp -Services IIS,SMTP

Delete the PFX from the file share afterwards. A file holding an exportable private key protected by a password someone typed into a chat window is a certificate you should treat as compromised the next time you audit anything.

Can you use an ECC certificate?

Only with preparation, and most deployments should not bother. Exchange rejected elliptic-curve certificates outright until the April 2024 hotfix updates added support for Exchange 2016 and 2019, with more scenarios covered by the November 2024 security update. Support is off by default and has to be switched on with a registry value on every Exchange server in the organization.

# Run on every Exchange server; can take up to 15 minutes to take effect
New-ItemProperty `
  -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" `
  -Name "EnableEccCertificateSupport" -Value 1 -Type String

Exceptions remain even with the switch on. The Federation Trust certificate and the Exchange OAuth certificate must stay RSA, and ECC cannot be used where AD FS claims-based authentication is configured. Request RSA 2048 for the mail certificate unless you have a specific reason not to, and read the comparison of ECC and RSA before deciding the reason is performance.

Verifying it is actually being served

Check three things, in this order: that Exchange records the binding, that the server presents the certificate on the wire, and that the chain is complete from outside your network. The first two can pass while the third fails, which is exactly the case that reaches you as a user complaint rather than as an alert.

# 1 — what Exchange thinks is bound, on every server
Get-ExchangeCertificate -Server EX01 |
  Format-Table Thumbprint,Services,NotAfter,Subject -AutoSize

# 2 — what the server actually presents on 443 and on 25
openssl s_client -connect mail.contoso.com:443 -servername mail.contoso.com </dev/null
openssl s_client -starttls smtp -connect mail.contoso.com:25 </dev/null

# 3 — from Windows, without openssl
Test-NetConnection mail.contoso.com -Port 443
Invoke-WebRequest https://mail.contoso.com/owa -UseBasicParsing | Select-Object StatusCode

For the outside view, our free SSL checker reads the chain the way a client on the public internet does and names the intermediate if one is missing. Test the Autodiscover name as well as the mail name; they are separate DNS records and only one of them is the name you have been staring at all morning.

Worth keeping next to the runbook: three of these four are binding or URL problems that no amount of reissuing the certificate will solve.

Renewal at 200-day lifetimes

A renewal repeats four steps: import the new certificate, enable the same services on it, update any connector that names it, and restart IIS. None of it is automatic on an on-premises Exchange server. At the 200-day ceiling in force since March 2026 that runs twice a year, and the CA/Browser Forum schedule takes it to roughly quarterly in March 2027.

The argument for scripting the import-and-enable sequence is not elegance. It is that the sequence now runs twice a year and will run eight times a year inside this decade.

Generate a fresh key pair each time rather than reusing the old CSR. It costs one extra command and it means a key that has been sitting on a mail server for years does not carry forward into the next certificate. Set a calendar reminder for 30 days before expiry, not 7: organization validation can take several days, and that is a poor week to discover the company registration details on file are out of date.

What the shortening schedule means for everything else you run is covered in preparing for 47-day certificates, and the reasoning behind the change in the 2026 lifetime changes.

Failures and what they mean

Most Exchange certificate failures are binding problems or name problems wearing a certificate costume. Before reissuing anything, confirm what is bound and what name the client is reaching. The table below covers what actually comes up.

What you see	What is usually behind it
Services column stays empty after import	The enable step has not run, or it ran against a different server. Bindings are per server.
Outlook on the web still shows the old certificate	IIS has not been restarted since the binding changed. Restart W3SVC and WAS.
Name mismatch naming your internal server	A virtual directory InternalUrl or the Autodiscover service URI still publishes the Active Directory name.
Import fails with a private key error	The request was generated on a different server, so no matching key exists here. Import a PFX instead.
Mail to a partner queues after renewal	A send connector still carries the previous TlsCertificateName string.
Chain error on phones, fine on desktops	The intermediate is missing from the server store; desktops cached it earlier.
The certificate is simply not accepted	It is an ECC certificate and the registry switch has not been set on this server.

For errors that are not Exchange-specific, the meaning of each browser and client message is collected in what each SSL certificate error means.

Frequently Asked Questions

Get instant answers to common questions about SSL certificates and our services.

Still Have Questions?

Our SSL experts are available 24/7 to help with any questions about certificates, installation, or technical issues.

Getting the certificate itself

Exchange needs a publicly trusted certificate carrying at least your mail name and your Autodiscover name, which makes it a multi-domain request rather than a single-name one. A multi-domain SSL certificate from My-SSL puts every name you listed above on one certificate with one expiry date to track. My-SSL is a Certum partner, so the certificates chain to roots that have been in the Windows trust store for years, which is the property the older mail systems on the far side of an SMTP connection depend on.

How to Install an SSL Certificate on Exchange Server