Key takeaway: An internal PKI is a good fit for on-premises Exchange when every client that connects is under your control. The moment Exchange Online is involved, anything Microsoft 365 or the public internet has to validate needs a certificate from a publicly trusted CA, because Microsoft 365 cannot be told to trust your private root. In a hybrid environment, the usual answer is both: public certificates where the outside world connects, internal PKI for everything else.
In This Article
- Public or Internal: Who Has to Trust the Certificate
- Prerequisites
- Plan the Names
- Step 1: Create a Template on the Issuing CA
- Step 2: Generate the Request from Exchange
- Step 3: Issue the Certificate
- Step 4: Import and Assign It
- Step 5: Point the URLs at the New Names
- Step 6: Verify
- When You Also Have Exchange Online
- After You Finish Moving to Exchange Online
- Troubleshooting
- Checklist
This is Part 2 of a two-part guide. Part 1 built the offline root CA and an issuing CA beneath it. This part uses that hierarchy for Exchange Server and covers what changes in a hybrid deployment with Exchange Online. The Exchange commands apply to Exchange Server Subscription Edition and 2019. Exchange 2016 and 2019 passed end of support in October 2025, so plan on Subscription Edition for anything you keep.
Public or Internal: Who Has to Trust the Certificate
The question is not "which CA is better." It is "who has to validate this certificate, and can I control what they trust?"
| Connection | Who validates the certificate | Internal PKI okay? |
|---|---|---|
| Domain-joined Outlook on the corporate network | Your own machines, which trust your root through Group Policy | Yes |
| Server-to-server inside your network (Exchange to Exchange, load balancer to Exchange) | Your own servers | Yes |
| Internal applications relaying through Exchange SMTP | Your own applications | Yes |
| Outlook, OWA, and mobile devices used from home or on personal devices | Devices you do not manage | No. Use a public certificate |
| Autodiscover and EWS requests from the internet | Any client | No. Use a public certificate |
| Hybrid mail flow with Exchange Online (connectors using TLS) | Microsoft 365 | No. Use a public certificate |
| Hybrid free/busy and other EWS calls from Exchange Online | Microsoft 365 | No. Use a public certificate |
| Mail with other organizations over TLS | Other organizations' servers | No. Use a public certificate |
| The Exchange Auth certificate (OAuth signing) | Not a TLS certificate | Leave it as is. See the note in the hybrid section below |
A related point: public CAs stopped issuing certificates for internal-only names (such as server01.corp.local) years ago. If you need a trusted certificate for an internal name, the internal PKI is the only way to get one.
Prerequisites
- An issuing CA from Part 1 that is running, with the root and issuing CA certificates published at working HTTP URLs, and a current root CRL. If clients cannot reach the CRL, certificates will fail with "revocation server offline" errors.
- The root and issuing CA certificates distributed to clients. For domain-joined Windows machines, use Group Policy: Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies. Put the root in *Trusted Root Certification Authorities* and the issuing CA in *Intermediate Certification Authorities*. An enterprise CA also publishes into Active Directory automatically.
- A plan for devices that are not domain-joined. Windows PCs, Macs, iPhones, and Android devices that connect internally need the root installed through your MDM (Intune, Jamf) or by hand. Verify the thumbprint against the one you recorded in Part 1.
- The list of names Exchange must answer to. Decide this before requesting anything, because changing it means a new certificate.
Plan the Names
Keep the list short and use the same names inside and out ("split DNS"):
- The client namespace, for example
mail.contoso.com autodiscover.contoso.com- Any additional legacy or internal names that clients still use
The server FQDNs (ex01.corp.contoso.com) do not need to be in the certificate for clients. Include them only if something connects to servers by their own names.
Step 1: Create a Template on the Issuing CA
- On the issuing CA, open Certificate Templates and duplicate the Web Server template. Name it
Exchange Server. - Compatibility: Windows Server 2012 R2 or later for the CA and the recipient.
- Request Handling: allow the private key to be exported (useful when you move the certificate between servers).
- Subject Name: *Supply in the request*. Exchange builds the request, so it supplies the names.
- Extensions: Server Authentication.
- Security: grant *Read* and *Enroll* to the admin account or group that will submit requests.
- Publish it: in the Certification Authority console, right-click *Certificate Templates*, choose *New*, then *Certificate Template to Issue*, and select it.
Step 2: Generate the Request from Exchange
Run this in the Exchange Management Shell on the server that will hold the certificate:
$req = New-ExchangeCertificate -GenerateRequest `
-SubjectName "CN=mail.contoso.com, O=Contoso, C=US" `
-DomainName mail.contoso.com, autodiscover.contoso.com `
-KeySize 2048 `
-PrivateKeyExportable $true
Set-Content -Path C:\certs\mail.req -Value $reqStep 3: Issue the Certificate
From a machine with access to the issuing CA:
certreq -submit -config "ISSUINGCA01.corp.contoso.com\Contoso Issuing CA 01" `
-attrib "CertificateTemplate:ExchangeServer" `
C:\certs\mail.req C:\certs\mail.cerThe template name here is the *internal* name, which has no spaces. If the CA requires approval, issue the pending request in the console first, then retrieve the certificate with certreq -retrieve.
Step 4: Import and Assign It
Import-ExchangeCertificate -Server EX01 `
-FileData ([System.IO.File]::ReadAllBytes("C:\certs\mail.cer")) `
-PrivateKeyExportable $true
Get-ExchangeCertificate -Server EX01 | Format-List Thumbprint, Subject, CertificateDomains, Services, NotAfter
Enable-ExchangeCertificate -Server EX01 -Thumbprint <thumbprint> -Services IIS, SMTP -ForceAssigning the certificate to IIS covers Outlook, OWA, ECP, EWS, ActiveSync, MAPI, and Autodiscover. Assigning SMTP makes the transport service present it on mail connections. With several servers behind a load balancer, export the certificate once with Export-ExchangeCertificate (as a password-protected PFX) and import the same certificate on each server, so clients see an identical certificate whichever server answers.
Do not touch the *Microsoft Exchange Server Auth Certificate*. It is a separate certificate used for OAuth tokens, not TLS.
Step 5: Point the URLs at the New Names
Clients find Exchange through the virtual directory URLs and the Autodiscover service connection point (SCP). If those still contain the old server names, clients will see certificate name mismatches.
$ns = "mail.contoso.com"
Get-OwaVirtualDirectory -Server EX01 | Set-OwaVirtualDirectory -InternalUrl "https://$ns/owa" -ExternalUrl "https://$ns/owa"
Get-EcpVirtualDirectory -Server EX01 | Set-EcpVirtualDirectory -InternalUrl "https://$ns/ecp" -ExternalUrl "https://$ns/ecp"
Get-WebServicesVirtualDirectory -Server EX01 | Set-WebServicesVirtualDirectory -InternalUrl "https://$ns/EWS/Exchange.asmx" -ExternalUrl "https://$ns/EWS/Exchange.asmx"
Get-ActiveSyncVirtualDirectory -Server EX01 | Set-ActiveSyncVirtualDirectory -InternalUrl "https://$ns/Microsoft-Server-ActiveSync" -ExternalUrl "https://$ns/Microsoft-Server-ActiveSync"
Get-OabVirtualDirectory -Server EX01 | Set-OabVirtualDirectory -InternalUrl "https://$ns/OAB" -ExternalUrl "https://$ns/OAB"
Get-MapiVirtualDirectory -Server EX01 | Set-MapiVirtualDirectory -InternalUrl "https://$ns/mapi" -ExternalUrl "https://$ns/mapi"
Set-ClientAccessService -Identity EX01 -AutoDiscoverServiceInternalUri "https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml"Make sure internal DNS resolves mail.contoso.com and autodiscover.contoso.com to Exchange (or its load balancer), and run iisreset or recycle the application pools if you want the changes visible immediately.
Step 6: Verify
- From a domain-joined PC, browse to
https://mail.contoso.com/owa. There should be no warning, and the certificate chain should show your root, the issuing CA, and the server certificate. - Open Outlook and confirm it does not prompt about certificates. Use *Ctrl + right-click* the Outlook tray icon and choose *Test E-mail AutoConfiguration* to see which URLs it uses.
- Check revocation reachability from a client:
certutil -URL C:\certs\mail.cer. All the AIA and CDP entries should show as verified. - Test an iPhone or Mac that is not domain-joined. If it warns, it does not have your root installed, which is exactly the gap this step is meant to find.
- Check the SMTP certificate:
openssl s_client -connect ex01.corp.contoso.com:25 -starttls smtp.
When You Also Have Exchange Online
In a hybrid deployment, Exchange Online and your on-premises servers talk to each other over the internet. Microsoft 365 validates your certificate the way any internet server would: it checks the chain against the public trust stores it knows. It has no setting for adding your private root.
That means:
- Hybrid mail flow. The connectors between Exchange Online and on-premises use TLS, and the certificate on the on-premises side must be issued by a publicly trusted CA, with the connector's certificate name matching one of its names.
- Free/busy, mailbox moves, and other EWS traffic. These reach your Autodiscover and EWS endpoints from Microsoft 365, so those endpoints need a public certificate too.
- The Hybrid Configuration Wizard checks the certificate on the hybrid namespace and will not complete cleanly with an untrusted one. If you use the Hybrid Agent, EWS and Autodiscover traffic is relayed through it rather than inbound directly, but mail flow still needs a publicly trusted certificate.
- The Exchange Auth certificate is what signs OAuth tokens between the two environments. It is self-signed by default and that is fine. Do not replace it with an internal CA certificate as part of this project; if it nears expiry, follow Microsoft's renewal steps.
### Three Patterns That Work
| Pattern | How it works | Best when |
|---|---|---|
| A: One public certificate everywhere | A public certificate for mail, autodiscover, and the hybrid names, assigned to IIS and SMTP on the Exchange servers. Internal PKI is not used for Exchange | Small environments. Simple, and every client trusts it with no GPO work |
| B: Public at the edge, internal behind it | A reverse proxy, WAF, or load balancer presents the public certificate to the internet and re-encrypts to Exchange using an internal CA certificate | You already have an edge device and want public names kept off the Exchange servers |
| C: Split namespaces | Public certificate on the external and hybrid names. Internal-only names use the internal PKI | Mixed environments where internal clients use a different name from internet clients |
Pattern B is the cleanest use of the internal PKI you built in Part 1. Inside the network, certificates are issued and renewed by your own CA at no per-certificate cost. At the edge, you buy one public certificate.
### Public Certificates Are Getting Shorter-Lived
Under the CA/Browser Forum schedule, publicly trusted TLS certificates are limited to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Exchange has no built-in renewal for third-party certificates, so plan to automate the request, import, and assignment steps above, or move the public certificate to an edge device that can renew itself. Certificates from your internal CA are not subject to those limits, which is one more reason to keep internal-only names on your own PKI.
After You Finish Moving to Exchange Online
When the last mailbox is in Exchange Online, you may keep one on-premises Exchange server for recipient management. That server no longer serves clients or mail from the internet, so it can use a certificate from your internal CA, or even its self-signed certificate. Public certificates for mail and autodiscover can be retired once the DNS records point to Microsoft 365. Remove them after you have confirmed no clients still use the old names.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Outlook inside the network shows a certificate warning | The SCP or a virtual directory still has the old server name, or the issuing CA is missing from clients' Intermediate store |
| "The revocation server is offline" or similar | The CRL URL in the certificate is unreachable, or the offline root's CRL has expired (see Part 1, Step 9) |
| iPhones and Macs warn but domain PCs do not | The root certificate was never installed on those devices |
| Hybrid mail from Exchange Online fails with a TLS or certificate error | The on-premises connector is presenting an internal certificate, or the name on it does not match the connector's certificate name |
| Hybrid Configuration Wizard fails on the certificate step | The certificate on the hybrid namespace is not from a publicly trusted CA |
| Browser warns about a name mismatch | The name used is not in the certificate's subject alternative names |
| New certificate imported but old one still presented | The new certificate was imported but not assigned to the IIS and SMTP services |
Checklist
- [ ] Root and issuing CA certificates distributed to every client that must trust them
- [ ] Root CRL and issuing CA CRL reachable over HTTP and not near expiry
- [ ] Certificate request created on Exchange, issued from the
Exchange Servertemplate, imported, and assigned to IIS and SMTP - [ ] Virtual directory URLs and the Autodiscover SCP updated to the certificate's names
- [ ] Non-domain devices tested
- [ ] Hybrid namespaces (if any) covered by a public certificate, with a renewal process in place
- [ ] Exchange Auth certificate left alone
- [ ] Certificate and CRL expiry dates added to the team calendar
If you would like help designing a PKI, tightening an existing one, or untangling certificates in a hybrid Exchange environment, get in touch.