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?
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.
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.