Outlook web, S/MIME, and CRLs, oh my!

Decorative image - Outlook logo, clip art padlock with encryption feel, and clip art list representing a certificate revocation list

All product names, logos, and brands used in this post are property of their respective owners.

I am a huge proponent of Microsoft 365 Message Encryption (Information Rights Management) for email encryption in M365 (specifically Outlook and Exchange Online). But alas, some situations require the older and heavier S/MIME (Secure/Multipurpose internet Mail Extensions) style of email encryption. Luckily, Microsoft supports both, although the latter requires more overhead to configure and maintain.

In this post, I will highlight a specific and poorly documented error and resolution if you plan to use S/MIME in Outlook on the web with an on-premises Microsoft Certificate Authority (CA, aka PKI deployment) underpinned by Active Directory Certificate Services. In the interest of brevity, the following assumptions apply:

The S/MIME control for Outlook on the web is essentially a bridge between your device’s local certificate store (technically, your account’s certificate store - My) and Outlook on the web. As long as your S/MIME certificates exist in the certificate store, the control allows the Outlook web app to access and use them.

If you followed the instructions to a T and S/MIME should be working in Outlook on the web, but you receive the following instead, the guidance in this post may apply.

Screenshot of email message with S/MIME encryption or signing enabled and the “The digital signature on this message isn’t valid or trusted. For more information, click here” error message

Message: The digital signature on this message isn’t valid or trusted. For more information, click here

More information: The online certificate revocation list (CRL) that the certificate chain relies on is currently offline.

In my case, the issue stemmed from the Microsoft CA being internal and not internet-facing. In my experience and opinion, it is uncommon and unwise to deploy Active Directory Certificate Services public facing. For Outlook on the web to validate your S/MIME certificate(s), one of the Certificate Revocation List (CRL) locations referenced in the CRL Distribution Points field must be publicly accessible.

Redacted screenshot of an S/MIME certificate from the Windows certificate store, highlighting the CRL Distribution Points field and locations it contains

Again, DO NOT make your Microsoft PKI infrastructure public-facing! Instead, consider one of the following to address the issue:

  • Publish only your CRLs (from C:\Windows\system32\CertSrv\CertEnroll, assuming default settings) publicly via https, using a different web server (or CDN) than where AD CS runs
  • Update Active Directory Certificate Services to automatically publish CRLs to a different (web) server, and re-issue your S/MIME certificates (so they include the new https location value in CRL Distribution Points)

For me, the former was the path of less resistance. I used Azure Storage and Azure CDN (with a custom domain, matching one of the http(s) endpoint names already specified in ADCS), to publish only the CRLs in an internet-accessible fashion. I kept things in sync with the Azure CLI (syncing changes to the CRLs in the storage account as they occured in AD CS).

I hope this helps someone in a similar situation.