In the previous posts, you saw how hashing algorithms and cryptography creates digital signatures, allowing to identify who sends a message and its integrity. However, we cannot communicate in a two way yet.

Those posts left two unanswered question:

How does John share the key with Mary in a safe manner?

How can Mary and John communicate securely in a two way fashion?

Digital Certificates and SSL/HTTPs answer both questions.

TRY IT YOURSELF: You can find the source code of this post here.

Web Security Series

• Part 1: Authentication and Authorization
• Part 2: Hashing – Digest
• Part 3: Symmetric and Asymmetric Cryptography
• Part 4: Digital Signatures
• Part 5: Digital Certificates and HTTPs (You are here)
• Part 6: OAuth2 and OIDC

The Problem

In the previous posts, you faced an attacker who captures the symmetric key used to communicate Mary and John, when John tries to share the key with Mary, as follows:

The toxic ex-boyfriend captures the key and save it. Of course, he allows the key to flow to Mary, so, when John and Mary start to communicate, the ex-boyfriend can decrypt the message, and change them if he wants. This means, John and Mary can communicate in a two way street, but, this is insecure if the key is leaked.

Now, using asymmetric keys, Mary generates a pair public and private keys, and wants to share the public key with John as follows:

The toxic ex-boyfriend captures the key and save it. Of course, he allows the key to flow to John, so, when John and Mary starts to communicate, the ex-boyfriend tries to hack the communication. If Mary sends a message to John, the exboyfriend will be able to read the message, as she encrypts it with her private key, and the exboyfriends captured the public key, however, if John sends a message to Mary, the exboyfriend cannot read John’s message, as the exboyfriend doesn’t have the private key to decrypt the messsage.

In the asymmetric key case, at least, John can communicate partially safe with Mary, but she cannot communicate safe with John.

We faced two problems here: how to share in a secure manner the key and how to allow a two way communication between parties.

Let’s talks about digital certificates and SSL/HTTPs.

Digital Certificates Overview

A Digital Certificate, know also as a public key certificate, is a document used to prove the ownership of a public key. This document contains the public key of an entity that I want to communicate to.

The certificate is issued by a Certificate Authority (CA). The CA is responsible of signing and issuing certificates. CAs are key, as everyone trusts them, so, every certificate issued by a CA, is typical accepted as safe.

Now, using Mary and John relationshipt, let’s see how Mary requests a new digital certificate to a CA:

First, Mary generates the pair public and private keys. After, she sends her public key (plus other information) to the certificate authority. The CA creates a signature, with his private key, using Mary’s information and public key, and generates a new certificate with the signature, and Mary’s public key. Finally, the CA sends the new certificate to Mary.

NOTE: Of course, this process is more complicated than that, this is just a simplification as we don’t need to know every detail at this point.

Now, let’s see what happens when John tries to communicate with Mary:

John has access to the CA public key. The CA public keys are open available, everyone can get them. After, John tries to talk with Mary, but, she responds with her digital certificate. With the certificate, John needs to validate its authenticity:

John uses the CA public key, and Mary’s public key inside the certificate, to verify the signature. If that signature is valid, Mary’s public key is correct. As the certificate was signed by a trust CA, John can use this public key without fear, as shown below:

John encrypts messages using Mary’s public key and only her, as she has the private key, can read them.

Digital certificate helps to share public keys in a safe manner, but, we cannot communicate in a two way yet. Let’s see how SSL/TSL/HTTPs helps here.

SSL/TSL/HTTPs Overview

Digital Certificates solves the sharing key problem, but, we still need to communicate in a two way manner.

As John now has the confidence of having Mary’s public key, he can share information with her in a safe manner. So, what if he shares another key, as shown below:

John generates a symmetric key, and encrypts it using Mary’s public key. Afterward, John sends the encrypted message to Mary, as shown below:

John sends the encrypted symmetric key to Mary, and she uses her private key to decrypt it, obtaining John’s symmetric key. As both have the symmetric key, they can use it to send messages back and forward, in a two way, as shown below:

Remember, if the toxic ex boyfriend has Mary’s public key, he cannot read the messages, as the messages are encrypted by John’s symmetric key, and that key, was never exposed.

This is how SSL/TSL/HTTPs works at high level, of course, it is more complicated than that.

NOTE: Why do we choose to share a symmetric key instead of an asymmetric key? well, remember that symmetric keys are faster to encrypt and decrypt than asymmetric keys. As this process usually is done by connection, for instance, each time you click in a secured web page, it is better to be fast.

Certificates, HTTPs and Web Browsers

Now, where can I find examples of this process? well, everywhere, actually, into this same site coderstower.com. Let’s map some concepts we have seen and coderstower.com site:

• Web Browser: This is John, the entity who wants to communicate to coderstower.com.
• coderstower.com: This is Mary, the entity John wants to communicate to.

Do you want to see the digital certificate? well, you can find it as shown below:

There, you see that the connection is secured, that means, it is HTTPs, and every message is sent encrypted. Also, you see the Certificate as Valid. If you click there, you will see something like the following:

In that digital certificate, you can see issued and issuer information, plus, the signature. The Certificate Authority is Let’s Encrypt Authority X3.

Java Example

Let’s discuss how digital certificates are handled in Java.

Java Trust Certificates

Java has a cacerts.jks file which keeps the Certificate Authorities certificates it trusts.

By default, cacerts has a lot of valid Certificate Authorities, so, if you try to connect to a HTTPs server, and its certificate was issued from a known Certificate Authority, Java will connect fine.

However, if you create your own digital certificate, or you have your own Certificate Authority inside your organization, Java won’t trust that digital certificate, so, Java will throw something like the following:

javax.net.ssl.SSLHandshakeException: 
           sun.security.validator.ValidatorException: PKIX path building failed:                
           sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

To fix that issue, you will need to add the digital certificate to your JVM, so, the JVM trusts your custom certificate, using the keytool, as follows:

java-home/bin/keytool -import -v -trustcacerts -alias server-alias
-file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

What this command does is, telling the JVM that she must trust the server.cer certificate. This is pretty common for web servers like Glassfish or similar, when you have custom digital certificates.

Also, you can point your JVM to a defined keystore. A keystore is a set of certificates. You can add these environment variables when you start the JVM:

-Djavax.net.ssl.keyStore=your/path/to/keystore.jks
-Djavax.net.ssl.trustStore=your/path/to/cacerts.jks

Load a X509 Certificate

If you need to load a X509 certificate from Java, you can use the Certificate class, as shown below:

  @Test
  public void load()
          throws CertificateException, IOException {
    CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");

    X509Certificate cert = (X509Certificate)certificateFactory.generateCertificate(
            Files.newInputStream(Path.of("src/test/resources/coderstower.cer")));

    assertThat(cert).isNotNull();
    assertThat(cert.getPublicKey()).isNotNull();
  }

Using the CertificateFactory, you can load a X509 certificate and get the public key.

Did We solve the Open Questions?

Yes, we have now enough information to anwser the open questions:

How does the destination (Mary) know if a message and its hashing was modified after the origin (John) deliveries it?

We use digital signatures, putting together hashing and asymmetric algorithms.

How does John share the key with Mary in a safe manner?

They use a digital certificate issued by a certificate authority.

How can Mary and John communicate securely in a two way fashion?

They share a symmetric key using asymmetric cryptography.

Final Thought

As you see, creating safe communications is not easy. We discussed authentication and authorization, hashing, cryptography, signatures, certificates and HTTPs, just to realize that all of them are important to create a secured communication.

Security is a huge topic, and I don’t expect you to understand everything through this posts, but, at least, you will have a big picture of how a secured communication works.

Secured communications are important, but, what about authentication and authorization? we just talked a little about them as big picture. In the following post, we will see how authentication and authorization protocols work, focusing on OAuth2 and OpenID Connect (OIDC).

If you liked this post and are interested in hearing more about my journey as a Software Engineer, you can follow me on Twitter and travel together.