Digital Certificates

An X.509 Digital Certificate is a secure container that can hold a public key, and miscellaneous other information about the public key owner as the Subject Distinguished Name (which contains their name, their email address, their organization, their location, etc). The items submitted for inclusion in the certificate are verified by someone (the Registration Authority) to be true and accurate. Then that information is "bound" to the pubic key by a trusted third party (the Certification Authority) digitally signing all of that information, using a well-secured private key (either a "root" private key or the lowest intermediate private key it in a hierarchy).

A Digital Certificate includes information supplied by the certificate signer (Certification Authority) including starting and ending validity dates, outside of which it should not be accepted as valid. It also contains information on who signed it (the Issuer Distinguished Name), and where to find the public cert associated with the private key used to sign it (in order to verify the certificate's signature). It may contain information needed to determine the revocation status (e.g. where to find that relevant Certificate Revocation List, or where to find the relevant OCSP server).

The reason we keep public keys in a Digital Certificate is to prevent someone from being able to trick you into using some other public key (the "public key substitution threat"). If public keys were used naked (without certificates), it would be very easy for a hacker (Eve) to trick Alice into using her (Eve's) public key instead of Bob's. Then Alice would accept bogus signatures on messages from Bob (intercepted, modified and re-signed by Eve) as valid, and Eve could read encrypted messages that Alice sent to Bob. Eve would not be able to re-encrypt the message correctly for Bob to accept it as coming from Alice (since she does not have Alice's private key), so Eve would just destroy the intercepted message (it would look like a normal failed delivery).

Certificates are created in tree-structured hierarchies. A given hierarchy (e.g. VeriSign's Class 3 server certs) has a pair of root keys (root public key and root private key), and one or more pairs of intermediate keys. These belong to the Certification Authority. They publish the public root and intermediate keys widely, but keep the root and intermediate private keys very secure (usually in a FIPS-140-2 level 4 compliant Hardware Security Module, which is itself very strongly protected). If the root or intermediate private keys are compromised, then all certificates in that hierarchy become invalid.

The root certificate is self signed (its own private key is used to sign it). The top level intermediate certificate is signed by the root private key. If there are other intermediate certificates, then each is signed by the next higher certificate's private key. End-user certificates are signed by the lowest level intermediate private key. There can be any number of intermediate certs, although one is the most common number and it is unusual for there to be more than two.

The root private key is kept offline, and only used to sign a new top level intermediate cert when needed (e.g. perhaps once every 5 years when the intermediate cert expires). Because of this, it typically has a very long validity period (maybe 25-30 years). The lowest level intermediate private key must be kept online, in order to be able to sign end-user certs. Because it is more at risk than the root private key, it has a shorter validity period, perhaps 5 years.

cert hierarchy

This is the overall structure of a digital certificate:

Things supplied by Applicant in Certificate Signing Request

Subject DN:         UID = This email address is being protected from spambots. You need JavaScript enabled to view it.
                    E = This email address is being protected from spambots. You need JavaScript enabled to view it.
                    CN = Lawrence Hughes
                    OU = Administration
                    O = Sixscape Communications, Pte. Ltd.
                    L = Cebu City
                    S = Cebu
                    C = PH
Public Key:         (2048 bit binary value)
 
Things added by Certification Authority
 
X.509 Version:      v3
Serial Number:      (128 bit binary value)
Issuer DN:          CN = Sixscape Client CA
                    OU = PKI Operations
                    O = Sixscape Communications, Pte. Ltd.
                    L = Cebu City
                    S = Cebu
                    C = PH
Valid From:         Friday, March 28, 2014 11:46:05 AM
Valid To:           Saturday, March 28, 2015, 11:46:05 AM
Basic Constraints:  Subject Type: End Entity
                    Path Length Constraint = 0
Key Usage:          Digital Signature
                    Key Encipherment
Enhanced Key Usage: Client Authentication
                    Secure Email
Netscape Cert Type: SSL Client Auth
                    S/MIME
Signing Algorithm:  SHA1-RSA
Signature:          (2048 bit binary value)

In the above, "DN" is short for Distinguished Name. There are two of them in a digital certificate - one to identify the subject (the certificate owner) and one to identify the issuer (the certificate signer). Distinguished Names are something left over from the X.500 Directory standard from OSI (early competitor to TCP/IP). Today X.500 survives only in the form of LDAP, which also uses DNs and X.509 Digital Certificates. X.509 was the "authentication framework" part of the X.500 Directory standard (intended for authentication of users logging into an X.500 server). The Public Key Digital Certificate was defined in X.509. This ISO standard is still available, but is quite expensive. Today most people use RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", May 2008. This RFC is from the IETF PKIX Working Group, who create standards for "Public Key Infrastructure using X.509".

A DN is similar to a multilevel, hierarchical nodename as used on the Internet, like server01.cebu.sixscape.com. With Internet style names, the fields are separated by periods and have only position (not names). With DNs, the fields (called RDNs, or Relative Distinguished Names) are name/value pairs(e.g. "E = This email address is being protected from spambots. You need JavaScript enabled to view it.", "OU = Admin"). They can come in any order, and are separated by commas. A given named field can also occur multiple times in a single DN, e.g. "OU=Atlanta, OU = Finance". The values of the fields in a DN can contain spaces (e.g. "L = Cebu City"). Unlike Internet hierarchical names, DNs can contain geographical information and a person's name.

There are many possible named fields in a DN, and most names have both short ("CN") and long ("commonName") versions. The most common field names used in Digtial Certificates are:

UID - userID - e.g. the account name on a computer

E - emailAddress - RFC 822 (SMTP) style email address

CN - commonName - usually a person's full name, but can also be a computer FQDN

OU - organizationalUnit - the group within the organization where the user works

O - organization - the company or agency where the user works

L - locality - name of the user's city, village, etc

S - stateOrProvince - name of the user's governmental unit between city and country

C - country - two letter code for user's country

There are several types of Digital Certificates, based on what the Subject DN contains, e.g. Server Certificate, Client Certificate and IPsec Certificate.

 

Server Certificates

A Server Certificate's Subject DN contains a Fully Qualified Domain Name of a particular computer in the CN (commonName) field, such as ws01.sixscape.com, although it could contain multiple FQDNs, or even a "wildcard", e.g. "*.sixscape.com". These are used on servers to enable SSL/TLS and provide server to client authentication (commonly used with HTTP, SMTP, LDAP, IMAP, POP, etc).

The applicant generates a public/private keypair (typically using RSA) and then creates a PKCS #10 Certificate Signing Request (CSR) which includes the server's FQDN, other identifying information, and the generated pubic key. They submit this CSR a Certification Authority (CA).

The CA verifies that the applicant has rights to use servers for that domain and company name, then creates a server certificate from the CSR, by adding the CA information and signing it using their intermediate private key (for their server certificate hierarchy). The signed certificate is sent to the applicant, who installs it in their server. Thereafter, any number of clients can make use of that single certificate to access the server securely using SSL/TLS (including server to client authentication).

 

Client Certificates

A Client Certificate's Subject DN contains a person's name (in the CN or commonName field) and typically their E-mail address. It may optionally include a UserID. These can be used for strong client authentication to an SSL/TLS server, for S/MIME email, for signing and/or encrypting digital documents, etc.

The applicant generates a public/private keypair (typically using RSA) and then creates a Certificate Signing Request (CSR) which includes the applicant's name, Email address, company name, etc as well as the generated public key. They submit this CSR to a Certification Authority (CA).

The CA verifies the information submitted in the CSR as being accurate and current. They then generate a Digital Certificate from the CSR by adding the CA information and signing it using their intermediate private key (for their client certificate hierarchy). The signed certificate is sent to the applicant, who installs it in their certificate store (a.k.a. certificate database)  on their computer, where various client software (e.g. IE, Outlook, Windows Live Mail, etc) can use it.

Unlike Server Certificates, where a single certificate can be used by all users of a given secure server, each user must be issued a distinct Client Certificate (with their name and email address). This is a much more complex problem.

 

IPSec Certficates

IPSec (Internet Protocol Security) is a scheme that can add simple authentication (weaker than digital signature, but better than nothing) and encryption to TCP/IP connections (at the IP layer, so it can be used with both UDP and TCP, and any application layer protocol). Unlike SSL/TLS (which is in the application layer), applications do not need to be modified or even know that they are being secured with IPsec. Unfortunately IPsec cannot work through NAT - it detects NAT (correctly) as an attack, since it checks for any changes in source or destination address and source or destination ports.

Unlike SSL/TLS, IPsec does not use digital certificates to establish a shared symmetric key. This is accomplished using another asymmetric key protocol, called Diffie-Hellman Key Exchange. IPsec can use a manually deployed "shared secret" during authentication, but this is not very secure or scalable. For real mutual authentication, IPsec requires an X.509 digital certificate on every secured node. These certificates include the IP address of the node in the CN (commonName) field of the subject DN. These are most commonly obtained via the Cisco proprietary SCEP (Simple Certificate Enrollment Protocol). Using X.509 certificates makes IPsec far more secure and scalable (assuming you can securely distribute IPsec certificates to every node). This distribution problem is very similar to the one for client certificates.

 

Sample Certificates and Viewer

This link allows you to download a Windows program to view PKI objects, such as certificates, CSRs, private keys and PKCS 12 files. Download it to your system, and run a virus checker against it. Assuming it is clean, run it to install ViewPKIObjects. This will install the application with a launch icon on your desktop, and in Sixscape Communications\ViewPKIObjects under Start / All Programs. When you launch the installed program, you will be able to view the details of the example certs below (or any PKI object saved to a file). This program is free and OK to distribute. It is a .Net executable (written in C#), so you will need at least .Net 4.0 framework installed on your computer. It should install the framework if it isn't already present.

ViewPKIObjects installer

 

The following links allow you to download various types of digital certificate to your computer. From there you can explore the details of each one with the ViewPKIObjects program above (or import them into your browser's certificate store by double clicking on the downloaded files and following the instructions).

The first one is an end-user client cert in the hughesnet.org client hierarchy. If you import this, it will not be trusted since I haven't provided you with the root and intermediate certs for this hierarchy. You can still import and view it, it will just not be trusted, and there will be no trust chain shown.

End_User_Client_Cert.crt

The following three certs are the root & intermediate certs, and an end-entity server cert from the hughesnet server hierarchy. If you install the root and intermediate certs in your browser certificate store (by double clicking on them), the server cert will be trusted, and you should see the trust chain up to the root.

Hughesnet_Server_CA_Root.crt

Hughesnet_Server_CA_Intermediate.crt

us1.hughesnet.org.crt