Let’s say that you have an Office 365 tenant, and that you also deployed a set of Federated Identities with Windows Active Directory Federation Services (ADFS). It could happen that you log into the Admin portal of your Office 365 tenant and you see the following polite message.

Let me repeat the text to help people find this content, via web search, in case of need: “Renew your Certificates – One of your on-premises Federation Service certificates is expiring. Failure to renew the certificate and update trust properties within X days will result in a loss of access to all Office 365 services for all users.” Wow! That’s a very clear message, but very scaring, as well. What’s happening?!

Well, from an ADFS perspective you will have at least three certificates to support the security of your own environment:

• The “Service Communications” certificate, which will be used to protect the HTTPS endpoint
• The “Token-decrypting” certificates, which will be used to decrypt security tokens
• The “Token-signing” certificates, which will be used to sign security tokens

The first one is used to secure the HTTPS endpoint, and when it expires you simply need to renew it and replace it in your ADFS and in your reverse proxies, as well and if any.

Meanwhile in your environment, which is federated with Azure Active Directory, the last two certificates are used to secure the security token exchange with Azure AD, which sits under the cover of your Office 365 tenant.

The kind message you get in the Office 365 Admin center simply states that one or both of these certificates are going to expire and, if you will not replace them promptly, nobody will be able to consume your services after the effective expiration of those certificates. Luckily you also have the “Update Now” link, at the very end of the alert. If you click on it you will be redirected to a Wiki page (created on March 2011 and updated on February 2015), which mainly targets ADFS 2.0 on Windows Server 2012. Now, my personal suggestion is to leverage Windows Server 2012 R2 and ADFS 3.0 for federating identities with Azure AD and Office 365, if it is possible.

Well, using ADFS 2.0 or ADFS 3.0 the solution to the problem is almost automatic, if you enable the AutoCertificateRollover capability. Let’s see.

Connect to your ADFS server and open PowerShell console or PowerShell ISE. Run the Get-AdfsProperties cmdlet and watch the output:

You will find some interesting properties like:

• AutoCertificateRollover (default value TRUE): determines if the ADFS service will automatically manage the enrollment of new certificates before expiration of current ones.
• CertificateCriticalThreshold (default value 2): is the number of days, before the current certificates expiration, that will determine a critical self-enrollment of new certificates to replace the current ones, which are going to expire. It shouldn’t happen if the auto certificate rollover procedure works properly.
• CertificateDuration (default value 365): defines the duration in days of the enrolled certificates.
• CertificateGenerationThreshold (default value 20): is the number of days, before the current certificates expiration, that will determine when the certificate auto-rollover procedure will be executed. That procedure will generate new certificates that will soon replace the current ones. Initially the new auto-generated certificates will be “Secondary,” and the current certificates will keep their status of “Primary” certificates.
• CertificatePromotionThreshold (default value 5): defines the number of days during which the new certificates will be “Secondary.” After that, there will be a switch between the certificates: the expiring ones will become “Secondary”, while the new ones will become “Primary.”

More details about these ADFS properties, and some others, can be found here.

In the demo environment that I am showing you I had the expiration date for my encrypting and signing certificates set on March 27th 2015, as you can see in the following figure.

Well, on March 7th 2015, which is exactly 20 days (= CertificateGenerationThreshold) before certificates expiration, ADFS 3.0 automatically generated a couple of new certificates for encrypting and signing. Moreover, ADFS 3.0 set those new certificates as “Secondary.” Here you can see.

This way, the Azure AD engine is able to retrieve the information about these two new certificates within the next 5 days (= CertificatePromotionThreshold). In fact, on March 10th 2015 the polite alert disappeared from my tenant Admin center, as you can see in the following figure.

Lastly, on March 13th 2015 (i.e. today), the ADFS 3.0 engine switched the “Primary” and the “Secondary” certificates, in order to promote the new ones and demote the expiring ones. Here is the result in the ADFS administration console.

And you are done! Your ADFS certificates are updated, the Azure AD tenant is aware of the new certificates, and for the next 365 days (= CertificateDuration) – after the creation date of the new certificates – you don’t need to care about certificates expiration. Your users can continue consuming their services without any service interruption.

When the Secondary (old and expiring) certificate will effectively expire, ADFS will automatically remove it from the list of available certificates, and only the Primary and valid (not expired) one will survive.