The answer of @SmokeDispenser is quite concrete and accurate. I will try to provide a bit of additional background in case you need it.
A private key is the most critical piece of data of your list. If someone gets access to it or manages to use it, the certification is pointless. As a result, private keys are often stored in files known as keystores. The content is usually password protected (technically it can support other protection modes, but I've only seen the case of passwords). This is important and often mishandled: do not send the password via email or other insecure mechanism, nor keep copies of them around. The extensions .p12
and .jks
belong to two formats of keystore. If you work with Windows, you might find also the extension .pfx
, but it's practically the same as .p12
.
Since you cannot distribute around your keystore and still don't have a certificate, you have to send a Certificate Signature Request (CSR) to the certificate authority. The .csr
file contains public information about your key and your identity.
As a response, the CA replies to your request with a certificate (.cer
or .crt
). It contains all your information, including your public key, some data about the CA and it is signed by the CA. Note that a certificate is only valid if you have a certificate chain (i.e. the system that validates the certificate, probably the browser, has the certificates of the CA stored).
Finally, depending of the usage you intend for the certificate, you might also need to be aware of the Certificate Revokation List (.crl
files). If a certificate is revoked (i.e. it is no longer valid for whatever reason), that action will be reflected on the CRL. When verifying a certificate, one should ensure that it is not in there. Nowadays, most reputable CAs offer also an online status check via the OCSP protocol.