REASON

The reason in this case, ultimately, was that the SDConnex server that the client was reaching out to had been pointed to talk to the wrong SES database (In this case the customer had two databases, and had mis-configured the SDConnex to talk to the wrong database).

Possible further ideas:  Possibly what was happening was that the SDConnex certificate was right so communication was allowed, but that the encryption keys that protect the databases were different from the fundamental key that protects the end point's key, and since the database that the mis-configured SDConnex was talking to was unable to work with the encryption key the client was trying to use or create, the key could either not be retrieved (the decryption failure here might be inability to get information by SDConnex out of the database ?) or could not be stored and validated ?  (Hal's interpretation/guesses - needs to be validated by someone more knowledgeable on the internals of access to the database through SDConnex).

NOTE to Support: If it is ever determined that this can occur from other causes, please update this article to reflect additional details.

SOLUTION

This issue was resolved once the SDConnex server was connected to the correct "live" SQL Server database.

• Error message or code: 0x8220 RSA decryption failed while using MS CAPI