I need to configure Single Sign On based on SAML 2.0 including encryption. Life would be easy if salesforce would allow import of the Identity Provider meta information XML that includes certificates for both the signing and the encryption. Unfortunately the encryption certificate must be uploaded either based on a Certificate Signing Request (CSR) or a Java Keystore. As I received the certificate from the Identity Provider I wanted to import it into a JKS and upload this one into salesforce. That seems to work at first glance but the certificate included in the JKS file does not show up as an active certificate. Worst thing about it is that no error message is being shown, the certificate is just not imported. Has anyone experienced the same behaviour? Any guesses what the problem with the JKS could be?

  • Why would you upload it to JKS? I'm thinking the point of the CSR or JKS was to build a certificate from one of those systems. What type of file was given to you from the IDP? Was it the public key or the private key? We used a self signed cert without issue, and no tweaking with JKS was needed. I just needed the public cert from our dev on the IDP side.
    – drakored
    Dec 24, 2014 at 16:01

1 Answer 1


How a mainstream encryption scenario works in SAML: identity provider encrypts some elements of the SAML response with service provider's public key. (I am assuming an asymmetric cipher which is how most implementations incl. Salesforce do this). The service provider decrypts using the private key that corresponds to the public key used to encrypt. In other words, the service provider needs to own a keypair - private key and public key - for this use case to work.

The identity provider's metadata could also contain a KeyDescriptor element with use="encryption". This has nothing to do with the encryption scenario described above.

A JKS keystore can contain different types of entries. You can import a public key into the keystore. If you use Java keytool to list the entries in your keystore (keytool -list -keystore), a public key-only entry will show up as a trustedCertEntry type. Another type of entry is one that contains a keypair (private and public key). This type of entry will be listed as 'PrivateKeyEntry'.

When importing a JKS keystore under Certificate and Key Management section, Salesforce appears to only read entries of PrivateKeyEntry type. In the encryption scenario above, that's the only entry that could be used to import a keypair. If you stick your identity provider's private key and cert into the keystore as a PrivateKeyEntry, you will be able to import it . The public key (cert portion) of the entry will then show up on the list when you're creating a SAML service provider under Single Sign-On Settings.

  • Excellent description of the technical background, thanks! It turned out that the private key imported into the keystore is not the one associated with the certificate included. Obviously JKS does not enforce this, while e.g. PKCS12 does. So you can double check correctness of the JKS entries by converting the JKS into a PKCS12 file.
    – h9nry
    Jan 5, 2015 at 10:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .