Download and save as ppsx: Certificate Enrollment Process

, , ,

As I have promised here you are next post from the PKI scope. Following example presents way of communication between user A and B with digital certificates. It will be one way communication example so user A sends data to user B. The same process takes place in opposite direction. It’s not easy and smooth but rather hardcore and kiler theme 😉 so it’s good to have fresh and open mind to read it. Are you read? Please go ahead.

The following process diagram will be very helpfull to understand the clue, step by step description below:



  1. User has own keys pair (public/private keys). Public key A (related to private key A) has been signed and authorized by the CA before (certificate enrolment process that is has been described Public Key Infrastructure – certificate enrolment post).
  2. User A uses public key B and encrypts Message that will be sent to the user B. Public key B has been taken from B’s certificate.
  3. Additionally, user A takes the same clear Message as input and does SHA (or MD5) hash function – Message# is output of this algorithm.
  4. Message# is then encrypted by the Private key A. Digital Signature of the user A Message is output of this process.
  5. The Digital Signature is added to the encrypted message.
  6. Above decrypted message and User A Certificate is send to the User B. User B gets a encrypted message and start decryption and authentication process. First user needs to be sure that Public key A that will be used for user’s A message authentication is true Public key of user A.
  7. To verify it, User B takes the Public key CA from the CA Certificate (that has signed User A’s Data, CA has issued the User A Certificate during certificate enrolment process) and decrypt the Digital Signature CA that is embedded into User A Certificate, Data# A is output of this process. Additionally user B downloads most up to date Certificate Revocation List (CRL) from CA to verify if User A Certificate has not been canceled and is still valid.  
  8. User B takes User A Certificate a does the same hash function (like CA has done for User A Data), Data# A is output of this process. User B takes this output and compares with Data# A (that has been produced in point 7) to confirm User A identity. If the hash outputs are the same it means that User A Certificates is real so Public key A is confirmed and can be use for communication.
  9. User B takes Public key A and decrypts Encrypted Message that has received. Clear, unencrypted message is output.
  10. To confirm that Message is real and has not been changed on way, User B does the same hash function (encryption and authentication functions have been negotiated at the beginning of the communications process, for example in case of IPsec it takes place in Phase 2 of IKE negotiation), so unencrypted Message is a input and Message# is output of this process.
  11. Then User B takes own Private key B and decrypts Digital Signature of the Message that has been added by the User A. Message# is output of this process.
  12. Message# from point 10 and Message# from point 11 is compare and if are the same then User B is sure that Message has not been changed and is exactly the same like User A has sent.

Some time ago when I was learning about PKI (Public Key Infrastructure) I searched for any process diagram that shows and visualyze step by step ceriticate enrolment process by CA or other encryption or authentication steps in the PKI enviroment in simple and detail manner. Because I have not found any have decided to draw it and explain the process, hope will help to understand the issue.

Before we will discuss the ceriticate enrolment process we have to explain the background shortly. OK so let’s start.

The base of the PKI is the concept of Asynchronous Keys. Asynchronous Keys is the encryption algorithm that can be use to secure transport data over unsecure connectivity, additonaly due to the nature of algorithm authenticate identity.
The idea of algorithm is based on two differtent keys (public and private key) that are mathematical related to each other, where private key derived from the public key. Message encrypted by recipient’s public key can only be decrypted by the corresponding private key (we can encrypt the message only by related key), and vice-versa, message encrypted by the owner’s private key can be only decrypted by the owner’s public key that is commonly available. Based on first case we achive data intergrity and confidential because only owener of private key will be able to decrypt the message and properly read the data, based on second one, reciver of the message can authenticate the sender because once decrypt the message and properly read a data, he knows that data have been sent by proper source (owner of private key). Above algorithm has revolutionized the encryption and authentication way. The only one problem was a public key distribution, this what the PKI is about.

Once we generate public/private key pair, we have to make the private key public available and the get global authority confirmation that the private key belong to as (at least it’s good to have confirmation from globally trusted source). Here Certificate Authority (CA) comes in to play. We have a lot of nice institution like VeriSign or GlobalSign and others that we can trust. The primary task of them is to confirm that generated public key belongs to us so can be used to exchange message in secure way.

Ceriticate enrolment process
I will explain the process based on the following example with user A (instead of user we can have any device: router or server, simple end point that will physically encrypt data).


1. User A generates pair of keys: public key A and private key A.
2. User A sends to the CA, own public key A with additional details that will identify user A like name, surname, departament city, country, e-mail address etc.
3. CA verifies user A data, next takes user A data and public key A as input and do SHA (or MD5) hash function – Data# A is output of this alghorith.
4. CA then uses own Private key CA and encrypts Data# A, Digital signature of the CA is output of this process.
5. User A Data, Public key of A, Digital signature of the CA, and specific details assigned by the CA like certificate serial number, issued and valid date, point of CRL distribution (and many more) creates User A Certificates.
6. Users A can get certificate and start use it to encrypt and authenticate data.

I hope this post will helpfull and clarify certificate enrolment process. If you have any comments please let me know. In next post I will discuss the encryption and authentication based on the digital certificate.