Welcome to the second article in this series about the certificate authority. In the previous article, we began with an introduction to cryptography and then moved on to the two forms of cryptography: symmetric key and asymmetric key. We then delved further into asymmetric key cryptography and finally made a case for why we need the certificate authority and what it is.
In this article, we will look at the certificate enrolment process with a certificate authority and how this certificate is used for authentication purposes.
Certificate Enrolment Process
As we have said, entities can use the digital certificates obtained from the certificate authority to prove their identities and, to get these digital certificates, there’s an enrolment process to be followed.
To begin the enrolment process, the applicant will usually generate a key pair, i.e., a public key and a private key. As we discussed, the private key is kept secret and is NEVER sent across the network or in any message; the public key, on the other hand, can be distributed.
Next, the applicant will generate a certificate signing request (CSR) to be sent to the certificate authority. The CSR is a message in which the applicant basically says “I need you to issue me a digital certificate that confirms that I am who I say I am.” The format of the CSR varies but the most common format used is the PKCS #10, which is the certification request syntax developed by RSA Security.
The CSR contains information about the identity of the applicant (e.g., the distinguished name of the applicant, the public key of the applicant, a digital signature which is the hash of the request encrypted with the applicant’s private key, and the hashing algorithm used for creating the digital signature).
This request is then sent to the CA.
When the CA receives the request, it must first verify that it has not been tampered with. To do this, the CA will take the public key of the applicant from the request and decrypt the digital signature.
Note that in the above diagram, the plus sign does not mean the mathematical function; it just means that a decryption process is performed on the digital signature using the public key. The CA then uses the hash algorithm also contained in the CSR and creates its own hash of the request—let’s call this Hash(calculated). The request is valid if the Hash(request) is the same as Hash(calculated). According to the RFC that specifies the PKCS #10 format, the reason for the digital signature on the CSR is to ensure that an entity does not request a certificate using another party’s public key.
When the CA confirms that everything is correct, it can then issue a digital certificate to the applicant. To allow an entity to detect any modification to the digital certificate, the CA will sign that certificate using its private key. The digital signature is still the same concept: A hash is created of the digital certificate and encrypted using the private key of the CA. If the digital certificate is altered in any way, the decrypted digital signature of the CA will not match the hash of the altered digital certificate.
An example of a digital certificate (X.509 format) for Facebook is shown below. Notice that it contains various items of information such as version, serial number, details about the issuer (in this case, VeriSign), the validity period, the subject details, the public key, and the digital signature at the end.
Using the Digital Certificate for Authentication
Now that the applicant (Bob) has obtained his digital certificate from the certificate authority, he can present this certificate as a means of authentication to anyone who requests it. So, instead of sending only his public key, Bob will send the certificate which maps his identity to his public key. Let’s look at an example of this process.
In this example, Bob and Alice want to communicate and Bob has to authenticate himself to Alice. They mutually trust the same CA. This mutual trust is important because Alice must be able to verify that the digital certificate presented by Bob was indeed issued by a trusted CA. To begin the process, Bob will send his digital certificate to Alice.
Upon receipt of Bob’s digital certificate, Alice will need to verify the certificate by first checking that she trusts the issuer. If the certificate was issued by an unknown or untrusted CA, the user will get a warning at this point; something like the image shown below.
Let’s assume that Alice trusts the CA that issued Bob’s certificate. This means she will also have the public key of that CA. She will then proceed to verify Bob’s certificate by decrypting the CA’s digital signature contained in the certificate. Since this digital signature was created by encrypting a hash value with the CA’s private key, only the CA’s public key can decrypt that signature.
Alice will compare the decrypted hash with the one she obtains by hashing Bob’s digital certificate. If these match, then Alice knows that Bob’s certificate has been issued by a trusted CA and this certificate has not been tampered with. She can therefore believe that she is talking with Bob and can extract his public key from the digital certificate for other purposes. This completes the authentication process. Note that during this process, if required (or configured), Alice may also check that Bob’s certificate has not been revoked.
You will notice that the process is dependent on the fact that both entities must trust the same CA. This means that there must be some form of pre-authentication of the CA beforehand. It may leave you wondering how we are able to connect to many websites securely without any pre-authentication of their CA. This is because there are some highly trusted CAs in the world, known as Root CAs, like VeriSign, Entrust, and GlobalSign and the certificates of these root CAs are installed by default with many web browsers.
To check the trusted root CAs installed on a Windows machine, follow these steps: Open “Run” and type “mmc” and click OK.
When the window opens, select “Add/Remove Snap-in” under the File menu.
Select “Certificates” and click on “Add.”
Choose the account for which you want to manage certificates.
Click on “Finish” and notice that the “Certificates” snap-in has been added.
Click on “OK” and you will see the “Certificates” link on the left-hand pane.
Navigate to the “Trusted Root Certification Authorities” folder and click on “Certificates” to view the root CAs.
This brings us to the end of this article, in which we have taken a deeper look into the certificate enrolment process by which an applicant requests and receives a digital certificate from a certificate authority. We have also looked at how this digital certificate is used for authentication purposes. Going forward, we will look at how to configure the Cisco router and ASA to act as certificate authorities.
I hope you have found this article insightful.
References and Helpful Resources
The Certificate Enrollment Process: http://www.tech-faq.com/the-certificate-enrollment-process.html
Certificate Signing Request: http://en.wikipedia.org/wiki/Certificate_signing_request
RFC 2986: http://tools.ietf.org/html/rfc2986
Digital Certificates: http://technet.microsoft.com/en-us/library/cc962029.aspx
CSR Decoder and Certificate Decoder: http://certlogik.com/decoder/