Digital Certificates and Public Key Infrastrucure

The World Wide Web which originally was developed to share only research and academic applications data over the network have today evolved a lot and is overwhelmed with e-commerce,banking and financial and government operation application. Where the research and academic data over HTTP was not vulnerable to any security threat, the data that present time's application transfer to and fro is highly sensitive, confidential and vulnerable to security attacks. So HTTP was extended further to a secured version HTTPS to ensure the authentication and secure transmission between two ends. The HTTPS uses the Digital certificate and Public Key Infrastructure to transfer the dtaa securely. So what are these  Digital Certificates and Public Key Infrastructure.

Digital Certificates

Digital certificates, similar to identification cards, are electronic credentials that are used to certify the online identities of individuals, organizations, and computers. Just like a identification cards, a digital certificate provides identifying information, is forgery resistant and can be verified because it was issued by an official, trusted agency. The certificate contains the name of the certificate holder, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting messages and digital signatures) and the digital signature of the certificate-issuing authority (CA) so that a recipient can verify that the certificate is real.

To provide evidence that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority. Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify certificates that the CAs have issued and signed. When PKI is deployed internally, digital certificates can be self-signed. Most of digital certificates conform to the X.509 standard. 

A Sample Digital Certificate

The digital certificates may be issued to both client and server to communicate over HTTPS but there is some difference in both of these.

Server Certificates

Server Certificates are basically used to identify a server. Characteristically this certificate is issued to the hostnames, which could be a host reader – for example Microsoft or any machine name. The server certificates serve the rationale of encrypting and decrypting the content. A web browser reaching the server, and validates that an SSL server certificate is authentic. That tells the user that their interaction with the web site has no eavesdroppers and that the web site is exactly who it claims to be. 

Client Certificates

Client certificates as the name implies are clearly used to identify a client to a respective user, which means authenticating the client to the server. Some web applications ask the client to prove their identity and authentication to communicate with the server. In that case client need to provide their Client Certificate to the Server. The client certificate is not at all used for data encryption or decryption because it is for user’s identity.

Both SSL certificate (server) and client certificate encompass the “Issued to” section. Here, for SSL certificate the “Issued to” section’s value will be the hostname for which it has to be issued and for the client certificate, it will be the user identity or the user name.

Public Key Infrastructure

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.

Without PKI, sensitive information can still be encrypted (ensuring confidentiality) and exchanged, but there would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

A typical PKI consists of hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates. Digital certificates are at the heart of PKI as they affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.

A typical PKI includes the following key elements:

• A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities
• A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root
• A certificate database, which stores certificate requests and issues and revokes certificates
• A certificate store, which resides on a local computer as a place to store issued certificates and private keys

A CA issues digital certificates to entities and individuals after verifying their identity. It signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate. CAs use this trusted root certificate to create a "chain of trust" -- many root certificates are embedded in Web browsers so they have built-in trust of those CAs. Web servers, email clients, smartphones and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.

Along with an entity’s or individual’s public key, digital certificates contain information about the algorithm used to create the signature, the person or entity identified, the digital signature of the CA that verified the subject data and issued the certificate, the purpose of the public key encryption, signature and certificate signing, as well as a date range during which the certificate can be considered valid.

So this is how the certificates the PKI helps in verification of certificates exchanged between client and server. Now when we know what are the Digital Certificates and how those are verified with PKI lets take a look at the SSL Handshake that takes place before the client and server startsto transfer the actual data to each other over a HTTPS/SSL session.

SSL Handshake

An SSL connection is always initiated by the client. At the beginning of an SSL session, an SSL handshake is performed. This handshake produces the cryptographic parameters of the session.

1. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.
2. The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number.
   
   Note: The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.
3. The server sends its digital certificate. (The server uses X.509 V3 digital certificates with SSL.)
   
   If the server uses SSL V3, and if the server application (for example, the Web server) requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.
4. The server sends a server "hello done" message and waits for a client response.
5. Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable.
   
   If the server digital certificate is self signed and cannot be verified by any CA the Browser display the message to the User and asks for how to proceed. Usually it provides an option to add this address in exceptions list to verify certificates if user trusts the server.
   
   If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory.
6. The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server. If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.
   
   Note:An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.
7. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys.
8. The server responds with a "change cipher spec" and a "finished" message of its own. 
9. The SSL handshake ends, and encrypted application data can be sent.

Secure Sockets Layer V3 can use server digital certificates as well as client digital certificates. As previously explained, server digital certificates are mandatory for an SSL session, while client digital certificates are optional, depending on client authentication requirements.


The public key infrastructure (PKI) used by SSL allows for any number of root certificate authorities. An organization or end user must decide which CAs it will accept as being trusted. To be able to verify the server digital certificates, the client must have possession of the root CA digital certificates used by servers.

SHARE