Public Key Infrastructure: Basics about digital certificates (HTTPS, SSL)

The usage of digital certificates for encrypted communication and lettering of data like email is a top item on most companies’ wish list. Surprisingly many companies still don’t use it.

Therefore I want to give you a brief overview of the technical method that is applied when you use digital certificates. In my example I am using the secure, encrypted access to a website „webmail.company.com“ via HTTPS protocol.

The method is based on three pillars:

• A generally approved and trustworthy authority: the central certification authority
• The private-public-key encrypting method
• The digital certificate which confirms the setting of a subject or object.

Secure and encrypted access to a website with digital certifcates

Interaction between the three pillars shown on an example

We want to provide a WebMail-Site for our coworkers with encrypted communication via the internet. A public DNS-entry for the webmail.company.com is already registered. We are now only missing a certificate verifying its authenticity. This brings the central certification authority into the game. There we will have our digital certificate issued. The central certification authority is also known as master certificate issuance authority or e.g. GlobalSign, VeriSign or Thawte.

This leads us to the second pillar of the certification-process: the private-public- key-encryption. Because it is only a means here, I am only going to explain its special eligibility for certificates only briefly. There a quite some books dealing solely with this encryption process as it plays a central role in cryptography. As the name “private-public-key” lets one suspect, there are not one but two keys for encrypting messages. One is private and secret and will never be handed to an outside party. The other is, you could say, its extroverted twin and made to be thrown into public. And why can you deal so carelessly with the public key? It does not provide any information about the private key.

This opens two very special possibilities:

1. Messages encrypted with the public key can only be decrypted with the private key. That means only the recipient can read the for her or him encrypted message.
    
2. Messages encrypted with the private key can only be decrypted by the public key. As we can assume that the private key exists only once, the sender can be identified unambiguously. This makes it possible to build up a signature-procedure.

The third pillar in our example, the property verified by the digital certificate, is the DNS-address “webmail.company.com”.

The certification process – employing all necessary parts

1. Generate a certification-request for our web-server. With this request, the private-public-key-pair is generated for our WebMail-Site. The private key stays with us. Besides the public key, the request-form also includes our DNS-web-address and some other information like the location of our server.
    
2. The finished certification-request is sent to a master certification authority of our choice to issue a certificate.
    
3. The master certification authoritycertification authority issues the certificate using our information and signs it with a private key. The digital certificate contains an expiration date and information about where to find both master- certificate and certificate revocation list.
    
4. The complete digital certificate is sent back to us and we transfer it to our web-server. This enables the encrypted communication with our WebMail-site.
    

As you probably noticed, the private key was never been given to an outside party throughout the whole process. Naturally that’s essential to the process which builds on the trustworthiness of the private key. In case it is not secure anymore, it cannot be guaranteed that messages can only be decrypted by their recipient and signed by their sender.

The development of an encrypted communication channel with our site webmail.company.com now runs according to a defined certification checking- and key exchange process.

1. Check authenticity of the digital certificate

1. The web browser sends a first request to our web server on the address: https://webmail.company.com.
   Using HTTPS, we indicate to build up an encrypted communication to the web-server.
    
2. The web server transmits our digital certificate to the browser which proofs the authenticity of the address webmail.company.com.
    
3. The browser checks the authenticity of the digital certificate. For this, all issuing certificates in the certificate-chain up to the master-certificate are identified. In our case this is only one. Usually certificates are issued by minor issuance-authorities and not by the master-certification-authority. All certificates are mostly contained in the CryproAPI-cache of the computer and can be retrieved by the internet-browser. Should that not be the case, they can be reloaded via the Authority Information Access (AIA) which is deposited in the web-server.
    
4. When all certificates in the chain are identified, it is checked whether the digital certificate is still valid or not.
    
5. After that, the Certificate Revocation List (CRL) is checked for every certificate whether it is blocked or not. The URL is contained in the certificate. Starting with Windows Server 2008 the Online Certificate Status Protocol (OCSP) is supported. With an OCSP-responder the status of the certificate can be requested promptly because a CRL is only updated in a limited time frame.
    
6. In case the address in the certificate matches with the web-address and purpose (web-server) and the information is verified by the certificate-signature, the digital certificate is accepted as valid and the encrypted channel can be established.

2. Exchange of the keys

1. The web browser generates a symmetrical key with which the data-traffic between web-server and internet-browser is encrypted for the duration of the session. The private-public-key-process requires considerably processing power. That is why it is only used for the exchange of the actual data-key. The key being symmetrical means that it is employed for both encryption and decryption to save power. Because it is only used for the current session it is short-lived and not very prone to spying.
    
2. The internet browser encrypts the data key with the public key of our web-server from the digital certificate. This package is then sent back to the web-server.
    
3. Only our web server is able to decrypt the data key with the appropriate private certificate key. All further communication with the internet-browser happens via the exchanged data key.
    
4. Because the internet browser can be sure that the web server only uses the data key the communication to the web-server is now secure.