What are the differences between .pem, .csr, .key, .crt and other such file extensions?

Question

I'm new to SSL / TLS, and I want to work with the OpenSSL toolkit.

What do .pem and .csr stand for?

I do know that .key is the private key and .crt is the public key.

Answer 1

File extensions can be (very) loosely seen as a type system.

• .pem stands for PEM, Privacy Enhanced Mail; it simply indicates a base64 encoding with header and footer lines. Mail traditionally only handles text, not binary which most cryptographic data is, so some kind of encoding is required to make the contents part of a mail message itself (rather than an encoded attachment). The contents of the PEM are detailed in the header and footer line - .pem itself doesn't specify a data type - just like .xml and .html do not specify the contents of a file, they just specify a specific encoding;
• .key can be any kind of key, but usually it is the private key - OpenSSL can wrap private keys for all algorithms (RSA, DSA, EC) in a generic and standard PKCS#8 structure, but it also supports a separate 'legacy' structure for each algorithm, and both are still widely used even though the documentation has marked PKCS#8 as superior for almost 20 years; both can be stored as DER (binary) or PEM encoded, and both PEM and PKCS#8 DER can protect the key with password-based encryption or be left unencrypted;
• .csr or .req or sometimes .p10 stands for Certificate Signing Request as defined in PKCS#10; it contains information such as the public key and common name required by a Certificate Authority to create and sign a certificate for the requester, the encoding could be PEM or DER (which is a binary encoding of an ASN.1 specified structure);
• .crt or .cer stands simply for certificate, usually an X509v3 certificate, again the encoding could be PEM or DER; a certificate contains the public key, but it contains much more information (most importantly the signature by the Certificate Authority over the data and public key, of course).

There are quite a few other extensions that you will find as well:

• .p8, .pkcs8 are private keys. PKCS#8 defines a way to encrypt private keys using e.g. a password. However, quite often, only the inner unencrypted PKCS#8 structure is used instead (which just defines the type of key). The inner structure can then e.g. contain a PKCS#1 formatted private key for RSA or a SEC1 one for Elliptic Curves.

  [dave_thompson: X9.62 defined commonly-used formats for EC public key and parameters (curve), but I'm pretty sure not private key although I won't spend my money to verify; for publickey and parameters SEC1 cites X9.62, and rfc5480 cites both SEC1 and X9.62, but for privatekey rfc5915 cites only SEC1 which cites nothing. Also I would say: generally not transported, but still fairly commonly PEM encoded, because many programs that use a separate key file or section, often via the OpenSSL library, require or prefer PEM: Apache httpd, nginx, haproxy, nodejs, python, wget and some curl; also Apache tomcat depending on version and option. But Java natively uses PKCS#8 DER, unencrypted.]

• .p12 or .pfx is a PKCS#12 defined key store, commonly password protected. It can contain trusted certificates, private key(s) and their certificate chain(s), but also other information such as secret keys and (very uncommonly) other personal information; .p12 is usually binary / DER encoded. PKCS#12 has lots of options plus extensions (i.e. attribute OIDs) with varying support, so it is not safe to assume that every P12 file will work in anything that uses (some) P12 files.

• .crl is a Certificate Revocation List which is defined within the X.509v3 certificate specifications, and this is usually DER encoded as well.

• .p7b or .p7c is a specialized kind of PKCS#7/CMS message: a SignedData that doesn't contain data and isn't signed, and is used only to as a way to conveniently handle a group of certificates and/or CRLs. In particular it is often used as a way to handle the certificates which make up a 'chain' or 'bundle' as a single, well-defined unit. Other kinds of PKCS#7/CMS messages exist but are less used, and may have extensions like .p7 or .p7m, except that detached signatures, as a special case, are usually .p7s. In addition S/MIME is layered on top of CMS: S/MIME messages are really CMS messages wrapped in MIME format, and as such are usually identified by the MIME-type (aka media-type) in the message not by a file extension.

Beware that not everyone may use the same extensions - there is no official register or anything like that. You're probably better off using the POSIX file command line utility first.

---

There are also proprietary formats that are relatively common.

• .jks stands for Java Key Store. It can be used to store private keys with their certificate chains (root CA, intermediate CA's, leaf certificates or just a single self-signed certificate), certificates of other parties (usually but not necessarily CAs) to form a trust store, or both. The JKS format (like the Java KeyStore API) is technically agnostic and can use any type of certificate for which the installed crypto-providers offer a CertificateFactory object, but in practice the only CertificateFactory implemented is X.509 (or PKIX) and the main applications in Java for keystores - code signing, S/MIME, XML/SOAP, and SSL/TLS - use only X.509. .jks key stores are password protected, using a proprietary (and weak) cipher Sun created back during the munitions-list era, but they have been deprecated since 2017 in favor of PKCS#12 with transitional support.

[dave_thompson: the JSON formats, JWS/JWE/JWT/JWK, are now common for communication (and not proprietary), but IME rarely stored in distinct files]