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:
- S/MIME configured and operational in Exchange Online
- S/MIME control and certificates installed and operational in Outlook on the web
- Microsoft CA (AD CS) is internal and not internet-facing
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.
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.
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.