It should come as no surprise that Office 365, being a secure service, has a number of SSL certificates in play. Some are owned and managed by Microsoft and some, depending on your on-premises components, are certificates that you are responsible for maintaining.
Failure to keep track of these certificates could result in an interruption of services.
Below are the various certificates that you should be aware of and how to manage them.
Active Directory Federation Services (AD FS)
If you use AD FS for authentication, there are two certificates that you need to be aware of:
Service Communications Certificate
You are likely aware of the SSL certificate that you purchased and assigned to your AD FS farm for authentication. This certificate, the “Service Communications” certificate, is installed on each internal AD FS server and each AD FS proxy server. The name on this certificate will be whatever you named your federation service (e.g. “sts.company.com”); if you’re using “Workplace Join” or “Azure Device Registration”, you will also have “enterpriseregistration.company.com” as a SAN on the certificate.
When your Service Communications certificate expires, you can use the following to renew it:
When renewing this certificate, if you’re currently using a SHA-1 certificate, you’ll want to switch to SHA-2. To generate a SHA-2 CSR on Windows Server 2012 R2 (AD FS 3.0), you can use this process: Office 365 – How to Request a SHA-2 Certificate in AD FS 3.0
Token-Signing & Decryption/Encryption
By default, AD FS uses a self-signed certificate for token-signing and token-decryption/encryption. This certificate has a default expiration of 1-year but can easily be extended and I generally recommend doing so. While the certificate will automatically renew, the trust with Office 365 will need to be updated; failure to update the trust will result in an inability to authenticate to Office 365 via AD FS. Microsoft will provide alerts in the tenant regarding an upcoming certificate expiration however you should proactively be aware of the expiration and plan for it.
To extend the expiration of the self-signed certificate, you can use the following commands on the primary AD FS server using the AD FS and Azure AD PowerShell module:
Set-AdfsProperties -CertificateDuration 1095 Update-AdfsCertificate –Urgent Connect-MsolService Update-MSOLFederatedDomain -DomainName: company.com -SupportMultiDomain
Unleash the Potential of Power Platform With a Center of Excellence
Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.
The above will set the certificate to expire 1,095 days from now. You may want to consider aligning this with the expiration of your Service Communications certificate so the renewal is a coordinated event. You could also extend this out 5+ years if you’re comfortable with that; odds are you will have upgraded your AD FS by then.
When the expiration is coming up, you’ll start seeing a warning within the tenant. A new self-signed certificate will be generated 20 days prior to the expiration of the current one. Once that occurs, you will want to run the same commands as above to update Office 365.
If you’re running in an Exchange Hybrid configuration, you have a couple of areas to watch out for:
When you ran the Hybrid Configuration Wizard, a trust was setup with the Microsoft Federation Gateway so that you can establish an Organization Relationship between your on-premises Exchange and Exchange Online. This is the component that allows for you to share free/busy information between on-premises and the cloud (or with other organizations). When that trust was created, a self-signed certificate was generated with a 5-year expiration. While this certificate is fairly “self-maintaining”, problems can arise with it at times.
Occasionally I’ve seen where this certificate is not replicated throughout your environment, resulting in intermittent free/busy issues.
Additionally, you may run across a situation where the certificate or metadata has an issue. You can easily resolve this with the following command:
Get-FederationTrust | Set-FederationTrust –RefreshMetadata
Microsoft even recommends running this as a scheduled task in Exchange 2010 environments: Keep Your Federation Trust Up-To-Date
In an Exchange 2013 environment, OAuth may have been configured between your on-premises Exchange and Office 365 depending on when you ran the Hybrid Configuration Wizard. This configuration uses a certificate with a 5-year expiration.
You can see the certificate in use with the following:
(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | FL
While there are manual instructions for configuring OAuth (Configure OAuth authentication between Exchange and Exchange Online organizations), I would recommend using the Hybrid Configuration Wizard to handle this renewal.
The certificate installed on your on-premises Client Access Servers is still used by your Office 365 users. Your Autodiscover record will still be pointing to your on-premises Exchange and the EWS endpoint used for free/busy lookups will also be used. Assuming you’ve been running Exchange on-premises for any length of time, you’re familiar with the process of maintaining this certificate. If you deployed dedicated servers for the purpose of remote mailbox moves or for your hybrid implementation and those servers have a separate certificate and expiration, you’ll want to take note of that certificate.
The one configuration item that is sometimes overlooked is when you’re running Exchange hybrid with Exchange 2013. The send/receive connectors between your on-premises Exchange and Exchange Online include details of your SSL certificate and will require updating when you renew that certificate.
You will see the certificate “Issuer” and “Subject” in these three places:
- “TlsCertificateName” field in your on-premises “Default Frontend” receive connectors
- “TlsCertificateName” field in your on-premises “Outbound to Office 365” send connector
- “TlsSenderCertificateName” in your Inbound connector in your tenant
While you could use the Hybrid Configuration Wizard to update these values, you can also generate the appropriate string and populate them via PowerShell.
If you’re using Exchange Edge Transport servers, don’t forget about those servers.
Office 365 Mobile Device Management (MDM) / Intune
If you’ve setup Office 365 MDM or Microsoft Intune and have any iOS devices, you should have configured the Apple Push Notification Service (APNS). During that configuration, you acquired an APNS certificate from Apple and that certificate has an expiration of one year.
You need to proactively renew this certificate before it expires or you will need to enroll your devices again. While you may receive an email from Apple about the upcoming expiration, this is definitely one to keep track of.
All in one spot, here’s what you should have marked in your calendar:
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.