Difference between .pfx and .cert certificates
There are two objects: the private key, which is what the server owns, keeps secret, and uses to receive new SSL connections; and the public key which is mathematically linked to the private key, and made "public": it is sent to every client as part of the initial steps of the connection.
The certificate is, nominally, a container for the public key. It includes the public key, the server name, some extra information about the server, and a signature computed by a certification authority (CA). When the server sends its public key to a client, it actually sends its certificate, with a few other certificates (the certificate which contains the public key of the CA which signed its certificate, and the certificate for the CA which signed the CA's certificate, and so on). Certificates are intrinsically public objects.
Some people use the term "certificate" to designate both the certificate and the private key; this is a common source of confusion. I personally stick to the strict definition for which the certificate is the signed container for the public key only.
.pfxfile is a PKCS#12 archive: a bag which can contain a lot of objects with optional password protection; but, usually, a PKCS#12 archive contains a certificate (possibly with its assorted set of CA certificates) and the corresponding private key.
On the other hand, a
.crt) file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate).
While doing client authentication, we require ssl client certificate to be installed on client browser. Is this .pfx file or .cert file?
Certificates are public data; _everybody_ has them. But client authentication is about having the client do something that only _that_ client can do; so the client must know something which is not public, and that's the private key. Thus, the client must have a private key along with its certificate; if the key was generated out of the client browser, then the expected setup is to import it into the client along with the certificate. Therefore, a .pfx file.
I have got .pfx file from IIS server where my certificate is installed. Is this the .pfx file which should be distributed? Since CA provided .cert file including keys which was installed on server.
@Xsecure123 no; there's two scenarios here -- and Thomas was answering for client auth only (where each client has it's own private certificate to prove their own identity). -- It sounds like you're doing something else -- it sounds like you're using a self signed certificate in IIS, and the clients don't trust it. -- In that case, you should give the clients a .cer file from the server. -- because the clients only need the public key to trust the server. -- If they also have the private key, then they can impersonate the server, or decrypt it's traffic, and that's not something you want.
I know this is a year-old thread, but for future readers, as mentioned above, no you do not distribute the .pfx file because that is the file containing the private key. You can extract and distribute the certificate (which is public) from the .pfx file via the method described here: https://stackoverflow.com/questions/403174/convert-pfx-to-cer
Where should you store the pfx file securely on the server? Obviously you wouldn't want another application using your PFX file, but I don't think I'd want to store it with my application either. Would you just import it into the machine cert manager and access it programmatically?
@Matt private key management is a whole topic into itself. Some relevant answers may be found here and here (the latter's not strictly relevant to PFX files, but still novel). The PFX file itself doesn't need to be stored on your server (i.e. if you're using IIS7, you'd import the PFX; if not, you'd extract the cert & private key from the PFX into their own files).