How to Use an Internal PKI Certificate with Exchange Server, and What Changes in Hybrid with Exchange Online (Part 2 of 2)

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

1. On the issuing CA, open Certificate Templates and duplicate the Web Server template. Name it Exchange Server.
2. Compatibility: Windows Server 2012 R2 or later for the CA and the recipient.
3. Request Handling: allow the private key to be exported (useful when you move the certificate between servers).
4. Subject Name: *Supply in the request*. Exchange builds the request, so it supplies the names.
5. Extensions: Server Authentication.
6. Security: grant *Read* and *Enroll* to the admin account or group that will submit requests.
7. 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:

Step 3: Issue the Certificate

From a machine with access to the issuing CA:

The 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

Assigning 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.

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 Server template, 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.