2 x scenarios that work slightly differently:
SCENARIO 1:
Web Browser (Client) accessing Web Page (Server) over HTTPS using SSL.
The Server has the .PFX File containing both keys. The Client connects to a Website on the Server, and the Server sends a copy of its Public-Key (.CER file) to the Client as part of the SSL handshake. The Client then generates a "SESSION-Key" and encrypts it using the public-key received from the server. The Session-key is then sent back to the server and decrypted to confirm its authenticity. If successfully, both the Client and Server now share the "Session-Key" to communicate using symmetric encryption (i.e. both client and server, now both encrypt AND decrypt all messages between each other using the same session-key. All of this is being done behind the scenes in the background of the web browser, between the time of you entering the URL in the address bar, and seeing the web page appear.
SCENARIO 2:
Application (Client) connects to a FTP Site (Server)
or
Remote Desktop (Client to Server) using SSH
(both examples would apply)
In this scenario, both the Client and Server will have their own private and public key pairs
(in contrast to the other examples mentioned in this thread, that only explain when a server has both keys, and the client has the public key only)
Now, for explanation purposes - Lets label the Key pairs something like:
A1 and A2 = as the Servers Private and Public Keys Respectively
B1 and B2 = as the Clients Private and Public Keys Respectively
Using this model, previous posts in this thread were talking about when the Server has A1 and A2 (.PFX file), and shares only a copy of A2 (.CER) with clients
Whereas FTP, or SSH connections (there are other examples out there) consist of A1, A2, B1 and B2 Keys in the entire Client-Server Communication. For instance,
- Client connects to FTP Server.
- Server Sends copy of its public Key (A2) to the Client.
- Client sends its own public key (B2) back to the Server, completing the handshake.
- This will now be using asymmetric Encryption
Server now has A1, (its own Private), A2 (its own public), and copy of B2 (Client's Public)
Client now has B1, (its own Private), B2 (its own public), and Copy of A1 (Server's Public)
Client-To-Server Comms:
Client uses A2 (servers public key) to encrypt messages bound for the Server,
Server decrpyts them using A1 (Server private key)
Server-To-client Comms:
Server uses B2 (clients public key) to encrypt message bound for the Client,
Client Decrypts them using B1 (Client private key)
Regarding the .CER and .PFX file Types, the Server ill have its own .PFX that shouldn't be distributed outside your organisation, instead, you should distribute the .CER file out to Clients.
more info can be found here:
https://www.digicert.com/ssl-cryptography.htm
and here:
https://serverfault.com/questions/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client