Most of us use https. Almost every communication is secured and encrypted with https. In this article I would like to discuss the HTTPS process in more detail and what role certificates play.

Introduction to the Public / Private Key Structure

A https connection is established by using Asymmetric Cryptography. The Server provides a certificate that demonstrates the server’s identity. But there’s more. The Server is in possession of a Public and a Private Key. Before we continue let’s take a look at the procedures when a sender and a recipient wants to exchange data in a secret way.

The Recipient transmits his public key (The public key can be given to anyone without any worries), but keeps the private key. So, the Sender can encrypt the message with the Recipient’s public key. This encrypted message can only be decrypted by the Recipient, because he’s the only one on this planet who is in possession of the private key.

The question is now how do I know if I’m in possession of a private key. Well, if you are using Windows open certmgr.msc (shows all user certificates) or certlm.msc (shows all computer certificates).

certmgr.msc

Ok, so now I know that I have the private key. But how can I send the public key to someone else? Well, if you are using an “official” certificate from a Trusted Root Authority then you can be quite sure, that the Sender has it already in his Trusted Root Certification Authorities.

If you are using a self-signed certificate then you have to transfer the public key. You can export the public key by clicking on Export … Be careful you don’t also export the private key! 👿

There’s so much more to say … but we have to get back to the main topic.

SSL Encryption (HTTPS)

So, we’ve seen that there’s a Sender and a Recipient. When using HTTPS the Sender is the Client and the Recipient is the Server. I’ve prepared a very simplified graphic.

1. The Client tries to establish a connection to the server. (Hello!) The server responds, that he accepts only secure communication.
2. The Server sends his Public Key to the Client.
3. The Client generates a random value (in our case it’s 243) and encrypts this number by using the Server’s public key.
4. The Server is the only one that can decrypt the data with his Private Key. After decryption, he can read the secret key (243).
5. The transfer of data begins.
6. To avoid that the attacker can guess the secret key (243) it is regenerated from time to time:

The secret key is regenerated at regular intervals.

By the way: If you want to test if a server can be reached via https (443), use PowerShell.

More about Test-NetConnection here:

The new netstat: Playing with Get-NetTCPConnection

Hope this was helpful!

See also

PowerShell: Encrypt and Decrypt Data by using Certificates (Public Key / Private Key)

How to digitally sign PowerShell Scripts