SSL: Useful Information & Commands

As developers, we know that SSL is quintessential when writing software that communicates securely over networks.  Whether it be publishing or consuming REST services or performing enterprise PKI communication in large organizations, knowledge of this topic is important.  When I reached the point in my career that I needed to understand SSL, I found it challenging, to put it mildly, to find any sort of consolidated compendium on the subject.  More recently developers within Onyx have been coming to me for help on just this topic; hence, this post.

Here, I’ve simply aggregated, organized, and published my various research (assembled from a variety of places*) as a public service for all those out there in the wild who are as confounded as I was when I first started scratching the surface of SSL.  The below attempts to provide high-level information as well as content and commands regarding certificates and the myriad ways of representing, converting, packaging, and using them:

Formats
There are four different ways to present certificates and their components:

• PEM - Governed by RFCs, its used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more). The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

  Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

• PKCS7 - An open standard used by Java and supported by Windows. Does not contain private key material.

  The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extention of .p7b or .p7c. P7B certificates contain "-----BEGIN PKCS7-----" and "-----END PKCS7-----" statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

• PKCS12 - A Microsoft private standard that was later defined in an RFC that provides enhanced security versus the plain-text PEM format. This can contain private key material. Its used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.

  The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

  When converting a PFX file to PEM format, OpenSSL will put all the certificates and the private key into a single file. You will need to open the file in a text editor and copy each certificate and private key (including the BEGIN/END statments) to its own individual text file and save them as certificate.cer, CACert.cer, and privateKey.key respectively.

• DER - The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used very much outside of Windows. The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms. The SSL Converter can only convert certificates to DER format. If you need to convert a private key to DER, please use the OpenSSL commands on this page.

Containers & Other Important File Formats

Somewhat frustratingly there are many different “container” standards that are used for packaging certificates. There may in fact be some that have been left out, but as others have tried to do, I also am giving a shot at assembling a complete list. Here goes:

• .csr - This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. The actual format is PKCS10 which is defined in RFC 2986. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate(which includes the public key but not the private key), which itself can be in a couple of formats.
• .pem - Defined in RFCs 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.
• .key - This is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.
• .pkcs12 .pfx .p12 - Originally defined by RSA in the Public-Key Cryptography Standards(abbreviated PKCS), the "12" variant was originally enhanced by Microsoft, and later submitted as RFC 7292. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys.

Here are few others as well:

• .der - A way to encode ASN.1 syntax in binary, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem. Windows sees these as Certificate files. By default, Windows will export certificates as .DER formatted files with a different extension. Like...
• .cert .cer .crt - A .pem (or rarely .der) formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.
• .p7b .keystore - Defined in RFC 2315 as PKCS number 7, this is a format used by Windows for certificate interchange. Java understands these natively, and often uses .keystore as an extension instead. Unlike .pem style certificates, this format has a defined way to include certification-path certificates.
• .crl - A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration. You can sometimes download them from CA websites.

Commands

Anyone that's going to want to work with SSL certificates will end up using OpenSSL.  Most refer to it as the Swiss Army knife of utilities for management of certs.  It's great and all, but it can also be quite confusing to use.  I've put together a list of commands that I've had to use over the years in addition to things I thought looked useful from a variety of other locations*.

Convert SSL Certificates

Use the following to convert SSL certificates to different formats:

Certificate Requests and Key Generation

When obtaining a new SSL certificate you must generate a certificate signing request (CSR), here are some useful commands:

View and Verify Certificates

Here are commands that are useful for viewing certificates:

Footnotes
* As an aside, I don't have references for this material, but should you notice that I "borrowed" your content here, let me know and I'll be happy to provide credit where credit is due.  Suffice it to say my intention is not to steal from anyone, please accept my thanks as it was quite helpful.  
** If you have suggestions, comments, or corrections, please let me know.