So, I'm trying to understand how certificates really, really work - I haven't been able to find what exactly I'm looking for on google so I'm phrasing it my way... If there's a straightforward link that you think might help me - please post it and I will delete this question.
I understand that when the client(say, a browser) makes a request to a website, it verifies the identity of the website by checking its certificate. Self signed certificates are discouraged and certificates from the Certificate Authority (and its branches) are the real deal. Now that the identity has been verified, the request is processed by the server and the response is sent to the client and now the user (a human being) can see that green lock sign on their browser next to the URL. Did I sum this up correctly? And this response is encrypted and will be decrypted by the browser/client?
In the case of SSO (single sign on) flows - when SAML assertions are "digitally signed" - what exactly does this mean? And how does the above mentioned certificates help in that?
I've just got too many concepts all mixed up in my head and was looking for clarity understanding systems and security and TLS.
First of all this is all about asymmetric cryptography. This allows to encrypt the message with one key and decrypt with another. Why is this helpful.
Secure interaction
You can send a message to your server using the public key of that server. Thus you can be sure that nobody else (except of that server) would be able to decrypt that message
Digital signing
You can encrypt a digest of a message with your private key and anyone will be able to check if that was you by decrypting your "signature" with your public key.
At what stage the certificate is involved
Both above cases have a pitfall. You cannot be really sure that the public key that the server provides you is really a key of the party you trust to. The same with signatures. You cannot be sure that the public key you have just successfully used to verify a signature is really a key of a person you expect to sign your contract.
Certificate is a bundle of a public key and the information about the holder of the key pair. This bundle is digitally signed with the private key of CA.
What is the end to end process
Let's consider https case. Your client says to a server "Hey I want to use https protocol". This is the point where asymmetric cryptography is involved. You use server's public key to encrypt a symmetric key (since the asymmetric cryptography is somewhat expensive, it is used only when symmetric key is being negotiated) that will be used for encrypting traffic.
But how can you be sure you can trust that server. Actually what server sends you is not just a key but a certificate. You take the certificate and verify that the server name specified in the cert is actually what you used in your address bar. You also verify the signature of CA using that CA's public key.
Certification chain
Public key of CA that has signed the server certificate might also require verification. Such verification is performed in the same way as explained above. The chain has to eventually stop at the certificate that you absolutely trust. Such certificates are stored at so called trust store.
So this is how ssl works. Digitally signed SAML assertions work in the very similar way. They deliver certificates which you can validate and use the public keys extracted from them for validating the signature of assertions.