Cer 和 pfx 文件之间的区别是什么

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.

In my experience (it's not as vast as i want it to be) i use a pfx file when configuring the https binding on an IIS server (since this contains both the public and the private key, you are fine with just that file), a cer file is just the public portion of the key pair (most of the times) and you need to use it in conjunction with a .key file when configuring the ssl traffic on an nginx or apache server,

As far as i understand there are no more hard reasons to use one or the other,

As has been mentioned, the question is a bit of apples and oranges, as the cer file is just the public key but the pfx file contains both public and private keys.

So a more fair question would be when would you want to use a pfx file as opposed to a pem file. Given that pfx files have been criticized for being overly complex, a fair answer to your second question might be: you would only ever want to use a pfx file if you're running IIS and its configuration absolutely won't let you use anything else.

Source: https://en.wikipedia.org/wiki/PKCS_12 (Referenced footnote is an article from Peter Gutmann.)

SSL uses asynchronous encryption, which means that one key (the private key) is given to the server that "owns" the key pair, while the other key (the public key) is distributed freely.
It is called asynchronous because data encrypted with the private key can only be decrypted with the public key, while data encrypted with the public key can only be decrypted with the private key. So if you want to send something securely to the owner, you encrypt it with his private key and he will be the only one who can decrypt it. If the owner wants to prove that he sent something, he encrypts it with the private key and anyone who has the public key can decrypt it. (Once the certificates are installed, this is usually done behind the scenes by the browser or email tool.)
Since the owner wants to keep that private key private, it will be password protected and given ONLY to the owning server (often in a PFX or P12 file). But the public key will be distributed freely (often in a CER file).

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