(1 votes, average: 5.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

July 13, 2016 3

SSL/TLS Certificates – Their Architecture, Process & Interactions

in Everything Encryption

Taking a closer look at SSL/TLS Certificates and how SSL/TLS works

You may have heard of SSL, your website may even employ SSL encryption—but do you know how it works? Do you care? Of course you do. You have an inquisitive mind, that’s why you clicked this link!

In this article we’ll take a look at the inner-workings of SSL, including SSL architecture, digital signatures, PKI and SSL’s interactions and processes.

SSL Certificates

SSL, which is short for Secure Sockets Layer (today, we actually use its successor Transport Layer Security (TLS) but still colloquially refer to it as SSL), is really two things. It’s a certificate and a protocol.

Think of the certificate as a driver’s license of sorts. It both verifies the identity of its holder while also granting certain permissions. The SSL protocol handles the actual encryption and decryption – in this car metaphor, the protocol is like the engine – we’ll talk about how it works later.

SSL Certificates are issued by Certificate Authorities. Certificate Authorities are trusted third parties that authenticate websites and issue SSL certificates. When we say trusted, what we mean is that they are considered trusted by web browsers and operating systems, and are essentially vouching for the authenticity of the websites they’re issuing SSL Certificates to.

As far as a web browser is concerned, there are two tiers of vouching. There’s Domain Validation and Organization Validation, which grant one level of authentication. And then the second tier is Extended Validation, which grants the highest level of authentication.

When a company or person wants an SSL certificate they first fill out a certificate signing request, or CSR. That is then submitted to the CA who goes through the necessary steps to vet the requester. The certificate is then created, signed and delivered for installation.

Digital Signatures

In order to grant the certificates, the CA’s must digitally sign them. A digital signature is a lot like a traditional signature, but more secure and they offer additional benefits.

When a document is digitally signed it:

In order to sign a certificate, a hash of the data to be signed must be produced. The result is then encrypted with the sender’s public key and appended to the data. This is what protects the integrity of the hash result.

The recipient of the data then uses the corresponding private key (don’t worry, we’ll explain public and private keys in a bit), to decrypt the hash.

A new hash result is then created, it is matched up against the original signed hash result and if the two codes are the same, it indicates that the data hasn’t been altered. This means the recipient can verify the sender, because only the entity with the private key could have signed it.

PKI (public key infrastructure)

You may be wondering what we meant back there when we referred to public and private keys. That all relates to PKI, or Public Key Infrastructure. PKI is the underlying framework for SSL and many other kinds of encryption. Public Key Infrastructure implements encryption using a process called asymmetric cryptography.

Asymmetric cryptography involves two keys, one which performs the encryption and another which performs decryption. The keys are created by the website owner (when they create a certificate signing request, or CSR) and are used in pairs–there is a private key and a public key. The public key is available to anyone who wants it, but the private key is kept by its owner and should never be handed out.

When someone wants to send information, they use the recipient’s public key to encrypt the information they are sending. The SSL protocol takes care of all of these steps invisibly in the background. The recipient is then the only person (or website) with the private key who can decrypt it.

SSL Interactions

So how does SSL work? You now understand how a certificate is issued, how it’s signed and what PKI is, but how does it all fit together?

When you visit a site the first thing your computer does is looks for the site’s SSL certificate (well, maybe not the first thing—but one of them). This lets your computer know if the site has been verified and if encryption will be used during communication.

If an SSL certificate is present the computer and the website do something called the SSL handshake, wherein they trade information and capabilities so they can decide exactly how they will be encrypting information.

If the handshake is successful, encrypted communication begins. The “client” – which is the computer connecting to the website – uses the website’s public key to encrypt any information it’s sending – this can be anything from credit card info to computer requests for which page they want to access – while the website uses the private key to decrypt the information once its reached its server.

This keeps the information safe from malicious third parties who may want to steal it.

How SSL/TLS Works

While there’s plenty of much more in-depth topics when it comes to SSL/TLS, that’s a basic overview of how SSL/TLS works.

In summation:

We could go into more detail about root certificates, cross signing, SHA1 and SHA2, ECC Algorithm, etc. And we will at a later date. But for now, this should serve as a nice entry point into how SSL/TLS works, its architecture, its processes and its interactions.