what is the difference between .cer & pfx file [closed]

Question

People used to say -

cer - certificate stored in the X.509 standard format. This certificate contains information about the certificate's owner... along with public and private keys.

pfx - stands for personal exchange format. It is used to exchange public and private objects in a single file. A pfx file can be created from .cer file. Can also be used to create a Software Publisher Certificate.

** got ref from this link What is the difference between a cer, pvk, and pfx file? **

but nobody is saying when we should use CERT file and when we should use PFX file. If possible please discuss the situation when we should go for CERT file & when we should go for PFX file. Thanks.

Answer 1

A .pfx includes both the public and private key for the associated certificate (NEVER share this outside your organization); it can be used for TLS/SSL on web site, for digitally signing messages or authorization tokens, or for authenticating to a partner system. A .cer file only has the public key (this is what you typically exchange with integration partners); it can be used to verify tokens or client authentication requests, and it is what is received by an HTTP client from a server in the SSL handshake.

Answer 2

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