How to Generate a CSR on Office 365

This guide explains how to generate a CSR (Certificate Signing Request) for Microsoft 365 (Office 365). The honest answer first: you do not generate a CSR for the Microsoft 365 cloud itself. Microsoft 365 is a hosted SaaS platform, so Microsoft owns and manages the TLS certificates on outlook.office365.com, the *.mail.protection.outlook.com mail endpoints, *.sharepoint.com, and the other Microsoft-hosted services. There is no portal page that accepts a customer-supplied certificate for those URLs.

A CSR comes into play only when you also run an on-premises or cloud-hosted server that integrates with Microsoft 365. The CSR is generated on that server, not in the Microsoft 365 admin portal. The sections below cover the scenarios where that actually happens.

Which scenario are you in?

Pick the row that matches what you are actually trying to secure, then jump to the matching section:

What you are trying to secure	Where the CSR is generated	Section
The Microsoft 365 cloud services themselves (Exchange Online, SharePoint Online, Teams, outlook.office365.com)	Nowhere. Microsoft manages those certificates.	Why there is no CSR for the cloud
An on-premises Exchange Server in a hybrid configuration with Exchange Online	On the on-premises Exchange server (PowerShell, or the EAC on supported builds)	Hybrid Exchange CSR
An AD FS server federating sign-in with Microsoft 365 / Entra ID	On the AD FS server (Windows certificate request)	AD FS / Entra federation CSR
An Azure App Service web app, function, or API that connects to Microsoft 365	Generated externally (any tool), then uploaded to Azure	Azure App Service CSR
A standalone Windows web server (IIS) that is not Exchange, but happens to integrate with Microsoft 365 (for example a portal, hook receiver, or relay)	In IIS Manager on that server	Standalone IIS server CSR

Why there is no CSR for the Microsoft 365 cloud

Microsoft 365 is a fully hosted, multi-tenant cloud platform. The TLS certificates for Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, and every other Microsoft-hosted endpoint are issued, deployed, and renewed by Microsoft. There is no admin center page, PowerShell cmdlet, or API that lets a tenant upload a third-party certificate to outlook.office365.com, the *.mail.protection.outlook.com mail flow endpoints, or any other Microsoft-owned hostname. That includes the case where you have added your own vanity domain such as contoso.com: once the domain is verified, Microsoft continues to terminate TLS for the underlying SMTP, IMAP, POP, and HTTPS endpoints, so no CSR is needed on your side.

If your goal is to enforce TLS on mail flow between Microsoft 365 and an external partner, you do that with an Exchange Online connector that requires the partner to present a valid public certificate. No certificate is uploaded on your side. See our Microsoft 365 SSL installation guide for the connector steps.

Generate the CSR for hybrid Exchange (Exchange Server on-premises)

If you have already generated your CSR on your on-premises Exchange server, skip ahead to the Microsoft 365 / Exchange SSL installation guide. Otherwise, this is the most common reason customers ask for a “Microsoft 365 CSR.” In a hybrid deployment, your on-premises Exchange Server (2016, 2019, or Subscription Edition) talks to Exchange Online over OAuth, EWS, and Autodiscover, and those connections must be secured with a publicly trusted certificate. You generate the CSR on the on-premises Exchange server, not on anything in Microsoft 365.

On every supported Exchange build (and as the only supported path on Exchange 2016 CU23+ and Exchange 2019 CU12 to CU14, where Microsoft removed the EAC certificate options), the CSR is generated with PowerShell. Run Exchange Management Shell as administrator on the server that will hold the private key, then run:

New-ExchangeCertificate `
  -GenerateRequest `
  -SubjectName "C=US, S=California, L=San Francisco, O=Example Inc, OU=IT, CN=mail.example.com" `
  -DomainName mail.example.com, autodiscover.example.com `
  -KeySize 2048 `
  -PrivateKeyExportable $true `
  | Set-Content -Path "C:\certs\exchange.req"

Two-step usage (the cmdlet output piped to Set-Content) is required on current builds: security update KB5014278 removed the older -RequestFile and -Path direct outputs from New-ExchangeCertificate on Exchange 2016 CU23 and Exchange 2019 CU12. Edit the values to match your environment:

• C is the two-letter country code (US, GB, DE, and so on).
• S is the full state or province name, not the abbreviation.
• L is the full city or locality.
• O is the legally registered company name.
• OU is the department, often “IT”. Optional.
• CN is the primary fully qualified host name the certificate will secure, for example mail.example.com.
• -DomainName is the comma-separated Subject Alternative Name (SAN) list. For a hybrid deployment, include at least mail.example.com and autodiscover.example.com, plus any additional namespaces you use (OWA, EWS, hybrid hostnames).
• -KeySize 2048 matches CA/Browser Forum baseline requirements. Use 3072 or 4096 only if your security policy mandates it.
• -PrivateKeyExportable $true lets you export the key later for backup or to share with the other nodes in a DAG.

On Exchange Server Subscription Edition and Exchange 2019 CU15, the EAC certificate wizard at Servers > Certificates is available again as an alternative GUI flow. The full step-by-step (PowerShell plus the EAC wizard, with version-by-version notes) is on our companion Microsoft Exchange CSR guide. Use that page for the canonical hybrid-Exchange CSR flow; the same CSR works for the certificate you will assign to the on-prem Exchange services that connect to Microsoft 365.

After the cmdlet runs, open the .req file in Notepad and confirm it looks like a normal PEM block:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC6TCCAdECAQAwgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
...
-----END NEW CERTIFICATE REQUEST-----

Copy the entire block, including the BEGIN and END lines (five hyphens on each side), and paste it into the CSR field of your SSL order. Decode it first with our CSR Decoder to confirm the common name, SANs, and key size before you submit.

Generate the CSR for AD FS / Entra ID federation with Microsoft 365

If you use AD FS (Active Directory Federation Services) to federate sign-in between your on-prem Active Directory and Microsoft Entra ID (formerly Azure AD) for Microsoft 365 single sign-on, the AD FS service needs a publicly trusted TLS certificate for its federation service name (for example sts.example.com). That certificate is bound to the AD FS service and to the optional Web Application Proxy in front of it.

The CSR is generated on the AD FS server (or any Windows server) using the Microsoft Management Console certificate snap-in or PowerShell, then submitted to a public CA. Either generate the CSR with our CSR Generator (then later combine the issued certificate and key into a .pfx), or follow our Windows CSR guide to produce the request on the server itself. The same certificate is then assigned to the AD FS service with Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.

Token-signing and token-decryption certificates inside AD FS are a separate topic. They are usually self-signed and auto-rolled by AD FS itself, so you do not generate a CSR for those.

Generate the CSR for an Azure App Service that integrates with Microsoft 365

If you host a web app, function, or API on Azure App Service that connects to Microsoft 365 (a custom portal, an SSO endpoint, a webhook receiver), you secure its custom domain with a certificate you upload to Azure. Azure App Service does not generate CSRs itself: you generate the request outside of Azure and upload the resulting .pfx.

The simplest path is our CSR Generator: enter your details, download the CSR and the matching private key, submit the CSR to the CA, then combine the issued certificate, intermediates, and private key into a .pfx file (PKCS#12). Upload that .pfx in App Service > Certificates > Bring your own certificates (.pfx) and bind it to your custom domain. If you prefer a fully server-managed flow, generate the CSR on a Windows admin workstation using our Windows CSR guide and export the result to a .pfx before uploading. Azure requires the certificate to include the Extended Key Usage Server Authentication (OID 1.3.6.1.5.5.7.3.1), which every commercial SSL certificate already does.

Generate the CSR on a standalone Windows / IIS server

If “Office 365” in your case actually means “a Windows server running IIS in the same environment as Microsoft 365” (for example a portal, an intranet site, or a non-Exchange relay), then you generate the CSR in IIS Manager on that server. This is the path the original tutorial described. It is the right flow for a generic IIS host, but it does not produce a certificate for the Microsoft 365 cloud, only for whatever IIS-hosted site you are managing.

1. Open Start > Windows Administrative Tools > Internet Information Services (IIS) Manager, or press Win + R, type inetmgr, and press Enter.
2. In the Connections panel on the left, select your server name.
3. In the center pane, double-click Server Certificates.
4. In the Actions panel on the right, click Create Certificate Request.
5. In the Request Certificate wizard, fill in the Distinguished Name Properties fields as follows:
   • Common Name: the fully qualified domain name you want to secure, for example portal.example.com. Do not enter outlook.office365.com or any Microsoft-owned hostname.
   • Organization: the full legal name of your company (for example Example Inc.).
   • Organizational unit: the department, often IT.
   • City/locality: the city where your company is registered (do not abbreviate).
   • State/province: the full state or province name (do not abbreviate).
   • Country/region: the two-letter ISO country code (US, GB, DE, and so on).
6. Click Next.
7. On the Cryptographic Service Provider Properties screen, leave the provider at Microsoft RSA SChannel Cryptographic Provider, set Bit length to 2048 (or 3072 / 4096 if your policy requires), then click Next.
8. Specify a file name for the CSR (for example C:\certs\portal.req) and click Finish.

IIS does not generate Subject Alternative Names through this wizard. For a SAN or multi-domain certificate, generate the CSR with PowerShell using a custom INF file with certreq, or use our CSR Generator and later combine the issued certificate and key into a .pfx for import. For the full IIS-specific flow with screenshots, see our Microsoft IIS CSR guide.

Open the saved .req file in Notepad and copy the full block, including the —–BEGIN NEW CERTIFICATE REQUEST—– and —–END NEW CERTIFICATE REQUEST—– lines, into your CA’s order form.

Verify your CSR before submitting

Before you paste the CSR into the order form, decode it to confirm the details are correct. A typo in the common name, a missing SAN, or a short key length will reject the order or force a reissue later. Paste the CSR into our CSR Decoder to see the common name, full SAN list, organization, country, signature algorithm, and key size.

Once the CA validates the request and issues the certificate, continue with our Microsoft 365 SSL installation guide for the matching install step (hybrid Exchange import, AD FS bind, Azure App Service upload, or IIS bind).