A Brief Primer on Digital Certificates and File Types
For those who want to download it, here's the article in PDF format.
When in the course of human events we deal with digital certificates, there are a number of file formats that we may encounter. We’ll take a look at the file formats, how they are used, and how you can identify them in the wild.
Before we dig in, there are a couple of abbreviations that will be helpful.
PKCS - Public Key Cryptography Standards
These were originally defined by the RSA corporation. Some of them have been adopted by the IETF as actual RFC’s, others are just used as-is. Some have been withdrawn and others are still being formulated.
DER vs. PEM Encodings
Most files can be in one of two different encodings. To begin with, almost all of the files start off by using a mathematical encoding method called Abstract Syntax Notation One, or ASN.1. This gives the data an abstract structure, similar to the Document Object Model (DOM) for XML or HTML.
The ASN.1 structure is in turn expressed in a binary encoding format known as Distinguished Encoding Rules, or DER. However, trying to send DER-encoded files can fail since DER bytes can contain all 256 possible values and some transmission channels may assume only 128 values or do things like convert line endings.
To protect against this, the DER-encoded data can be encoded using Base64 to become the Privacy Enhanced Mail or PEM encoding. This also is a more human-readable format, as it usually has a header line that gives an indication of the actual content.
At least some of the time a PEM-encoded file is given an additional .pem filename extension, while a DER-encoded file will lack the additional .pem filename extension. E.g., a DER-encoded RSA private key will have a filename extension of .key, while a PEM-encoded RSA private key will have a filename extension of .key.pem. That said, many times people just assume the use of PEM as standard and omit the additional .pem filename extension. The only way to tell for sure is to look at the file in a text editor. If it contains binary gibberish it’s in DER encoding; if it contains neat lines of ASCII characters and has nicely formed beginning and ending lines, it’s in PEM encoding.
Since the PEM encoding is derived from the DER encoding, the two types of files are equivalent. However, some applications require one encoding and others require the other encoding. You can use the OpenSSL tools to convert them back and forth.
With that out of the way, the four most-frequently encountered file types are PKCS#1, PKCS#7, PKCS#12, and digital certificate.
Usual extensions: .key or .key.pem
This is the grand-daddy of all of them, and has absorbed several others. Although it’s commonly called a private key, it holds both an RSA private key and its associated public key. It cannot hold other types of private keys, such as ElGamal or Elliptic Curve keys. Since it contains a private key and may be in an unencrypted form, you should NOT expose a PKCS#1 file to anyone outside your organization, such as sending it via unencrypted e-mail or posting it to an unencrypted file sharing location.
A PKCS#1 file can be found in both DER and PEM encodings, and in both encrypted and unencrypted forms. A PKCS#1 file in PEM format starts with the line:
-----BEGIN RSA PRIVATE KEY-----
and ends with the line:
-----END RSA PRIVATE KEY-----
A PKCS#1 file that has been encrypted will also have an couple of encryption header line just below the BEGIN line, with the format:
None of the GUI tools on OS X will produce a PKCS#1 file, but OS X Server stores PEM-encoded, encrypted PKCS#1 files in the /etc/certificates directory with the filename extension .key.pem.
Most open source software that utilizes a private key expects to load the key from a file in PKCS#1 format, although some use the PKCS#8 format instead. You’ll need to check the documentation to see what the software expects.
Usual extensions: .p7b or .p7c
This file format is associated with S/MIME signed and encrypted e-mail messages. However, it is used in other ways as well. PKCS#7 has been superseded by the Cryptographic Message Syntax (CMS), but the core features are the same and PKCS#7 files can be processed by CMS systems.
A full PKCS#7 file has an extension of .p7b. It contains a message (that may be encrypted) and an optional a digital signature. If the file contains a digital signature, it usually also contains a copy of the digital certificate that was used to sign the message. It does not contain a private key.
However, some organizations also use PKCS#7 files without any actual message content to transport digital certificates. If the file does not have any content and is only being used to transport certificates, it usually has an extension of .p7c. Again, it does not contain a private key.
Regardless of the content, the file may be in DER or PEM format. A PKCS#7 file in PEM format starts with the line:
and ends with the line:
Exporting a certificate from Keychain Access using the “Certificate Bundle (.p7b)” option will produce a DER-format PKCS#7 file. Also, some certificate authorities will issue certificates using a PKCS#7 file.
Usual extensions: .p12 or .pfx
This file format is an encrypted store that contains a private key and one or more digital certificates. It is always a binary format using DER encoding. PKCS#12 is used to transport private keys and certificates between systems. Java applications may also use PKCS#12 files as key stores.
The original file format was defined by Microsoft as the Personal inFormation eXchange (PFX) format. PKCS#12 is an extension of PFX, but the two filename extensions are used interchangeably and the two file formats are generally interchangeable. The PKCS#12 file format is arguably one of the most complex and problematic of file formats in use today. See http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html for a long explanation of what they did wrong in designing this format.
Exporting a certificate and its associated private key from Keychain Access using the “Personal Information Exchange (.p12)” option will produce a PKCS#12 file. This is the only way that you can export a private key from Keychain Access.
While a PKCS#12 file by itself is encrypted and secure, you should not expose the file and its password together to anyone outside your organization, such as sending it via unencrypted e-mail or posting it to an unencrypted file sharing location.
Usual extensions: .cer, .crt, or .cert; also .cer.pem, .crt.pem, .cert.pem, or sometimes just .pem
This is an actual digital certificate, either self-signed or from a certificate authority. Somewhat surprisingly, it is not a PKCS file format, although it uses the same ASN.1 structure and DER or PEM encodings. A PEM-format certificate file starts with the line
and ends with the line
Exporting a certificate from Keychain Access by dragging and dropping to the Finder or using the “Certificate (.cer)” option will produce a DER-format digital certificate file. Most certificate authorities issue digital certificates using this format with a PEM encoding. This format does not contain a private key.
There are a couple of less common formats that you may encounter as well.
Usual extension: .csr
This is a Certificate Signing Request. Almost always created using PEM encoding, a PKCS#10 file begins with the line:
-----BEGIN CERTIFICATE REQUEST-----
and ends with the line:
-----END CERTIFICATE REQUEST-----
The most common way to create a PKCS#10 file on OS X is to create a certificate request from within Server.app.
Usual extension: .p8
This is a private key format that can hold any type of private key, not just RSA private keys. This format is rarely encountered on OS X, but Java uses it extensively. It can be in DER or PEM encoding.
Similarly to a PKCS#1 file, you should NOT expose a PKCS#8 file to anyone outside your organization, such as sending it via unencrypted e-mail or posting it to an unencrypted file sharing location.