ILWC Privacy Statement About ILWC
Certificates ... why?
security privacy
2018-10-18 14:58:18
2018-10-18 16:00:00
2018-11-18 16:00:00
An attempt to shed some light on web-certificates.

Let's say I want to navigate to this very website ( So I just key in the URL and voila...the browser does all the work, I'll get connected. And in this case it's a encrypted connection (https). So you (might) feel safe.
But how does the browser determine that this sight is safe to navigate to?
Well the easy/lazy answer is Certificates. Well this is certainly true, but I doubt whether the average reader now has a clear idea of what is happening, so let's get into some more detail.

What is actually our problem?
Let's start with this question. What is the problem anyway? You have to imagine, hmmm actually you have to realize, that the WWW is not a friendly place. It maybe started out as a friendly place, but it sure isn't anymore these days. A whole lot of crooks are trying to get to your online data or maybe try to misinform you. How do they do that? I'll just give one example, but there are many many more ways to get to you online.

The normal flow of data in a unencrypted conversation.

  Client (browser)                                 DNS   server (httpd)
1      | -----------> Ask IP-address of --> |
2      | <----------- Get the IPaddress of <------- |
2      | -----------> Create TCP connection ---------------> |
       |              to this IP-address
3      | <----------- Acknowledge the connection <---------- |
4      | -----------> Send GET to -----------------> |
5      | <----------- Send index.html back <---------------- |
But what if a crook has set up a roque WIFI access-point. This access-point recurses all DNS requests to a normal DNS-server except for requests for DNS-requests for will get an answer wich points the browser to a server controlled by the crooks. And on this server anyrhing can happen. Maybe even a look-alike site to trick you into logging in to the (fake) site. At that moment the crook has you credentials and can login to with your username/password.
Let's see how this works for a site which is not
                                           Rogue    Regular  Rogue       Real
  Client (browser)                         DNS      DNS      Web-Server  server (httpd)
1      | ---> Ask IP-address of --> |
2             Recurse the request          | ------> |
3             Get the regular DNS answer   | <------ |
4      | <--- Get the IP-address <-------- |
5      | ---> Create TCP connection ------------------------------------> |
       |      to this IP-address
6      | <--- Acknowledge the connection <------------------------------- |
7      | ---> Send GET to --------------------------------------> |
8      | <--- Send index.html back <------------------------------------- |

And now for a request to
                                           Rogue    Regular  Rogue       Real
  Client (browser)                         DNS      DNS      Web-Server  server (httpd)
1      | ---> Ask IP-address of -> |
2             Return fake address <------- |
5      | ---> Create TCP connection ------------------------> |
       |      to this IP-address
6      | <--- Acknowledge the connection <------------------- |
7      | ---> Send GET to --------------------------> |
8      | <--- Send index.html back <------------------------- |
If you think the above scenario must be quite exotic...No it's's common practice.

What can we do? Well certificates come in to play.
A certificate is a little file which says "Yes...this server is who it claims to be." In the cae an certificate says "Yes...the server you are connecting to is actually"

Problem solved ...NO. If this was the end of the story a crook could easily forge a certificate, place this certificate on the rogue server, and pretends even securely that it's
Luckily this is not the end of it. Certificates must be signed (the digital equivalent of an autograph) to be valid. This signing can be done by it self (self-signed-certificate), this will add NO extra security. Because, if you can...a crook can also create a self-signed-certificate on the roque site.
A valid certificate is signed by a Certificate Authority (CA). However certificates of all CA's are not deployed with your browser. Only a few are deliverd : the root CA's. They are on the end of a chain of certificates. Let's look at some information from the chain of certificates of
[martijn@tijnie ~]$ openssl s_client -connect
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN =
verify return:1
Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
There is much more information but...for now, this is enough. A browser downloads the whole chain of certifcates (except for the root). The root is provided with the browser.
So what did the browser do:
  1. get the certificate-chain from
  2. Checks whether it the certificate is valid
  3. Checks whether the certificate is actually signed by "Let's encrypt"
    1. Not signed by Let's Encrypt...error and exit
    2. Signed ....Checks whether the signature on the Let's Encrypt certificate is trustworthy
      Since this is a root certificate it must be allready in my browser (supplied by the browser-developer)
      1. The Let's encrypt certificate is not signed by the root certificate....Error/Exit
      2. The Let's encrypt certificate is actually signed by the root certificate....proceed
  4. Apparently everything is fine. We do now trust that the site is who we think it is..Get the webpage we are after

So the idea is that if we ultemately trust the root-CA to only sign certificates of CA's which it really trust, we also can trust the intermediate CA's (like Let's Encrypt) to only sign certificates which are valid.

A question might be....Does my browser actually have the root certificate of (in this case /O=Digital Signature Trust Co./CN=DST Root CA X3). Well let's see in my chrome browser which root CA it is supplied with:
Let's go to chrome://settings/certificates and turn to the tab Certificate Authorities.

And now see whether we can find the root CA:

Yes...we can.