Microsoft Outlook: Emails encrypted with S/MIME cannot be opened. The error message "Your digital ID name cannot be found by the underlying security system" appears.

Assume the following scenario:

• A user receives an e-mail message encrypted with Secure/Multipurpose Internet Mail Extensions (S/MIME).
• The message cannot be opened.
• When opening the message, the following error message is displayed:

Sorry, we're having trouble opening this item. This could be temporary, but if you see it again you might want to restart Outlook. Your digital ID name cannot be found by the underlying security system.

The German-language variant of the error message:

Unfortunately, there is a problem opening this item. This may be temporary. If this error occurs again, you should restart Outlook. The name of your digital ID cannot be found in the underlying security system.

Possible causes

The following causes are possible:

• Inappropriate S/MIME capabilities in the certificate
• Private key not available at the recipient
• Private key not usable at the recipient

Details: Inappropriate S/MIME Capabilities

The error message occurs, if the e-mail is encrypted with AES, but the certificate used has a S/MIME Capabilities Certificate extension with restriction to 3DES has.

Such a case probably occurs when the sender has a certificate of the recipient without S/MIME Capabilities extension and he Outlook from 2016 with hotfix KB4484511 or newer, the recipient in turn uses a (potentially renewed) certificate with the same private key but with the S/MIME Capabilities extension (and restriction to the "legacy" algorithms) has.

Details: Private key not available at recipient

This error message also occurs when you, as the recipient, try to open an encrypted email and you do not have the private key needed to do so.

The latter may occur in particular when,

• if the recipient has an S/MIME certificate but it is not present on the system in question, for example
  • because he is working on a new computer
  • because he works in a terminal session (remote desktop)
  • because the certificate is on a smart card, and this has never been connected to the computer in question
  • because the certificate was originally requested for a different purpose (e.g., participation in public tenders) and has not yet been used in the context of S/MIME.
• if the recipient tries to open a "historical" e-mail message, i.e. a message he received before a new S/MIME certificate was issued to him, and the previous certificate (including private key) does not exist on the system in question.
• if the message was not encrypted at the S/MIME layer for the recipient at all - this can occur, for example, if the sender sends mail to multiple senders and uses an encryption gateway that does not know the recipient's public key. In the article "Microsoft Outlook: Find out recipient certificates for S/MIME encrypted mails" describes how to gain insight into the encryption layer of an email to determine which certificates can be used to decrypt the message.

Please note that some e-mail gateway systems automatically encrypt e-mails for the recipient if the recipient's S/MIME certificate is listed in the common public certification authority provider directories. For example, you can use a Online service of the company Zertificon Insight into these directories can be made.

Details: Private key not usable by recipient

The problem can also occur with the sender when he tries to open an encrypted mail in his "Sent Items" folder and he cannot use his own private key.

It can also happen that a user has the correct certificate in his keystore, but it is not suitable for decrypting a message. This can happen, for example, if the key pair was created using the wrong Cryptographic Service Provider (CSP) or Key Storage Provider (KSP) was generated.

For example, if the key pair was generated by certreq.exe with an INF file, and the INF file does not contain any information about the keystore provider, the Microsoft Base Cryptographic Provider v1.0 is used. This may be used for signing messages but not for decrypting them. Cryptographic Service Providers may also have a restriction on the private key (KeySpec) that it can generally only be used for signing (AT_SIGNATURE but not AT_KEYEXCHANGE), which is also the case if the option is not specified.

How to find out which keystore provider a certificate uses is described in the article "Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)" described.

Solution

Provision/restore the S/MIME certificate

In most cases, the solution is to make the user's S/MIME certificate and private key available on the corresponding computer. For this purpose, in most cases a Private key recovery through a key recovery agent (Key Recovery Agent, KRA).

Reset Outlook cache at sender

If the phenomenon occurs only with individual senders, in rare cases it may be due to this.

An indication to determine whether one is affected by this problem may be that it is not possible to enter the recipient from the address field into the Outlook contacts. In this case, the sender receives the following error message:

The desired operation could not be performed. The selected command is not valid for the recipient. The recipient cannot be added to the contacts. An internal help function has reported an error.

If this is the case, it is helpful to delete the recipient from the AutoComplete list in Outlook at the sender (compose a new e-mail and enter the recipient, mark the recipient in the list of suggestions with the mouse and press the "Remove" key), or to delete the entire NickName (AutoComplete) cache of the sender so that the recipient's public key is read anew from the global address book.

Related links:

• The "S/MIME Capabilities" certificate extension
• Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)

External sources

• Nickname cache (Microsoft)
• Autocomplete Stream (Microsoft)
• Clearing AutoComplete and other Recipient Caches (ENow Software)
• Your Digital ID name cannot be found error when decrypting a message by using a 3DES certificate (Microsoft)