In my previous article (Does a Padlock icon mean a site is completely safe to use?) there was a certificate authority involved. But basically, what is a certificate authority and how is a certificate signed.
So far we have only shown that we can communicate in an encrypted fashion even though the communication channel itself might not be protected, we haven’t really talked how you can make sure that the party you ate talking to is actually who they claim they are. This is where the certificate authority comes in.
So remember we had a certificate that was signed by the google certificate authority, but how do you get such a certificate, how is it signed.
What is a Certificate Authority? 🤔 How It Works
This time let us start with the youtube.com web server. Now imagine this is before youtube.com uses HTTPS, so we want to secure this web server with HTTPS, but we don’t have anything along those lines yet.
So now there is the Google certificate authority, which is considered a trusted certificate authority on the Internet. Like any party involved in public-key cryptography the google certificate authority has a private key and a public key.
Now if the webserver running youtube.com also wants to take part in HTTPS encrypted they also have to create such anew key pair, and everyone can create a key pair.
Next up the person or company running this youtube.com web server Creates a so-called certificate signing request. So, this a request that youtube.com web server creates which is made from their key pair and basically it requests the known authority to sign this certificate.
So the youtube.com web services says,” Hey I have decided, I want to use HTTPS from now on. I have created a signing request with my key pair. Can you please sign it?” 🤔
Now the google certificate authority says, “Sure. I have signed your request with my private key. Now anyone who has my public key can verify that it was actually me who signed it.” 😊
Now most browser’s when they are installed on any device already have a list of trusted certificates and these certificates are issued by known certificate authorities.
Google is one of them and YouTube uses the google one because YouTube belongs to google, or alphabet and they have their own authority.
But smaller companies might not have their own certificate authority, so there are also standalone certificate authorities (e.g DigiCert) on the internet that you can ask to sign your certificates signing request.
The important thing is that you chose one that most browsers trust by default because now when this browser comes in contact with this newly created website even though youtube.com might not have existed when the browser was created.
it can now verify that this public key which claims to be signed by google was actually signed by Google, because it knows Google’s public key from their certificate authority and can now reliably determine that the information in this certificate that youtube.com provided is true as long as we trust the google CA.
That also means that the public key which is in there that we’ll use in HTTPS to encrypt a new secret that we can then use for symmetric encryption does belong to youtube.com.
What is a self-signed certificate?
Sometimes it might not be necessary to have a well-known authority sign your request. Let us imagine you have your own app and it’s currently deployed to your staging environment where you want to do some testing.
So, if you now say I also want to encrypt all the communication with this app, you have to create a private key and a public key. So, the next step would now be to create a signing request, but who will sign this if there is no certificate authority.
In such scenario’s you can create a second pair of keys, and setup your own certificate authority.
You can now do the same stuff as before, you create your certificate signing request and send it to the certificate authority, the CA will make sure that you actually have access to this URL that you’re claiming and say,” hey, here’s your certificate. It was signed by me, and anyone with my public key can verify that it was signed by me”.
So instead of a browser this time your 2nd app comes along and say,” hey I want to interact with the 1st app that we just deployed to the staging environment”. It then realizes that your app wants to use HTTPS, so it looks at the certificate and finds a public key in there.
This certificate now says I was signed by our newly created certificate authority and then of course your second app says this is not a trusted CA I will not trust this.
However because all of this is in your controlled environment and you do trust the CA that you just created you can now tell your 2nd app, to trust the certificate that points to this CA, that contains this public key. Then you can use that to validate the public key from the 1st app that we deployed to staging.
This makes your 2nd app to trust the certificate provided by your 1st app and in turn start the HTTPS communication between them.
So, the process is basically the same, in the second case we are just populating our own CA and asking end user’s to trust that, which is very common in testing environments.
In conclusion, HTTPS communication is not that difficult and really everyone should implement it for obtaining a better security posture.
I am planning to release a few more articles in which I will show you how you can self-sign your own certificates, so you can use HTTPS for testing, and then later up will also show how to automate all of this process with Kubernetes, both using your own CA and also a trusted CA. Leave a comment with you feedback for this article.