Certificates can be quite confusing, and after some work migrating them between two Cisco ASA devices, I thought I would try and provide a summary of the key concepts (no pun intended) and the various file formats used.
Introduction
Digital certificates, or more specifically X.509 certificates, are used in many internet protocols, including SSL/TLS, which is the basis for HTTPS. They can be deployed for encryption, authentication, and digital signatures.
Public Key Infrastructure or PKI is an umbrella term used to define the management of digital certificates and public-key encryption.
Public key encryption (also called asymmetric encryption) involves the use of a key pair — a public key and a different private key, which are mathematically related to each other. Either of the keys can be used to encrypt information but only the associated other key can be used for the decryption. The public key, as the name implies, is available publicly. The private key, on the other hand, is kept private.
There are various asymmetric encryption algorithms available, including RSA, Diffe-Hellman, DSA and Elliptic curve. RSA is used heavily in SSL/TLS with Elliptic curve being supported in later versions.
Encrypting with the private key confirms identity, as anyone with the public key can decrypt, but only the owner can encrypt with the private key. Whereas, encrypting with the public key creates confidentiality as only the private key owner can decrypt.
There is also symmetric encryption, which uses the same keys for both encryption and decryption. Examples of symmetric key cryptography include AES, DES and 3DES, with probably the most common being AES in its various bit lengths. Symmetric encryption is much faster than asymmetric encryption.
SSL Certificates
Although the makeup of an SSL certificate really consists of a private and public key, the SSL certificate itself contains only the public key, as well as additional information such as an identity, issuer, what the certificate is supposed to be used for, and other types of metadata. The private key is kept separate (e.g. on the web server only) and not available as part of the visible SSL certificate.
Typically, a certificate is signed by a certificate authority (CA) using the CA’s private key. This verifies the authenticity of the certificate.
In some cases, the certificate may be valid for multiple hostnames, either by being a “wildcard” certificate (where the subject name contains a “*”) or by having multiple names contained in the “Subject Alternative Name” field (commonly called SAN certificates).
Communication
A server will present a certificate as part of the initial connection. A client connecting to the server will then perform certification validation by ensuring the subject of the certificate matches the hostname, it is in date and signed by a trusted certification authority.
The certificate public key is used to establish a secure connection back to the server (as only the server can decrypt the message with the private key). The messages are used to agree a new encryption key which is then used to secure future communications using fast and simple symmetric encryption. i.e. the public and private keys and asymmetric encryption are only used to agree a secret key for the rest of the conversation.
Certificate Formats
There are several formats used to store and exchange certificates and unfortunately naming conventions for files are not standard! The two most common formats are Distinguished Encoding Rules (DER) and PKCS#12.
Note that there is another “encoding format” called Canonical Encoding Rules (CER). It’s just an unfortunate coincidence that CER are the first three letters of “certificate”. Certificates are not normally encoded using CER. Although they can be saved to a file with a “.CER” extension!
PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file.
Certificates can also be stored in either binary or ASCII formats. ASCII formatted files are encoded using BASE-64 which translates all of the binary data to readable characters. The main reason for the ASCII format is you can reliably copy and paste ASCII data!
Certificate filename extensions
There are several commonly used filename extensions for X.509 certificates. Unfortunately, some of these extensions are also used for other data, such as private keys.
- .pem – (Privacy-enhanced Electronic Mail) BASE-64 encoded DER certificate, enclosed between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“
- .cer, .crt, .der – usually in binary DER form, but BASE-64 encoded certificates are common too
- .p12 – PKCS#12, may contain certificate(s) (public) and private keys (password protected)
- .pfx – PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)
In practice, if the file is readable and contains the “—- BEGIN….” heading, then it is as ASCII format, BASE-64 encoded certificate. If it looks like gibberish, it’s a binary format.
Other extensions you might see used for ASCII DER files:
- .pub – public key
- .key – private key
- .pvk – private key
PKCS#12 and PFX files can also be stored in ASCII format with BASE-64 encoding – and look similar to a PEM file! This is the format that a Cisco ASA will export its public and private keys in.