Community Tribal Knowledge Base

 View Only
last person joined: 5 days ago 

Digital Certificates - Part 4 

Jan 16, 2012 06:14 PM

Now that we understand the structure of a PKI and how certificate authorities work, let’s look at how an end user gets a digital certificate.  This could include a company obtaining a digital certificate to be used for an SSL website, or an individual looking for a certificate to sign emails or other documents.  I will use for this example an old copy of my own personal digital certificate, used to digitally sign emails.  You can find several public CAs that offer these sorts of personal certificates, typically for a cost of around $19.95 per year.  For this price, they will do some simple verification of identity that involves checking an email address and a phone number.  For a higher fee, CAs will verify additional information such as a business license, a physical address of a company, employment status, and other details that increase confidence in identity.

 

This example from GeoTrust begins the process by asking for some personal information:

 

 Certs-05.png

 

A small window opens up and prompts the user to generate a password.  This password is used to generate a public/private keypair, which the GeoTrust server stores.  It is important to remember the password – it will be used again later.

 

 Certs-06.png

 

After providing payment information, GeoTrust sends an email to the supplied email address and requires the user to validate the email address by clicking on an HTTP link.  Next, the GeoTrust system calls the provided phone number and requires that the user validate the phone number as well.

 

Once identity verification has been completed, the GeoTrust server takes the user’s public key along with information such as name, email address, phone number, and validity period, and generates a Certificate Signing Request (CSR).  The CSR is fed to the actual CA server.  The CA server takes all supplied information, puts it into an X.509 file format, and signs the file using its private key.  Note that the CA server was never given the user’s private key – the private key is not part of the digital certificate and thus is not required by the CA server.  Depending on the capabilities of the operating system you are using, the private key may have remained on the local computer the whole time, and may even be protected by specialized hardware called a Trusted Platform Module (TPM).

 

The user downloads the certificate and private key together in a file format known as PFX or PKCS#12 and installs this certificate into the operating system or email client.  Looking at the certificate below, we can see that it was issued by the CA server known as “GeoTrust True Credentials CA 2” and that it is valid for some specific purposes such as protecting email.  It is not valid, for example, to be used as a CA certificate itself, and thus cannot be used to issue additional certificates on behalf of GeoTrust.  We can also note the presence of “You have a private key that corresponds to this certificate” – this line indicates that this certificate can be used to digitally sign documents or data.

 

 Certs-07.png

 

Looking at the certificate details, we find information inserted into the Subject field about how identity was verified.  This lets the user of the certificate determine how much trust should be given to it – a certificate where a user physically presented himself and a passport at the CA’s office will be given a higher degree of trust than a simple email/phone validation.

 

 Certs-08.png

 

Going back to our email example from earlier, Randy (after obtaining his own certificate) can now digitally sign his email to Josh using his private key.  But now, instead of attaching his public key to the email, he attaches his digital certificate.  Josh receives the digital certificate, and his system looks for a matching CA certificate for the issuing CA.  Finding it, his system uses the CA’s public key to verify Randy’s certificate and determine that it is valid.  Next his system extracts Randy’s public key from the digital certificate and uses it to check the integrity of the email message.  Finding that the integrity check passes, we can be sure that Gregor, our man in the middle, did not modify the message in transit.

 

In our final article, we’ll cover certificate file formats and certificate revocation.

Statistics
0 Favorited
2 Views
0 Files
0 Shares
0 Downloads

Related Entries and Links

No Related Resource entered.