How SSL Work

Recently, there was a bit of a discussion in the office on how SSL works. I think this stems from SSL (OpenSSL) being one of the most sparsely documented library in the open source world. Hopefully this will help someone, and also serves to remind me next time I want to fix things.


The following presumes you have public-key crypo knowledge. To set up the secure channel, the steps are as such:

  1. Client connect to SSL server
  2. SSL server sends client its cert
  3. Client randomly generate a key, and encrypt it with the server’s cert and sends it to server. Since encrypted, only server and client knows this key.
  4. Server gets client’s key, and encrypts remaining of the data with key

In this scenario, there is one loophole – how do you know the server sending you the cert is valid? A bad guy on the internet can intercept the data stream and give you his own cert, creating a man-in-middle attack.

To solve this problem, SSL uses signed certs. The cert that the server have is signed by another cert (typically call Certification Authority, CA). This CA cert can be signed yet by another cert, etc, etc. So how do we verify the top level certs (those that sign everybody else)? These certs are actually installed in client’s browser/OS, since the client trusts its browser and OS, the chain of trust can extend down to the server cert.

Verifying Certificate

You can verify a certificate using openssl on linux.
$ openssl s_client -connect
depth=0 serialNumber = fqi84NUg7JCvWph5RiPhVWj76ujT39uq, C = SG, O = *, OU = GT21833570, OU = See (c)10, OU = Domain Control Validated - RapidSSL(R), CN = *
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 serialNumber = fqi84NUg7JCvWph5RiPhVWj76ujT39uq, C = SG, O = *, OU = GT21833570, OU = See (c)10, OU = Domain Control Validated - RapidSSL(R), CN = *
verify error:num=27:certificate not trusted
verify return:1
depth=0 serialNumber = fqi84NUg7JCvWph5RiPhVWj76ujT39uq, C = SG, O = *, OU = GT21833570, OU = See (c)10, OU = Domain Control Validated - RapidSSL(R), CN = *
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
0 s:/serialNumber=fqi84NUg7JCvWph5RiPhVWj76ujT39uq/C=SG/O=* (c)10/OU=Domain Control Validated - RapidSSL(R)/CN=*
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Server certificate
subject=/serialNumber=fqi84NUg7JCvWph5RiPhVWj76ujT39uq/C=SG/O=* (c)10/OU=Domain Control Validated - RapidSSL(R)/CN=*
issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
No client certificate CA names sent
SSL handshake has read 1744 bytes and written 353 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID: 046976837AFB333337300D2AE0CFA9BFB92ACB262857F98632E1F4327A5D5A73
Master-Key: C5038788C147F16260760064E379BE5B948CB3E65D33EBC0B99110D92DE4FCB7F6E86BD26FF3FB75589FA915EE578A12
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1332384818
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)

You can see from the output (blue, in Certificate chain) that the server returned one cert. From the last line, we are not able to verify the cert. This is because we didn’t provide the top level certs directory for openssl to verify again. In Ubuntu, the certs are at /etc/ssl/certs/.

$ openssl s_client -CApath /etc/ssl/certs/ -connect
Verify return code: 0 (ok)

Single Root

In our example above, we can see that the server cert is signed by a root CA (“Equifax Secure Certificate Authority”). This is what we call “Single Root” cert. In the last few years, single root certs are becoming less common, and most certs that you buy are chained certs (server cert signed by intermediate cert, which is in turned signed by root cert). This is the confusing part to many sysadmins. Instead of just installing a server cert, now a sysadmin have to install but the server certs and all the intermediate certs, to ensure that the chain of trust can be verified. An example of this is

$ openssl s_client -connect
Certificate chain
0 s:/C=SG/ST=Singapore/L=Kent Ridge/O=National University of Singapore - School of Computing/OU=Webserver Team/
i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
1 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/
2 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

You can see that the server now returns 3 certs. (0) is server cert, which is signed by (2), which is in turn signed by (1).

If only the server cert is installed, then you will only be able to see 1 certificate here, and the chain of trust will fail!

In summary, always check your certs after installing. You can also check them easily using web tools, e.g.


One thought on “How SSL Work

  1. After that anything that mmakes thee pocess less complicated has actually acquired too be a good thing, if lie me you’re trying tto discover a new language.

    I’ve taken a look at severa of the tools available and have actually found to
    my expense that many of the paid ones are practically ineffective.
    The one I use at the moment is in the generaal public domain
    name and functions fantastically well. If you’ve any sort of passion inn increasing your discovering then why not look?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s