LFCE 101 🐧 TLS — Concepts - KandZ

⏱️ Estimated read: 13 min | |

TLS (Transport Layer Security) is the cryptographic protocol that sits between the transport layer and the application layer of the TCP/IP stack, providing confidentiality, integrity, and authentication for the client-server communication . The previous chapters covered the tools that inspect and control the traffic; this chapter covers the protocol that protects the traffic in transit. The LFCE exam expects the candidate to configure the host-based and user-based security for a service , and TLS is the mechanism that secures the HTTP, the SMTP, the LDAP, and the other application protocols.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The protocol is built on a combination of the algorithms: the symmetric encryption for the data confidentiality, the asymmetric encryption and the key exchange for the session key agreement and the authentication, and the hash functions for the message integrity . The combination is called a cipher suite, and the client and the server negotiate the suite during the handshake. The handshake is the sequence that authenticates the server, agrees on the session key, and establishes the secure channel. The certificate is the mechanism that binds the server’s identity to its public key, and the Certificate Authority (CA) is the trusted third party that signs the certificate .

Key point: The TLS handshake authenticates the server by verifying that its certificate is signed by a trusted CA and that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the hostname the client is connecting to . The client and the server negotiate the cipher suite and the TLS version, and the server proves that it possesses the private key corresponding to the public key in the certificate. The session key is then derived from the key exchange, and all subsequent data is encrypted with the symmetric cipher .

Why TLS requires the certificate and the handshake

The authentication problem.

The encryption alone does not prevent the man-in-the-middle attack. An attacker could intercept the connection, present its own certificate, and decrypt the traffic if the client does not verify the certificate. The certificate is the mechanism that binds the server’s public key to its identity, and the CA signature is the mechanism that the client uses to verify that the certificate is authentic . The client must have the CA’s public key in its trust store, and it must verify that the certificate’s domain matches the hostname it is connecting to. A certificate issued for a different domain is invalid, even if it is signed by a trusted CA .

The key-exchange problem.

The symmetric encryption is fast, but it requires both parties to share the same key. The asymmetric encryption is slow, but it allows the parties to agree on the shared key without ever transmitting it. The TLS handshake uses the asymmetric encryption (or the Diffie-Hellman key agreement) to establish the session key, and then it switches to the symmetric encryption for the data . The key exchange is the mechanism that solves the key-distribution problem, and the session key is the mechanism that makes the bulk encryption practical.

The version problem.

The TLS 1.2 and the TLS 1.3 have the different handshake flows and the different security properties. The TLS 1.3 removes the static RSA and the static Diffie-Hellman cipher suites, which ensures that all the public-key-based key exchange provides the forward secrecy . The TLS 1.3 encrypts all the handshake messages after the ServerHello, and it reduces the number of the round trips . The version is the variable that determines the security and the performance, and the server should be configured to prefer the TLS 1.3 and to allow the TLS 1.2 only for the legacy clients.

a. The certificate and the PKI

The certificate is an X.509 document that contains the server’s public key, the identity information, the validity period, and the CA’s signature . The CA is the trusted third party that signs the certificate, and the client trusts the CA by having its certificate in the trust store.

# View the certificate content
openssl x509 -in server.crt -text -noout

# Check the certificate's subject and the issuer
openssl x509 -in server.crt -noout -subject -issuer

# Check the validity period
openssl x509 -in server.crt -noout -dates

The openssl x509 -text command prints the full certificate content, including the subject, the issuer, the validity, the public key, and the extensions . The -subject and -issuer options show the identity of the certificate’s owner and the CA that signed it. The -dates option shows the notBefore and notAfter dates, which the client checks against its own clock .

The certificate chain is the sequence from the server’s certificate to the trusted root CA. The server should send the full chain, including the intermediate certificates, so that the client can build the path to the root that it trusts .

# Check the certificate chain
openssl s_client -connect example.com:443 -showcerts

The openssl s_client -showcerts command connects to the server and prints the certificate chain that the server sends . The chain must include the server’s certificate and the intermediate CA’s certificate. The root CA’s certificate is not sent, because the client already has it in the trust store.

b. The handshake and the cipher suite

The handshake is the sequence of the messages that authenticate the server and establish the session key. The TLS 1.2 and the TLS 1.3 have the different flows, but the principles are the same.

# Test the TLS handshake with the openssl s_client
openssl s_client -connect example.com:443 -tls1_3

# Check the negotiated protocol and the cipher
openssl s_client -connect example.com:443 | grep -E "Protocol|Cipher"

The openssl s_client -tls1_3 command forces the TLS 1.3 handshake, which is the mechanism for the version-specific testing . The grep on the output shows the negotiated protocol and the cipher suite, which are the result of the negotiation.

The cipher suite is the combination of the algorithms: the key exchange, the authentication, the bulk encryption, and the hash . The TLS 1.3 cipher suites are the AEAD (Authenticated Encryption with Associated Data) algorithms, such as the TLS_AES_256_GCM_SHA384 and the TLS_CHACHA20_POLY1305_SHA256 . The TLS 1.2 cipher suites include the key exchange and the authentication, such as the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 . The server’s cipher list determines which suites it accepts, and the client’s list determines which it offers. The server selects the suite that both support.

c. The TLS 1.3 improvements

The TLS 1.3 is the current version, and it addresses the known weaknesses of the TLS 1.2. The handshake is shorter, the cipher suites are stronger, and the forward secrecy is mandatory .

# Check the TLS version that the server supports
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

The -tls1_2 and the -tls1_3 options test the specific versions, which is the mechanism for the version-support check . A server that supports the TLS 1.3 and the TLS 1.2 should negotiate the 1.3 when the client offers both, because the server prefers the higher version.

The TLS 1.3 handshake has the one round-trip (1-RTT) for the full handshake and the zero round-trip (0-RTT) for the resumption, compared to the two round-trips of the TLS 1.2 . The 0-RTT is the mechanism that allows the client to send the application data in the first flight, at the cost of the replay protection . The TLS 1.3 also removes the data compression, which eliminates the CRIME-style attacks .

Complete Example Session

# ============================================
# PART 1: CHECK THE CERTIFICATE
# ============================================
openssl x509 -in server.crt -text -noout
# Output shows the subject, issuer, validity, and public key

# ============================================
# PART 2: CHECK THE SUBJECT AND ISSUER
# ============================================
openssl x509 -in server.crt -noout -subject -issuer
# Output shows the certificate's owner and the CA

# ============================================
# PART 3: CHECK THE VALIDITY
# ============================================
openssl x509 -in server.crt -noout -dates
# Output shows the notBefore and notAfter

# ============================================
# PART 4: CHECK THE CHAIN
# ============================================
openssl s_client -connect example.com:443 -showcerts
# Output shows the certificate chain

# ============================================
# PART 5: TEST THE TLS 1.3 HANDSHAKE
# ============================================
openssl s_client -connect example.com:443 -tls1_3
# Output shows the TLS 1.3 handshake

# ============================================
# PART 6: TEST THE TLS 1.2 HANDSHAKE
# ============================================
openssl s_client -connect example.com:443 -tls1_2
# Output shows the TLS 1.2 handshake

# ============================================
# PART 7: CHECK THE NEGOTIATED CIPHER
# ============================================
openssl s_client -connect example.com:443 | grep -E "Protocol|Cipher"
# Output shows the protocol and the cipher suite

# ============================================
# PART 8: VERIFY THE DOMAIN MATCH
# ============================================
openssl s_client -connect example.com:443 -servername example.com
# The SNI is sent, and the certificate's domain is checked

# ============================================
# PART 9: CHECK THE EXPIRY
# ============================================
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# Output shows the expiry dates

# ============================================
# PART 10: CLEAN UP
# ============================================
# No cleanup needed for the read-only checks

The ten parts demonstrate the TLS inspection: the certificate content, the subject and issuer, the validity, the chain, the TLS 1.3 handshake, the TLS 1.2 handshake, the negotiated cipher, the SNI domain check, and the expiry. The critical verification is Part 8: the -servername option sends the SNI (Server Name Indication), which is the mechanism that allows the server to select the correct certificate for the hostname .

Quick Reference

TLS Properties

Property	Mechanism
Confidentiality	Symmetric encryption (AES-GCM, ChaCha20)
Integrity	Hash functions (SHA-256, SHA-384)
Authentication	X.509 certificates, CA signatures
Key exchange	Diffie-Hellman, ECDHE
Forward secrecy	ECDHE (mandatory in TLS 1.3)

TLS Versions

Version	Handshake	Key Features
TLS 1.2	2-RTT	Static RSA, weak ciphers allowed
TLS 1.3	1-RTT (0-RTT resumption)	AEAD only, forward secrecy mandatory

Certificate Commands

Command	Purpose
`openssl x509 -in cert -text -noout`	View the certificate
`openssl x509 -in cert -noout -subject -issuer`	View the subject and issuer
`openssl x509 -in cert -noout -dates`	View the validity
`openssl s_client -connect host:443 -showcerts`	View the chain
`openssl s_client -connect host:443 -tls1_3`	Test the TLS 1.3

Trust Store Locations

Distribution	CA Certificate Directory
RHEL / CentOS	`/etc/pki/tls/certs`
Debian / Ubuntu	`/etc/ssl/certs`
Oracle Linux	`/etc/pki/tls/certs`

Best Practices

✅ Do This:

# Verify the certificate chain
openssl s_client -connect example.com:443 -showcerts          # ✅

# Check the certificate's domain
openssl x509 -in server.crt -noout -subject                  # ✅

# Test the TLS 1.3 support
openssl s_client -connect example.com:443 -tls1_3            # ✅

# Check the expiry
openssl x509 -in server.crt -noout -dates                    # ✅

# Use the SNI for the hostname-specific certificate
openssl s_client -connect example.com:443 -servername example.com # ✅

❌ Don’t Do This:

# Use the self-signed certificate in production
# The clients do not trust it without the CA installation # ❌

# Ignore the certificate expiry
# The expired certificate fails the handshake             # ❌

# Use the TLS 1.0 or the TLS 1.1
# They are deprecated and vulnerable                     # ❌

# Skip the domain match check
# The certificate for the other domain is invalid         # ❌

# Use the weak cipher suites
# The RC4 and the 3DES are broken                         # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
The certificate error	The CA is not trusted	Install the CA in the trust store
The domain mismatch	The CN/SAN does not match	Issue the certificate for the correct domain
The expired certificate	The validity period passed	Renew the certificate
The handshake failure	The cipher or the version mismatch	Check the cipher list and the version
The chain incomplete	The intermediate is missing	Send the full chain

Real-World Examples

1. View the certificate

openssl x509 -in server.crt -text -noout

2. Check the subject

openssl x509 -in server.crt -noout -subject

3. Check the issuer

openssl x509 -in server.crt -noout -issuer

4. Check the dates

openssl x509 -in server.crt -noout -dates

5. Check the chain

openssl s_client -connect example.com:443 -showcerts

6. Test the TLS 1.3

openssl s_client -connect example.com:443 -tls1_3

7. Test the TLS 1.2

openssl s_client -connect example.com:443 -tls1_2

8. Check the negotiated cipher

openssl s_client -connect example.com:443 | grep Cipher

9. Check the SNI

openssl s_client -connect example.com:443 -servername example.com

10. Check the expiry

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Visual

The TLS Handshake (TLS 1.2 vs 1.3)

┌───────────────────────────────────────────────────────────────┐
│  THE TLS 1.3 HANDSHAKE IS SHORTER                             │
│                                                               │
│  TLS 1.2 (2-RTT):                                             │
│  Client ── ClientHello ──▶ Server                            │
│  Client ◀── ServerHello, Cert, ServerHelloDone ── Server     │
│  Client ── ClientKeyExchange, ChangeCipherSpec, Finished ──▶ │
│  Client ◀── ChangeCipherSpec, Finished ── Server             │
│                                                               │
│  TLS 1.3 (1-RTT):                                             │
│  Client ── ClientHello + KeyShare ──▶ Server                 │
│  Client◀── ServerHello + KeyShare + Cert + Finished ── Server│
│  Client ── Finished ──▶ Server                               │
│  (all handshake messages after ServerHello are encrypted)     │
└───────────────────────────────────────────────────────────────┘

The Certificate Chain

┌──────────────────────────────────────────────────────────────┐
│  THE CHAIN OF TRUST                                          │
│                                                              │
│  Root CA (trusted by the client)                             │
│       │ signs                                                │
│       ▼                                                      │
│  Intermediate CA                                             │
│       │ signs                                                │
│       ▼                                                      │
│  Server Certificate (example.com)                            │
│                                                              │
│  The server sends the leaf and the intermediate.             │
│  The client has the root in the trust store.                 │
└──────────────────────────────────────────────────────────────┘

The Cipher Suite

┌──────────────────────────────────────────────────────────────┐
│  THE CIPHER SUITE IS THE COMBINATION OF THE ALGORITHMS       │
│                                                              │
│  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384                       │
│  ├── ECDHE: key exchange (forward secrecy)                   │
│  ├── RSA: authentication (the certificate)                   │
│  ├── AES_256_GCM: bulk encryption                            │
│  └── SHA384: hash (integrity)                                │
│                                                              │
│  TLS 1.3: TLS_AES_256_GCM_SHA384 (AEAD)                      │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Protocol	TLS (Transport Layer Security)
Purpose	Confidentiality, integrity, authentication
Certificate	X.509, signed by a CA
Trust store	`/etc/pki/tls/certs`, `/etc/ssl/certs`
Handshake	Authenticates the server, agrees on the key
TLS 1.3	1-RTT, AEAD only, forward secrecy mandatory
TLS 1.2	2-RTT, static RSA allowed
Cipher suite	Key exchange + auth + encryption + hash
Verification	`openssl s_client`, `openssl x509`

Key takeaways:

TLS provides the confidentiality, the integrity, and the authentication. The symmetric encryption protects the data, the hash functions ensure the integrity, and the X.509 certificates authenticate the server . The protocol sits between the transport layer and the application layer, and it is the mechanism that secures the HTTP, the SMTP, and the other application protocols.
The certificate binds the server’s identity to its public key. The CA signs the certificate, and the client verifies the signature with the CA’s public key in its trust store . The certificate’s Common Name (CN) or Subject Alternative Name (SAN) must match the hostname the client is connecting to.
The handshake authenticates the server and establishes the session key. The client and the server negotiate the cipher suite and the TLS version, the server proves its identity with the certificate, and the key exchange derives the session key . The TLS 1.3 handshake is shorter and encrypts the handshake messages after the ServerHello .
The TLS 1.3 is the current version. It removes the static RSA and the static Diffie-Hellman, mandates the forward secrecy, and uses the AEAD ciphers . The TLS 1.2 remains for the legacy clients, but it should be configured with the strong ciphers and the ECDHE key exchange.
The openssl s_client is the verification tool. The -showcerts option prints the chain, the -tls1_3 and the -tls1_2 options test the versions, and the -servername option sends the SNI . The openssl x509 command views the certificate’s content, the subject, the issuer, and the dates.
The trust store is the client’s source of the trusted CAs. The RHEL and the Oracle Linux use the /etc/pki/tls/certs directory, and the Debian and the Ubuntu use the /etc/ssl/certs directory . The CA certificate must be installed in the trust store for the client to trust the server’s certificate.

Remember: TLS is the protocol that secures the application traffic. The certificate is the identity, the CA is the trust anchor, and the handshake is the mechanism that authenticates the server and establishes the session key. The TLS 1.3 is the current version, and the TLS 1.2 is the legacy fallback. The openssl s_client and the openssl x509 are the verification tools, and the trust store is the client’s source of the trusted CAs. The result is the secure channel where the client knows who the server is and the data cannot be read or modified in transit.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!