If you handle any kind of confidential material on your work email (most of us do), encrypted email is a must to ensure confidentiality and security of the material being moved around.
Warning: This is a long text post with lots of tech details. No pretty diagrams this time.
Other than the proprietary solutions for intra-company encryption, there are only a few “open standards” that two random organizations can use to exchange encrypted emails. S/MIME being one of the popular ones, if your organization already uses appropriate certificates for user authentication (Wifi, 802.1x, disk encryption, etc.), enabling email encryption could be a simple matter of configuring email client to use that cert for S/MIME email encryption.
Assuming all that is setup, an email sender still needs the intended recipient’s “public key” before an encrypted email can be sent. That can be exchanged manually using “signed emails” between two users but is a headache for more frequent certificate exchanges.
That is where enterprise directories like “Active Directory” can help. Microsoft exchange being one of the most popular email infrastructure choices, it is easy to publish all user certificates to the corporate directory. That way any MS Exchange compatible client can lookup recipient certs while composing an email.
Microsoft exchange can be accessed using a variety of client protocols. Most of those protocols expose similar interfaces and provide almost the same functionality from an email client’s perspective. The difference is in the transport protocol structure in use. These client protocols also provide the ability for the email client to “request recipient’s email certificate” on the fly.
So, publish each user’s cert with Active Directory / Exchange and the problem is solved, right? Not quite so.
For Microsoft’s own email client options – Outlook, etc. that use EWS to talk to Exchange CAS – Client Access Server, the cert lookup process works fine. Microsoft even has an IE ActiveX plugin to enable S/MIME on “Outlook Web Access”.
The problem currently exists with clients that use the Microsoft ActiveSync protocol to access Exchange services. If you configure Apple iPhone or Android Touchdown apps for Exchange, they use ActiveSync instead of EWS. ActiveSync protocol provides API calls (ResolveRecipients) to fetch a recipient’s email certificate. But when the client makes that call, the CAS ActiveSync process is unable to fetch the cert and returns a negative response.
We first came across this issue several years ago and after extensive online search and forum posts, concluded (like others) that this was an Apple iPhone Mail issue and kept cursing Apple for it. We also kept testing it with every IOS release with no success. The logic there was that if the fetch worked for EWS clients, ActiveSync should have the same result as it is the same CAS server.
But that was an incorrect assumption. Well, the issues are specific to each client. After hours of debugging, educating (yes) MS support engineers on S/MIME, here is the current summary –
For ActiveSync Clients (Apple iPhone Mail / Android Touchdown) –
The issue is with Microsoft ActiveSync Server – documented here.
Client Cert Request to CAS
<?xml version="1.0" encoding="utf-8" ?>
CAS (ActiveSync) Response to Cert Lookup Request
<?xml version="1.0" encoding="utf-8" ?>
For Apple Mail – OSX (uses EWS)
The problem is with Apple mail trying to use Keychain to lookup certs instead of EWS protocol. Keychain lookup does not work for OSX versions before El Capitan. Works on El Capitan only if the machine is joined to the windows domain and directory lookup is enabled on Keychain. This is not a practical solution if the OSX client is roaming outside corporate network with no LDAP access to the GAL / domain controllers to do a cert lookup query.
Outlook Mac 2016 (Latest version)
S/MIME cert lookups stopped working from version 15.11. Anything between 15.3 and 15.10 still work. This is a known issue with MS dev teams with no specific fix date.