/
(DC) Unable to decrypt emails sent from MS Outlook 2010

(DC) Unable to decrypt emails sent from MS Outlook 2010

Encrypted email sent from Outlook 2010 cannot be read on other email clients

When you send encrypted email using Microsoft Outlook 2010, it cannot be read by non Outlook email clients such as Mozilla Thunderbird, Microsoft Entourage, Apple Mail, etc.

There is no problem decrypting the email using Microsoft Outlook 2007 or Microsoft Outlook 2010.

This behavior also happens when a simple IMAP account is used in Microsoft Outlook 2010 with default S/MIME settings.

MS KB 2142236 - Unavailable

Many articles that discuss this issue, refer to the following Microsoft Knowledge Base article (https://support.microsoft.com/en-US/help/2142236).  Unfortunately that link no longer works (404 error) and the KB 2142236 can not be found in Microsoft Support websites.  Ignore references to this KB article, it does not exist anymore.  See information below.

 

Table of Contents

 

The Issue

This is a known issue with Microsoft Outlook 2010, but a fix has been provided -- you might want to notify the sender that they need to apply Service Pack 1 (SP1) to Outlook 2010 to prevent further issues.

X.509 certificates have several attributes attached, some of them can be used to identify certificates. One such way is to use the serial number together with the certificate issuer (together, they have to form a unique identifier). For S/MIME encrypted messages, this is called issuerAndSerialNumber. An alternative is the also standardized subjectKeyIdentifier, which "should be" be derived from the public key in some form, but is not specifically defined.

Outlook 2010 (pre-SP1) uses the subjectKeyIdentifier and creates one if no such identifier is provided (from the knowledge base article linked above, highlighting added by me):

The Cryptographic Message Syntax (CMS) is documented in RFC 5652. That specification allows using either the subjectKeyIdentifier or issuerAndSerialNumber as the SignerIdentifier. The release (RTM) version of Outlook 2010 uses subjectKeyIdentifier as the SignerIdentifier, whereas earlier versions use issuerAndSerialNumber. If the subjectKeyIdentifier extension is not defined in the certificate, Outlook 2010 RTM generates one. Some email clients or third-party operating systems are unable to use the Outlook-generated subjectKeyIdentifier. This results in the recipient being unable to decrypt and read the message.

With other words, Microsoft Outlook 2010 pre-SP1 uses a certificate identifier very likely not understood by any other mail application. 

In fact messages that have been encoded incorrectly continue to be a problem even with the latest version of Outlook.

How to Decrypt the Message Anyway

This won't be easy, and involves dropping to the command line. This should work on pretty much all operating systems (Linux, Windows, macOS, any BSD), make sure to have OpenSSL installed. Using OpenSSL, we can enforce decryption using a specific key, ignoring the broken subjectKeyIdentifier.

  1. Save the message to some folder (Thunderbird will save it as an .eml file). I named it mail.eml in all further steps.

  2. Export the private key (open the Preferences, Advanced, Certificates, View Certificates, select the appropriate certificate, Backup, select the same folder as used for the message). Thunderbird will query for a passphrase. You should have another file now with .p12 extension. I named it certificate.p12.

  3. Open a terminal. All further steps will be completed on the command line.

  4. Navigate to the folder using the cd command.

  5. For decrypting the message, we need the private key in the PEM format. To convert the key, run openssl pkcs12 -in certificate.p12 -out privatekey.pem -nodes`. You will be asked for the passphrase you entered in Thunderbird.

  6. Now use the exported key to actually decrypt the message:

    openssl cms -decrypt -in mail.eml -inkey privatekey.pem -out decrypted.txt

    The decrypted message will be stored in the decrypted.txt file.

The message is likely to be encoded as quoted-printable. If you encounter weird character sequences like Gr=FC=DFe and there is a header Content-Transfer-Encoding: quoted-printable included, convert the message to plain text (you need Perl, probably restricted to version 5, and the MIME::QuotedPrint module):

perl -MMIME::QuotedPrint -pe '$_=MIME::QuotedPrint::decode($_);' <decrypted.txt >decoded.txt

The decoded.txt file will finally include the decrypted message. If the encoding of special characters still seems wrong, use the conversion tools of your choice or simply try opening the file in Firefox or another browsers -- usually, they do a great job at fixing messed up encoding.

Putting together a new, unencrypted .eml message requires stripping all Content-* headers and moving any Content-* headers from the decrypted message in this place. More details are out of scope for this tutorial, there are too many different encodings to provide reasonable assistance.

Possible Fix for Outlook 2010

You this solution at your own risk.  This is modification of the application and system using a tool called Registry Editor.  Warning:  Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Outlook 2010 now uses another option, per the Cryptographic Message Syntax (CMS) documented in RFC3852. Outlook 2010 now uses subjectKeyIdentifier as the SignerIdentifier, whereas earlier versions used issuerAndSerialNumber. It seems that some clients may not yet support using subjectKeyIdentifier as the SignerIdentifier, as defined per the RFC. This results in it being unable to decrypt the message.

The recipient should check with their email client vendor to determine if an update to address this issue is available for their email client.

As a workaround, you can use the following registry value to make Outlook 2010 revert to the behavior found in earlier Outlook versions.

HKEY_CURRENT_USER\Software\microsoft\office\14.0\outlook\security
DWORD:  UseIssuerSerialNumber
Value:  1