Digital Certificates - Part 5

By jgreen posted Jan 16, 2012 06:15 PM


Certificate File Formats

Using our GeoTrust example again, a server at GeoTrust packages our new digital certificate and our private key into a single file.  This file format is known as PKCS#12 and typically takes the file extension of .p12 or .pfx.  In order to protect the confidentiality of this file, it is password-protected using the password we entered at the start of the process.  The password protection is important – without it, anyone getting ahold of this file would have a valid digital certificate AND the corresponding private key, and could impersonate us at will. 


A file that contains an unprotected certificate and corresponding private key is often known as a PEM (Privacy Enhanced Mail) format file.  You can recognize a PEM file because it is base64-encoded plain ASCII text and takes the following format:









Other common encoding schemes for digital certificates include CER (Canonical Encoding Rules) and DER (Distinguished Encoding Rules).  These files are not human-readable text.  For the Unix enthusiasts, most Linux and FreeBSD systems come with OpenSSL pre-installed.  If you want to convert between different certificate formats, OpenSSL is the tool to use. 


Certificate Revocation

Let’s say that Randy carelessly stores his digital certificate and private key in a PEM file and stores it on a network drive where others can get access to it.  Randy’s adversary – let’s call him “Taylor” – comes along and finds this file, and begins using it to impersonate Randy.  Once the private key to a certificate has been exposed, the digital certificate can no longer be trusted by anyone.  This is where certificate revocation comes in.  Certificate revocation allows us to go back to the issuing CA and ask that it revoke, or make invalid, a previously issued certificate.  Each CA will generate a Certificate Revocation List (CRL) that contains the serial numbers of certificates that have been revoked.  An end user or client software should, before trusting a digital certificate, check the CRL from that CA to make sure the certificate is still valid.  In practice, this step is rarely done because CRLs can grow very large and there is significant overhead involved in checking a CRL each time.


An alternate to CRLs is known as Online Certificate Status Protocol (OCSP).  This is described in RFC 2560 and takes the form of a request/response query to an OCSP server, or “responder”.  OCSP eliminates the overhead of transferring large CRLs and can also update in real time, but as the name implies it is only designed for online systems – systems with a network connection to the certificate authority.  OCSP is expected to continue to gain in popularity.


Wrapping Up

Properly implemented, public key infrastructure provides a solid method of determining identity, encrypting communication, verifying integrity and establishing non-repudiation.  If there is any downside to this technology, it is in the number of moving parts and the complexity of understanding how it works.  As the example with GeoTrust shows, however, automation can greatly simplify PKI mechanics and allow a user of even modest technical ability to participate in the system.  This is a trend that should continue into higher functions such as server certificates and even certificate authorities.