HTTPS Certificates and work flow
In Part 1 we discussed the steps involved in establishing a secure channel between web server and client .
Here we will discuss about the high level steps involved in Certificate signing and verification between a Web server and Client along with Certificate Authorities
Suppose you are hosting a site www.example.com ; how you will ensure that the contents you serve from web server is not forged when it reaches your client.
We need a secure mechanism, HTTPS; but how these certificate things work, how you get these certificates and who does the verification of it on client side
Let’s break it down to two parts, one the Certificate Signing Request and second is Certificate Authorities
You already know VeriSign provides Signed Certificates and you decided to reach them out for a certificate
First, they will ask for a Certificate Signing Request (CSR)
How you are going to create CSR ?
It’s very simple with OpenSSL, first you create a key and using that key you can create a Certificate Signing Request
This CSR will be sent to Certificate Authority(CA) ; they will sign it with their private key and will send you back the Signed Certificate
At the same time the CA approaches the Web client software developers, let’s say here it is Mozilla Firefox team and ask them to include their CA public certificate in Firefox installer
Mozilla team will verify CA’s reputation and approve the submission of certificate. As an end user you will download Firefox and install it on your local system
Now you have the CA certificates in Firefox’s certificate vault which came along with the installer.
When you make a request to https://www.example.com , it will give you the Signed Certificate which web server got from VeriSign (or another CA).
Once the browser gets Certificate, it will go to the certificate vault and check if there is any CA matches with the signature which is in the certificate sent by the web server
Of course, there will be a match in this scenario and Firefox will trust the site and continue with next steps
If there is no matching certificate on vault or if the FQDN you typed in URL not matching with the one on the certificate which the web server sent; you will get a warning on browser
Here browser will give you a choice, “Do you want me to still trust it as I cannot verify his identity, or shall I deny it?” We will deny it if this site that always have an active signed certificate
Please read my first post – Part 1 if you are interested to know how thing progress from here on wards
Now let’s look at the step by step process involved which I’ll explain based on above flow diagram
Step 1. Server admin creates a key or private certificate
Step 2. Using this key admin generates a Certificate Signing Request
Step 3. CSR will be send to Certificate Authority (CA)
Step 4. CA will sign the request using its private key
Step 5. Signed Certificate send back to web server’s admin
Step 6. Server admin deploys the certificate on to web server
When the CA generates in Public certificate, they approach the Firefox developers to include their public CA certificates to the installer
and you know the remaining thing happens from here onwards.
Note: I took Firefox as an example and this process varies based on browsers and sometime OS vendor can also embed these CA certificates in their certificate store