What is the difference between a certificate and a private key?
Every Private Key has a corresponding Public Key. The public key is mathematically derived from the private key. These two keys, together called a "key pair", can be used for two purposes: Encryption and Signing. For the purposes of certificates, signing is far more relevant.
A certificate is basically just a public key, which has been signed by someone else's private key. This forms the basis of public key infratsucture (PKI), which is explained in the articles linked in the question.
How do Certificates and Private Keys relate?
A certificate is just a "fancy" public key, which is related to a private key. You can do the same thing with a certificate as you can do with a public key.
If Bob gets the certificate of Alice, he can encrypt a message for Alice. Likewise, if Alice publishes some data and signs it with her private key, Bob can use Alice's certificate to see if it is really from Alice.
What are all those different file types?
.pemis a de-facto file format called Privacy-Enhanced Mail. A PEM file can contain a lot of different things, such as certificates, private keys, public keys and lots of other things. A file being in PEM format says nothing about the content, just like something being Base64-encoded says nothing about the content.
.cer: This is another pseudo-format that is commonly used to store certificates. These can either be in the PEM or in the DER format.
.pfx: These are interchangable file extensions for the PKCS#12 format. Technically, PKCS#12 is the successor to Microsoft's PFX format, but they have become interchangable. PKCS#12 files are archives for cryptographic material. Again, what kind of material this contains is completely up to the user.
.p12 can all be used to store certificates, public keys and primary keys. From a purely technical standpoint, you can not tell what the semantic content of any of these files is just by their file extension. If you ever get confused, don't worry - you're not alone.
However, there are some common conventions that are being followed.
.pfx files are usually used to store a certificate together with the private key that corresponds to this certificate.
.crt files usually contain single certificates without any related private key material.
.pem files are wildcards. They can contain anything, and it's not uncommon to see them used for all different kinds of purposes. Luckily, they are all plain text, and are prefixed in a human-readable way, such as
-----BEGIN CERTIFICATE----- MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y ...
Why would an application not handle a
.crt file if it wants a client certificate?
A certificate is just a public key, and thus by definition public. A client certificate is no different - just a public key by a person, machine or other "client", that is signed by some authority.
An application that wants a client certificate usually wants to use that certificate for something, such as to authenticate the client to a server. In order to do that, one needs the certificate and the corresponding private key.
So an application should really write "certificate plus private key", because the certificate alone is not enough to prove one's identity. It's actually the private key that does it.
Certificate is a container that holds information about certificate holder/owner and public key. Private key is raw key material without any extra information. For example, from private key you can't extract information about owner of the key, or a certificate this private key is associated with. Certificate is often called as public certificate, because it contains only public key and public information.
Possessing the public certificate only doesn't prove certificate ownership. Only possession of private key that is associated with public key embedded in public certificate can prove certificate ownership.
About certificate types:
.pemare literally same thing. Just with different encoding used to store same information in file.
.crtis often a pure pure binary copy of ASN.1-encoded certificate.
.pemis same binary copy of certificate converted to base64 string and wrapped by PEM header and footer. They store only public certificate. No private key inside. See RFC 1421 for more details about PEM. You can open PEM in any text editor, copy/paste encoded certificate. It is hard to do with raw binary file, which
.pfxare same thing. They represent a PKCS#12 container which is suitable to store both, public certificate and encrypted private key. PFX or P12 use binary file encoding. With PFX, you can store multiple certificates with associated private keys and optional certificate chains. Hence it is a container.
why, for example, an application expecting a "client certificate" blows up when you give it a .crt file.
as I said, having only public certificate (which
.crt is) is not enough to prove the ownership of the certificate. When client authentication is used, client must prove that it owns the supplied certificate and it requires a private key to prove this ownership. Thus, client app must be able to access the private key associated with public certificate. Depending on client application, platform and other variables, it is done by having a
.key file in a defined location, accessing PFX/P12 or other means provided by platform (read certificate and key from certificate store in Windows).