SSL Certificates 101

SSL (Secured Socket Layer) is a protocol that allows the data to be transferred across securely in the computer networks. Though SSL was one of the initial steps towards securing the data, as the technology advanced with leaps and bounce, in today’s world, what we refer to as SSL is TLS (Transport Layer Security). The most advanced version of SSL.

Let’s see why we need SSL Encryption and how it works. Before we get there, let's also agree that we will explore the following concepts like Symmetrical Keys, Mutual Authentication, Certificate Authorities, Digital Signature, Public and Private Keys with real-time examples and that way, I believe we can also connect to it easily. Most importantly, it will also make it easy for us to understand what went wrong with each approach and why it has to be replaced with the better version.

Meet John and Susan

John and Susan are a married couple and living happily. The unfortunate thing is, due to financial constraints, the couple couldn’t afford to buy a second car. They are forced to share the car they own together. They have decided to carry each of a pair of keys that came with the car. When John wants to use the car, he uses his key, and likewise, Susan uses her key when she wants to use the car.

The sad part here is, unlike John, Susan is a bit of careless person. She tends to lose her personal belongings due to her less careful behavior. The day came; she lost her car key, to make it worse, it is now in the hand of a bad person who chooses to steal her car and most importantly the valuables that John and Susan kept inside the car.

Though John happens to be one of the most careful people, due to the shortcoming of his wife, he has lost his car and the valuable things that were inside the car. The problem here is they shared the identical keys that will lock and unlock the car. When one of the keys is lost, the damage is for both the parties involved.

Symmetrical Keys Encryption

The problem faced by John and Susan is the exact problem with Symmetrical Keys Encryption too. When Computer A and B are exchanging data using the Symmetrical Keys to encrypt and decrypt data transferred over the network and when the key gets to the hand of a bad person, the security is compromised and the data can be stolen/manipulated. To illustrate this, let’s assume Warren wants to transfer X amount to his friend Charlie using Symmetrical Keys Encryption. When the security is compromised, the amount and to person account details can be modified while the data is being transferred over the network and the fraudulently bumped up amount can be transferred to the unintended person’s account. When the key is lost by any of the parties, the security of data is compromised. Very reason is the major drawback with symmetrical keys encryption.

Worried John and Happy-go-lucky Susan

Worried John came up with the solution of two non-identical keys. The first key only locks the car. The other one only unlocks the car. Also, he went ahead and made a duplicate copy of the key that only locks the car and gave it to Susan. Whenever Susan wants to go out, John will unlock the car for her; she can go around and when she is back home, all she will have to do is just lock the car. In fact, she can even leave the key in keyhole as it can not unlock the car. In a way, it addresses the tendency of losing the key by happy-go-lucky Susan. Whenever she is done with her trip, she can lock the car and throw away the key as it can only lock the car.

Public and Private Key Encryption

This is exactly what the Public and Private Key Encryption approach does. The key John gave to Susan is the public key which can only encrypt the data. The key that John kept with himself and uses to unlock the car is the private key which he doesn’t have to or want to share with Susan and he can keep it with himself securely. So, when Susan loses her key and that gets to the hand of bad people, it does no good for them because it can’t unlock the car. Likewise, the public key in the hands of bad people is no good as it can’t decrypt the data encrypted using it.

To address the shortcoming of sharing the identical keys (symmetrical keys encryption), the usage of Public Key and Private Key Encryption came into practice. Since the public key only encrypts the data and does not decrypt the data, it doesn’t have to be secured, and also as its name suggests it’s made publicly available.

Let’s go back and rerun the bank transfer scenario with Public and Private Key encryption. Warren sends the bank transfer request to his bank that is encrypted with the public key shared by the bank. When the public key gets to the hand of bad people, it is of no use for them as it can’t help them to decrypt and manipulate the data. The transferred data reaches the bank; the bank will use its private key (similar to John’s key) and read the transfer request details and complete the transaction. It’s a win-win situation for Warren and his Bank. Warren can be confident his data is secured and the bank can be sure that nobody could have tampered the data.

Now we know why Public and Private Key encryption is a widely used encryption method today.

Meet Smith and Sam

Smith and Sam are very good childhood friends and recently graduated youngsters too. Both passed out with good grades from two different universities. Smith graduated from a well-known university whereas Sam graduated from the university not even known by people living in the same city. They both moved to a nearby big metropolitan city to pursue their careers. Surprisingly, they both applied and got a high paying job from the same MNC. As part of the recruitment process, the company does its background verification that includes the degree certificate evaluation too. Certificate evaluation is nothing but an authenticity check on the degree certificates; they are real and issued by the corresponding universities only.

Smith got his background verification cleared the very next day whereas Sam did not. Upon reaching out to the recruitment department, Sam was informed that the university from where he was graduated was not present in the company’s master list of universities that they have been maintaining for years. Also, he was told, they would have to take some extra effort to clear his degree certificate evaluation.

Eventually, Sam got his background verification cleared a week later and the recruiting MNC also went ahead and added his university details in their master university list. So, the next person who graduated from the same university will be cleared immediately as the university is now present in the vetted university master list. Here the intention of the MNC is to verify the authenticity of the degree certificate and the issued university really exists. Since Smith’s university was in the master list, he was through immediately, but Sam had to wait for a week to be cleared since his university was not there initially and it took additional effort for MNC to verify and add the university to the master list.

Digital Signature and Certificate Authorities

So far, we have seen Symmetrical Keys Encryption and how the Public and Private Key approach overcame the drawback of Symmetrical Keys Encryption. Now, we know the public key is something that is made publicly available and people could use to send the encrypted data to the receiver and the receiver uses the corresponding private key to decrypt and get the message. Going back to the bank transfer example, when Warren wanted to request the bank transfer, he used the public key of the bank and encrypted information and sent it to his bank. He was sure it couldn’t be decrypted by anybody other than the bank. But now, the question that comes to his mind is

Since the public key is not intended to be secured, how can I be assured that the public key I’m using really belongs to my bank???

Now, Warren wants to be 100% sure that the public key he is using belongs to his bank. This is very similar to the authenticity check performed on the degree certificates of Smith and Sam. The MNC wanted to be sure that the certificates are from the issued university and the university really exists. Warren is in a similar situation once MNC was in. MNC took care of it by doing a degree certificate evaluation to make sure the certificate was from the real university by validating it against the vetted university list they had.

To address the issue of verifying the public keys, the Certificates and Certificate Authority came into the picture.

Certificate Authority is a third party agency that digitally signs the public keys and issues a certificate that contains nothing but the public key + digital signature of the CA (Certificate Authority).

Digital Signatures of Certificate Authorities are very similar to the master list of universities that the MNC maintained in their database.

There is a bunch of well-known Certificates Issuing Authorities like IdenTrust, DigiCert, GoDaddy in the world that they are recognized globally and their digital signature certificates are stored in the trust stores of almost all the widely used browser, OS and keystores of Java packages too.

That said if any organization that wants to have a secured connection with their clients will take their public key to any one of the above-mentioned Certificate Authorities (CA) and get it digitally signed. As we already know, all Certificate Authority does is signs the public key, it issues back the digitally signed certificates to the requested organizations. Then the organization shares the certificate with its clients to establish a secure connection.

Going back to Warren’s authenticity concern of trusting his bank’s key. Whenever Warren wants to do a bank transfer, he opens up his browser and hits the URL of the bank which is HTTPS enabled for the secured connection. The first thing that happens is the SSL handshake which includes server sending its public certificate to Warren’s browser. The certificate has a public key and the digital signature of the Certificate Authority. Since most of the browser has a built-in trust store that contains the digital signatures of most of the globally recognized Certificates Authorities (CA), the certificate is verified automatically by the browser, and the bank page is shown to the user. In other words, the browser took care of Warren’s concern of verifying the received certificate (bank’s public key signed by CA) by checking the certificate signature against the build-in signatures of globally recognized CAs in browser’s trust store.

Post certificate check, the Session Key is sent back by the client browser encrypted using the received public key. And the rest of the data exchanges between server and client is encrypted and decrypted using the session key. We will save this topic for another day.

Some organizations don’t go to Certificate Authorities to get their public key digitally signed, instead, they self sign it. Such certificates are called Self-Signed Certificates. Since it’s is self-signed, unlike signatures of Certificates Authorities, it won’t be available in the built-in trust stores of the client browser, OS, or Java package. When client browser encounters such self-signed certificate, it will start showing the warning message to the user that it couldn’t verify the digital signature of the received certificate against the built-in signature certificates, please continue with your own risk (what we typically see in the browser for some of the sites we visit and we have to hit ‘proceed further’ button to continue).

Also, it’s very similar to the situation that MNC ran into when they couldn’t find the university of Sam’s degree certificate in their database. The MNC took the extra effort to verify the certificate and university. Likewise, Warren has to make sure that he can trust the site whenever his browser starts showing such a warning message. When Warren feels comfortable with the site and to avoid such warnings in the future, he can choose to store the certificate of the site in his browser’s trust store. It’s very similar to what MNC company did after authenticating Sam’s degree and they went ahead and added his university information in their master list; so that, next time it’s available in their list to preform degree background checks for future candidates from the same university.

If the client alone validates Server’s certificate it’s a One-way SSL check.

If both parties (server and client) validate certificates of each other, it becomes a Two-way SSL check or Client Authentication or Mutual Authentication. In that case, the client will also need to send its certificate to the server. Two-way SSL check is not very common and it’s enforced only when a server wants to restrict itself to serve the requests from a limited set of clients. If the client doesn’t have a certificate, the client has to create one using tools like OpenSSL and gets its certificate signed by Certificate Authorities (CA), or the client can self sign it.

When the client self signs instead of getting it from CA, the signature won’t be available in the trust store of the other person. So to avoid SSL authentication error, the client could share his certificate with the other person beforehand to have him include his certificate in their trust store. Using tools like Keytool or OpenSSL server team needs to add client self-signed certificates in their trust store since it’s not in the built-in list. In the case of CA-signed, this additional effort of adding a certificate to the trust store is not required.

Summation of our learning

1. What is SSL and why it’s needed.
2. What are Symmetrical Keys encryption and the problem with it.
3. How Public and Private Key encryption overcame the Symmetrical Keys problem.
4. What is the role of Certificate Authority.
5. What is the Trusted Cert Stores.
6. What is One-way and Two-way SSL authentication or Client Authentication or Mutual Authentication.

Fellow Java Folks

Though my intention is to stay with the basic concepts, just only for Java Developers who want to communicate to secured URLs from a Java program. When the certificate is non-CA signed, the self-signed certificate needs to be added to the underlying Java Keystore by using keytool command. Many would have already done it. Some who have never done it will do it with good understanding since you know it now. If it’s CA issued, you don’t need to add it to the keystore as the signatures of Certificate Authorities are already packaged in keystore (also it gets updated with a newer version of JDK).

If you do not want to add it to the Keystore and want to have the certificate info as part of your java project itself, you can package the certificate in JKS or PKCS12 file put in the classpath and tell your code to refer to it when establishing the secured connection using HTTPClient.

That’s all for today about SSL certificates and Encryption. Hope this helps you to understand the basics of the SSL certificates and its usage.

Happy Learning!!!