Most people see HTTPS services as some kind of a black box, which is untrue.

HTTPS relies on the RSA encryption system. The RSA is a different post but the short version is you have two complementary keys, one public and one private. Everything coming your way needs to be encrypted with your public key so you can decrypt it with your private key.

Having an HTTPS service means your web service has an RSA key pair that is signed by a trusted certification authorization service provider. The most known service is Google CA.

Key pairs can be certified by any service including your own that you can create, but browsers will only trust pre-defined Certificate Authorization services. In your closed-off work network environments, you can tell the browser to trust your own CA service. With this, all of the communication between devices in your network can be encrypted and the only way to join this device network is to get their key pair certificated by your service, so third parties cannot enter without permission.

Before we step into how signing works, we must take a quick look at how we can validate that we are who we claim to be. Because our public key is public, third parties can say «That public key is mine, send all the data traffic to me.» and manipulate our network traffic.

The easiest way to validate yourself is, again, encryption.

Public and private keys are complementary, they work in both ways. So if you encrypt a message with the public key only the private key can decrypt it, and if you encrypt it with the private key only the public key can decrypt it.

The question to ask here is, «Is there a message that can we encrypt that both sides of the communication know of?». If you want to have a thought experiment with it, stop reading and think about it for a few seconds.

The answer is yes, there is. Everyone knows each other's public keys. You can encrypt your public key which is your message with your private key and send it for validation. The device on the other side already knows your public key and runs the same function on the encrypted message and discovers the message itself was your public key all along.

So, what does it mean? It means, you have the private key pair of that public key, and most likely the owner of the key pair. Now, everyone who has run the validation check can know you are you.

Going back to the CA services, this is basically what they do. They do a validation check to make sure you are who you claim to be and sign your key pair so everyone else that trusts this CA service can know you are validated and they can communicate with you.

In the process of sending out your encrypted message to CA services, you should remember that they also use RSA. So the encrypted message you have has become the message itself and it needs to be encrypted again with the CA service's public key. Because every network traffic going towards an RSA system user must be encrypted with their public key.

On the CA service side, the system will first decrypt using its own private key to uncover your encrypted message. Then, decrypt it again with your public key to discover the initial message. And only and only if the decrypted initial message was your public key all along, they will sign it for you and send it back so you can start using them.

These are also the steps your own CA service should go through if you decide to build one.

Security is still a big problem, share this with others if you have found it useful.