So, I know how public-private key encryption works. I understand how/why certificates are required. I understand how a SSO flow (IdP initiated) works. But, I do not understand how the three of them happen together. I am confused about what "signing" a SAML assertion means. I'm confused about "encrypted certificates". I just can't seem to tie it all together - can someone help me understand this better?

2 Answers 2


The IdP will sign either the SAML response of the SAML assertion using its private key. The SP verifies the signature using the IdP's public key.

It's also possible to encrypt the SAML assertion in which case the IdP encrypts the assertion using the SP's public key and the SP decrypts the assertion using its private key.

So, an IdP-initiated SSO flow might see the IdP signing the SAML assertion using its private key followed by encrypting the signed assertion using the SP's public key. The encrypted assertion is bundled into a SAML response and sent to the SP. The SP decrypts the SAML assertion using its private key and verifies the signature using the IdP's public key.

  • What about certificates?
    – Saturnian
    Oct 6, 2020 at 22:05
  • Certificates store the public key (+ some metadata like expiration dates) Oct 18, 2022 at 20:54

You've asked a couple of different questions. ComponentSpace has nicely answered one of them; I'll tackle another: "encrypted certificates".

Normally, certificates don't need to be encrypted. They are intended to be publicly visible documents that contain a public key, plus a signature that attests to their authenticity. Encrypting them is essentially pointless.

But something about certificates and keys is that in the real world, you have to deal with how and where these artifacts are stored. As you know, a public/private keypair has two parts - a public key, and a private key. The public key is usually kept on a signed certificate. But its matching private key must be kept in a secure place.

It's sometimes convenient to store both the certificate and the private key in the same file. This is common for setting up a web server, for example. The generic name for a file that can contain multiple keys and multiple types of keys is a "keystore".

A couple of common keystore technologies are Java Key Stores (JKS, for Java apps), and PKCS#12 files. A JKS or PKCS#12 file can store any combination of private and public keys: one private key; one certificate; multiple certificates (often a keystore will include all the certificates in the signing chain for any endpoint certificates they contain); and even multiple private keys along with multiple certificates.

(Inside the keystore, keys are identified with a "friendly" name, usually called an "alias". Both the private key and certificate will need to have the same alias, otherwise the program using the keystore won't be able to match the paired keys.)

Where it gets tricky is that a keystore can have its own top-level encryption. This means that unless you have the keystore password, you cannot even see the certificates that are stored inside it. Each private key inside the encrypted JKS also has its own separate encryption, with its own separate key and password. So to access a private key inside a keystore, you need both the keystore password as well as the private key password.

It's not normally important to encrypt a certificate, as a certificate is a document that is intended to be shared publicly. But when you use a keystore that has its own encryption, you may be dealing with certificates stored in an encrypted keystore -- thus, the slightly-misleading label of "encrypted certificates." It's not usually intended that a certificate be encrypted, but if it's stored in a keystore, it might be encrypted anyway.

  • JKS isn't all encrypted. The whole file has a MAC, but you can read the contents, including the certs, without the 'store' password; e.g. just run keytool -list -keystore file and hit return when prompted. Each privatekey IS encrypted, but with a weak ad-hoc algorithm invented by Sun back during ITAR. PKCS12 similarly has an overall MAC, which can be skipped, but stores the certs and pkeys in separate 'bags' and by convention the pkey bags are strongly encrypted (usually PBE-3DES) while the cert bag is weakly encrypted (usually PBE-RC2-40). Oct 7, 2020 at 5:42
  • Some tools e.g. openssl pkcs12 can vary this and use different encryptions for the bags; to an extent so can the BouncyCastle provider for Java. Oct 7, 2020 at 5:44
  • 1
    No they really truly aren't. cat is a little too basic, but I can do it with dd or head|tail and no password at all, and have numerous times. Post an example file (in hex or b64, or somewhere that won't corrupt it like pastebin) and I'll demonstrate. And the change to default PKCS12 in keytool (and also in the API, for programs that use the default) was Java 9, although 9 and 10 are now EOL and currently only 8 and 11 are LTS. Oct 8, 2020 at 1:16
  • @dave_thompson_085, thanks for the correction! Oct 8, 2020 at 2:01

You must log in to answer this question.

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