Too often do i hear my application admin coworkers and some sysadmins even, moan and grumble about certificates. People are always talking about TLS/SSL as if “no one understands this anyway” and “It’s a mystery to me”. I held a talk at my workplace recently where I attempted to demystify TLS/SSL a bit, and maybe someone out there would also be interested in that.

I’m no expert on TLS in any real sense, but i’ve been managing an internal PKI for a while now and looked into the protocol.

Also this is not a step by step guide on how to build an internal PKI (though i might do that in another blog post, at least for homelab use), nor is it a detailed guide on certificates. It’s more of an overview.

---

What the Hell is SSL? And who is TLS?

Okay first of let’s get the definitions out of the way. They’re not necessary for this but It’s a good place to start. SSL stands for Secure Sockets Layer and was invented in 1994. In 1999 its newest cousin was named TLS, or “Transport Layer Security”. TLS came with some upgrades to authentication and stronger encryption.

Since then we’ve only been talking about TLS. !

Versions of SSL

SSL began with 1.0, which was rubbish, and never publicly released. In 1995 SSL 2.0 was the first proper release of SSL, until 2011 when it was deprecated. SSL 3.0 was released in 1996, just a year later, and was supported until 2015.

Flaws in SSL 2.0

SSL 2.0 had a few major security flaws, one of which was the fact the handshake was not protected, thus leading to easy man in the middle attacks. Another flaw was that TCP Fin could be used to indicate data flow, which allows for a truncation attack.

Flaws in SSL 3.0

SSL 3.0 was vulnerable to the POODLE attack (See here for more details.)

With 3.0, that was the end of SSL. Long live TLS!

Versions of TLS

TLS has had four official releases so far: 1.0, 1.1, 1.2 and 1.3. 1.2 and 1.3 are the current releases, with 1.3 being preferred but some older applications and protocols requiring 1.2. SSL Inspection doesn’t work very well on 1.3, which is usually good, but bad in a corporate environment

TLS version 1.0 was released in 1999, while 1.1 was released in 2006. Both were deprecated in 2021.

Flaws in TLS 1.0

Mostly TLS 1.0 had weak ciphers (we’ll get to that, don’t worry), and was vulnerable against the BEAST attack (yes, they really have some fun names for their attacks, don’t they?) It also supported small key sizes, which in today’s environment are easy to break. Lastly (not really, but this is not a blogpost about TLS vulnerabilities) we had weak hashing, like SHA-1.

Flaws in TLS 1.1

TLS was plagued by many of the same issues, such as POODLE, weak ciphers. It was also vulnerable to downgrade attacks, which allows attackers to downgrade the TLS version to 1.0 or SSL 3.0. Also its handshake was less efficient than modern TLS versions.

---

Okay but how does it work?

Now let’s see how this works, and what is needed. Let’s get the technical basics out first.

TLS Handshake

TLS begins with a discussion between client (initiator) and server. They negotiate their favorite ciphers (yes we’ll get to it) and TLS versions, and then get at it. The TLS handshake looks thusly: ! You have the server’s public certificate, and are trying to figure out a symmetrical key together with the server without telling the server what the key is. It’s like a game of charades, but with cryptography! The whole thing has another underlying process, which is how the symmetrical key (known as the Session Key) is generated. ! Together with two random numbers, both client and server are able to calculate a symmetrical key without the key ever being transmitted.

This specific version is the RSA Key Exchange, There’s also Diffie-Hellman Key Exchange (often shortened as ECDHE: Elliptic Curve Diffie-Hellman Exchange). Finding out more about that one is left as an exercise to the reader.

The diagram talks of a “Public Key Certificate”, but what is that actually? It’s time to get into certificates!

Certificates

A certificate certifies (who would have guessed?) that the talking server is the actual owner of the presented public key. When we speak of certificates, we are actually not speaking of a special TLS object, but a more generic one. The certificates used in TLS are X.509 certificates. A certificate has certain formal requirements/fields:

Version

Each certificate must tell you which version of X.509 it is (usually v3 today).

Serial Number

This one’s important. Each certificate has a serial number uniquely identifying them within a CA (see the PKI section to figure out what that means).

Signature Algorithm

Which algorithm was used to sign the certificate, this is a combination of a hashing algorithm and an asymmetric algorithm. (e.g. SHA256 with RSA).

Issuer

Who issued this certificate? This is that CA part again, we’ll get to this, don’t worry! Certificates function without a CA, as so-called “self-signed” certificates. However, this is generally a bad idea.

Validity Period

A certificate has a date before which it is not valid, and a date after which it is not valid. In internal CA’s, i’ve seen certificates be valid for up to 10 years! Though usually in the outside world of the internet, we’re talking about a year maximum, more likely 90 days. Google actually is working on reducing this to 45 days!

Subject

Who the certificate is for. This includes:

• Common Name: FQDN of the server
• Organization: The organization which uses this certificate
• Organizational Unit: Optional
• Country: The country
• And more location information such as Locality and State.

Public Key

The big one! The actual public key of the server

Extensions

Specific to X.509 v3. These are additional fields in the certificate which extend or confine its use. One of the most important ones here is the “Subject Alternative Name”, which contains additional DNS names (or IPs! though public CA’s don’t like that) which the certificate is valid for.

Important: the CNAME must also be present in the SAN.

Signature

The signature! Which is a hash of the certificate, signed by the issuer.

Certificate Formats

lastly, certificates generally come in 2 usable formates:

• PEM
• PKCS12 The former is an unencrypted, Base64 encoded string. It does not include a private key, and is meant for public distribution. The latter is the encrypted, binary certificate which is bundled together with the private key. It is therefor often protected with a passphrase. There are also pkcs7, but we will be ignoring them today.

Ciphers

When the client and server are chatting during the handshake, they’re essentially deciding on their favorite meal from a cipher suite menu. A cipher suite is a combination of algorithms that determines how data will be encrypted, authenticated, and verified. Think of it as ordering a full-course meal:

1. Appetizer (Key Exchange Algorithm):
   This is how the client and server decide on a shared session key. Options include RSA (classic) or ECDHE (modern and snazzy). The latter is like kale—everyone’s into it these days because it’s healthier (better security).

2. Main Course (Symmetric Encryption):
   This is the actual encryption algorithm that protects your data during the session. Think AES-GCM (the filet mignon of encryption) or the slightly older AES-CBC (still good but prone to spills—uh, vulnerabilities).

3. Dessert (Message Authentication):
   To make sure no one tampered with the data while it was in transit, we need a dessert that’s hard to fake—like an HMAC (Hash-based Message Authentication Code). Deliciously secure.

A typical cipher suite might look like this on the menu:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Yes, they love long names. They’re overachievers.)

Here’s the breakdown:

• ECDHE_RSA: We’re using Elliptic Curve Diffie-Hellman Exchange for the key exchange, signed with RSA.
• AES_256_GCM: AES with a 256-bit key in Galois/Counter Mode for encryption.
• SHA384: A secure hash function to verify data integrity.

---

Ugh why is my cert not working?!!!

This is going to be a short one. There is an amazing website, called badssl.com, which simulates all kinds of TLS (and SSL!) errors. If your service is throwing you an error message, such as a website, you can usually find an error message.

! In firefox you’ll need to go to “Advanced”. This error is SEC_ERROR_EXPIRED_CERTIFICATE. Remember when we talked about the validity of a certificate? Let’s take a look at this one… ! You can see that the certificate expired in 2015. We can also see other interesting fields we talked about in the previous section, such as the Subject Alternative Name (which correctly includes the CNAME!) and the certificate’s serial number.

---

PKI, (I don’t have a funny title for this one)

Now! We’re able to encrypt things (with TLS) and even trust things (with certificates) however, what are we going to do? Trust a billion certificates? What if one of those certificates gets stolen?

That’s where PKI, or Public Key Infrastructure, comes in.

What is PKI?

At its core, PKI is a system for managing, issuing, and validating digital certificates. It consists of several components and processes that create trust between communicating parties. Essentially, it answers two key questions:

1. Is the server (or client) I’m talking to who they claim to be?
2. Has the data I’m receiving been tampered with?

PKI is built on asymmetric encryption (using a public/private key pair) and trusted authorities to establish this trust.

Key Components of PKI

1. Certificate Authority (CA):

   • The CA is the entity that issues certificates. It acts as a trusted third party that everyone agrees to trust. (Remember when we talked about the issuer in certificates?)
   • Example: DigiCert, Let’s Encrypt, or your internal CA.
   • When a CA issues a certificate, it digitally signs it using its private key.

2. Root CA:

   • The ultimate trust anchor in PKI. Every device has a list of trusted root CAs pre-installed (e.g., your browser or OS).
   • Root CAs issue certificates to Intermediate CAs.
   • A good internal CA will have an offline Root CA, so we don’t have to start from the beginning when our other CA’s get compromised.

3. Intermediate CA:

   • A middleman that issues end-entity (or leaf) certificates. These are typically used so the root CA doesn’t directly sign all certificates, reducing its exposure.
   • The chain of trust flows from the root to the intermediate to the end-entity certificate.

4. End-Entity (or Leaf) Certificate:

   • This is the certificate you see on websites (e.g., example.com). It’s issued to the entity actually using the certificate.
   • Leaf certificates cannot issue other certificates.

5. CRL (Certificate Revocation List):

   • A list of certificates that have been revoked before their expiration date. The CRL is published by the CA and checked during certificate validation.

The Chain of Trust

When you visit a website secured with TLS, your browser doesn’t blindly trust its certificate. Instead, it validates the chain of trust. Here’s how it works:

1. The browser receives the website’s leaf certificate.
2. The browser checks if the leaf certificate was issued by a trusted CA.
   • If it wasn’t issued by a root CA, the browser follows the chain to an intermediate CA, then to the root CA.
3. The browser validates the signatures in the chain using the public keys from each certificate.
4. If the entire chain is valid, the browser trusts the website’s certificate In the end, we trust whatever the OS and Browser developers put in.

Key takeaways

(Takeaway? I’m getting hungry after that cipher part!)

1. TLS is SSL, but newer! Use it, love it, abuse it! But stay on TLS 1.2 and 1.3 please
2. Certificates are the ID Cards for public keys They prove that the server you’re talking to is who he/she/they claim to be.
3. Cipher’s are the secret sauce below it all. There are some that are good, there are some that are bad. ECDHE with AES-GCM is a solid choice btw!

And that’s it! if that helped, i’d be glad!