Is my understanding about how SSL works correct?

Question

I've been reading about 2-way SSL or mutual auth recently, and here's what I've figured so far:

Mutual auth is a way for the client to authenticate itself to the server, just like the server does to client during (1-way) SSL connections. Web browsers are preloaded with the certs of well known CAs, so, when a website sends it's public key (something like a .cer file?) the browser can use the CA's certificate to figure if this received certificate is valid or not. Similarly, in 2 way SSL, the server needs to have the client's CA's certificate, or the self signed certificate using which the client's certificate was generated to confirm if the client is authentic or not.

Following are some specific questions about which I'm not yet clear and I'd appreciate if someone could verify my understanding:

1. The certificate that the server sends for 1 way SSL just contains the public key of the server right? Is this necessarily a .cer file, or something like a .cer file?
2. The CA certificates that the browsers come preloaded with - are they like .pfx certificates? And just having these certificates is enough for the browser to confirm if the cert received from the server is a valid one or not?
3. In case of self signed certs, does the server need to have the .pfx self signed certificate from which the client certificate was created?

I guess it's clear from my questions that I'm not even sure when the public key and when the private is key is used to encryption/decryption, so when you answer these questions, I'd appreciate it if you could also mention which keys are used for what purpose when a specific certificate is used.

Answer 1

Let's abstract from a .cer or .pfx for a moment.

What is a certificate? It is something tying public key to a name (oversimplification, but should be OK for this question). Certificate is signed by a third party (certification authority) which certifies that this public key "belongs" to this name (e.g. www.example.com).

Now, when web browser connects to a SSL site, site responds with its certificate. Web browser then verifies that certificate by checking if it is signed by a trusted root certificate (one of preloaded with the browser). If it does, browser can establish secure session using public key from the certificate (because it is now confident that public key belongs to the site it's connecting to).

In practice sites return not a single certificate, but a chain of them (site's leaf cert and one or more intermediate ones). This doesn't change the big picture much but browser now needs to verify whole chain and make sure it ends up in one of the trusted root certs (i.e. that leaf cert is signed by intermediate cert and that intermediate is signed by root cert).

As to private/public keys... Certificates do not contain any secret or private keys; they only contain entity's public key. In short, party proving its identity must possess private key corresponding to its certificate. With 1-way SSL this means that server must have private key corresponding to its certificate; with 2-way this means that that client must also have private key corresponding to its certificate. Anyone with private key corresponding to a certificate may impersonate certificate holder.

To your questions:

1. Certificate is a public key + name + other info; no private data in there;
2. Preloaded certs are exactly same as ones returned by the server (i.e. no secret data); the "magic" is that they are trusted by the system by default, so other certificates signed by those trusted certificates will also be trusted;
3. You're talking about client auth here? Server only needs certificate of the client that it can trust (self-signed certs might satisfy this) and client certificate must absolutely not contain client's private key.

I've tried to simplify things a bit, so they're not 100% accurate and there's a room for nitpicking :) But I hope this helps to better understand the basics.