How to Install an SSL Certificate on Office 365

This tutorial explains how to install an SSL certificate for Microsoft 365 (Office 365). The important part comes first: you do not, and cannot, upload an SSL certificate into the Microsoft 365 cloud itself. Microsoft manages TLS for Exchange Online, SharePoint Online, and the other hosted services. You manage commercial certificates only on the servers, apps, and gateways that connect to or run alongside Microsoft 365. The sections below cover the three scenarios where that actually applies.

Generate a CSR code

A CSR (Certificate Signing Request) is a block of encoded text containing your contact and domain details that you submit to the Certificate Authority during enrollment. You only need a CSR for the scenarios where you install your own certificate (Exchange Server or Azure). For an Exchange Online forced-TLS connector you do not generate a CSR, because no certificate is uploaded on your side.

You have two options:

• Generate the CSR automatically with our CSR Generator.
• Follow our step-by-step guide on how to create a CSR for Microsoft 365.

Submit the CSR to the Certificate Authority during your order. After the CA validates it and issues your certificate (typically as a .pfx bundle that includes the private key and chain), continue with the matching section below.

Install an SSL certificate for Microsoft 365

Important: you do not install an SSL certificate into Microsoft 365 cloud services such as Exchange Online or SharePoint Online. Microsoft handles TLS for those services automatically, and the cloud does not allow manual certificate uploads. You install and manage certificates only on your own servers, apps, or gateways that connect to or work alongside Microsoft 365.

This guide covers the three common use cases for a commercial certificate in a Microsoft 365 environment:

• Exchange Online with enforced SSL/TLS (connector, no certificate upload)
• Exchange Server on-premises or in a hybrid setup
• Azure-hosted web apps or services

Use case 1: Exchange Online, enforce SSL/TLS with a partner (no cert upload)

If you use Exchange Online only and want to secure mail flow with a trusted external server (for example a partner organization, a legacy system, or a multifunction printer), you enforce TLS with a connector. You do not upload a certificate. Instead, you require that the other side present a valid, publicly trusted certificate.

Steps to set up forced TLS in Microsoft 365 mail flow

1. Sign in to the Exchange admin center with an account that has mail flow permissions.
2. In the left panel, go to Mail flow and then Connectors.
3. Click Add a connector. For mail from a partner into Microsoft 365, set the connection From: Partner organization and To: Microsoft 365. (For outbound mail to a partner, reverse the direction: From: Microsoft 365 and To: Partner organization.)
4. Click Next and follow the wizard.
5. On the security restrictions step, select Reject email messages if they aren’t sent over TLS to require TLS.
6. To pin the connection to a specific certificate, select And require that the subject name on the certificate that the partner uses to authenticate with Office 365 matches this domain name, then enter the partner domain (for example mail.partnerdomain.com).
7. Finish the wizard and validate the connector.

Note: Microsoft requires you to select at least one restriction on the security step — either the TLS and domain-matching option above, or a restriction based on the partner’s IP address range. The wizard will not let you finish the connector with no restriction selected. Separately, the external server must present a valid public SSL/TLS certificate that Microsoft 365 trusts, meaning one issued by a commercial CA. A self-signed certificate will fail validation.

Use case 2: Exchange Server on-premises, install and assign your certificate

If you run Exchange Server 2016, 2019, or Subscription Edition (SE), or you have a hybrid setup with Microsoft 365, you install your certificate on the on-premises server. In a hybrid configuration the Exchange certificate must be a valid third-party certificate from a trusted CA, otherwise mail flow between on-prem and Exchange Online will break.

Prerequisites

• A .pfx file that contains the certificate, its private key, and the intermediate chain.
• The password for that .pfx file, stored securely.

PowerShell method (Exchange Management Shell)

PowerShell works on every supported Exchange build, which is why it is shown here (see the note after these steps about when the Exchange Admin Center can also do this). Run the Exchange Management Shell as an administrator and replace the file path, password, and thumbprint with your own values.

1. Define the path to your certificate file:

$file = "\\server\share\yourdomain.pfx"

2. Enter the password securely (you will be prompted, and the value is not shown on screen):

$pwd = Read-Host -AsSecureString

3. Import the certificate:

Import-ExchangeCertificate -FileData ([IO.File]::ReadAllBytes($file)) -Password $pwd

4. Find the thumbprint, then assign the certificate to the services that need it:

Get-ExchangeCertificate | FL Thumbprint, Subject
Enable-ExchangeCertificate -Thumbprint <YourThumbprintHere> -Services IIS,SMTP

Assign only the services the certificate is meant for (common values are IIS, SMTP, POP, and IMAP). When prompted to overwrite the default SMTP certificate, confirm only if that is your intent.

Note on the Exchange Admin Center: many guides import certificates through the EAC graphical interface (Servers and then Certificates). Availability depends on your build. Starting with Exchange Server 2019 CU12 and Exchange Server 2016 CU23, Microsoft removed importing, exporting, requesting, completing, and renewing certificates from the EAC for security reasons. Microsoft later restored those tasks to the EAC in Exchange Server 2019 CU15, and they are present in Exchange Server Subscription Edition (SE). So depending on which version you run the EAC wizard may or may not be available, but the PowerShell steps above work on every supported version, which is why they are the method shown here.

Use case 3: Azure App Service, upload and bind your certificate

If you host a website or application on Azure App Service (for example a client portal, an SSO endpoint, or a webhook receiver) that connects to Microsoft 365, you install the certificate in Azure and bind it to your custom domain.

1. Open the Azure portal and go to your App Service.
2. In the left menu, open Certificates (older portals label this TLS/SSL settings).
3. Under Bring your own certificates (.pfx), click Add certificate and upload your .pfx file, then enter its password.
4. Go to Custom domains and select your domain.
5. Under TLS/SSL binding (or SSL Bindings), click Add binding.
6. Choose your uploaded certificate, select SNI SSL for most apps, and confirm the binding.

Azure requires certificates with the Extended Key Usage Server Authentication (OID 1.3.6.1.5.5.7.3.1). Every valid commercial SSL certificate includes this by default.

Notes for admins and developers

• Install certificates only on endpoints you control. The Microsoft 365 cloud does not allow manual certificate installation.
• Every certificate must come from a public, trusted Certificate Authority. Self-signed certificates fail in these scenarios.
• Use a .pfx file for Windows, IIS, Exchange, and Azure rather than importing a bare .crt or .pem, because the .pfx carries the private key and chain together.
• Include the full chain (intermediate and, where required, root) in the .pfx so clients can build a complete trust path.

Test your SSL installation

After you install the certificate on your Exchange Server or Azure app, open the relevant URL in a browser and check the padlock and certificate details. Even when everything looks correct, run a full scan to catch hidden chain or protocol issues. Our SSL Checker delivers an instant report on the state of your certificate. For mail-related setups, you can also confirm encrypted delivery by reviewing the connector and message trace results in the Exchange admin center.

Frequently asked questions