A quick note on TLS certificates

TLS certificates are commonly used in almost all modern websites and APIs. Most people know they “enable HTTPS”, but how they work and how to deploy them correctly are often misunderstood. This short note provides a simple explanation on this topic and hope it will be helpful.

What are TLS certificates

At its core, a TLS (Transport Layer Security) certificate is a digital document that binds an identity (such as a domain name like example.com) to a public key.

A TLS certificate answers a very simple question: “When I connect to this server, how do I know it is really who it claims to be?”.

A certificate is part of a trust chain, not a standalone item. It contains:

The Subject: Who the certificate is issued to (domain name or organization).
The Public Key: Cryptographic material used to initiate secure communication.
The Digital Signature: A cryptographic seal from a Certificate Authority (CA) stating: “We have verified that this identity and public key belong together.”
Validity Period: The time window during which the certificate is considered valid.

The certificate itself is public information. The security of TLS relies on a corresponding private key, which must remain secret.

Public key and private key

TLS uses asymmetric cryptography, which is based on a mathematically linked key pair:

Public key: Contained within the TLS certificate and shared openly. It allows clients to verify the server’s identity and securely exchange the parameters needed for the encrypted session.
Private key: Retained exclusively by the server owner. It is used to prove ownership of the certificate and to decrypt or sign data during the initial handshake. If this key is compromised, the security of the entire connection is void.

These keys are governed by two fundamental principles:

Asymmetric operations: Data encrypted with the public key can only be decrypted by the corresponding private key. Conversely, the private key can “sign” data to create a digital signature that can be verified by the public key, proving the data’s origin.
One‑way feasibility: While the keys are mathematically related, it is computationally infeasible to derive the private key from its public counterpart, even with immense computing power.

How TLS certificates work

A valid TLS certificate proves who the server is (authentication) and ensures no one can listen in (encryption). It does not determine what a user is allowed to do (authorization).

The TLS handshake is a multi-step process that establishes identity before initiating encryption.

1. Authentication: proving server identity

The authentication phase ensures the client is talking to the intended recipient, not an impostor:

The exchange: A client (browser or app) connects to the server, and the server presents its TLS certificate containing its public key.
Validation: The client verifies the certificate’s metadata: the domain name matches, the expiration date is valid, and the digital signature is from a trusted certificate authority.

At this stage, the client trusts the certificate, but not yet the server itself. Since certificates are public, the server must prove it possesses the corresponding private key. It does this by signing a piece of handshake data. If the client can verify that signature with the public key, it confirms the server is the legitimate owner.

2. Encryption: establishing a secure channel

Once identity is confirmed, the two parties agree on a Session Key to encrypt the rest of the conversation.

Session key exchange:

The client generates a random session key.
The session key is encrypted using the server’s public key.
The server decrypts it using the private key.

Once both sides have the session key:

All further communication switch to symmetric encryption.
This is significantly faster than asymmetric cryptography for data transfer.

The private key is no longer involved in the data transfer; its role is strictly limited to the initial identity verification and secure setup.

How to correctly deploy the certificates

Deployment errors are the most common source of TLS failures, especially around certificate chains.

1. Server-side: the “full chain”

The server (like Traefik, Nginx, or an AKS Ingress) must have:

Private key: Stored securely and never shared.
Server (leaf) certificate: Identifies the server and includes the public key.
Intermediate CA certificate(s): Used to link the server certificate back to a trusted root.

In most setups, the server must present a certificate chain that contains the certificates in a specific hierarchical order: Server (leaf) -> Intermediate CA 1 -> Intermediate CA 2 (if any). The private key must never be bundled with the public certificate file.

2. Client-side: the trust store

The client (like browser, application, or backend service) decides what to trust:

Operating systems, browsers, and runtimes contain a root CA trust store.
If the server’s certificate chain can be traced back to a trusted root, the connection succeeds.

If we are using internal or self-signed certificates, the client will fail because the custom root CA is not in its store. We must manually install the root CA into the client’s environment.

TLS interception (SSL inspection)

While TLS is designed for end-to-end privacy, many organizations implement TLS Interception to maintain visibility into network traffic. This technique allows a security appliance (a “middlebox” like a firewall or proxy) to scan encrypted data for malware or sensitive data leaks.

1. How the “Man-in-the-Middle” works

TLS interception effectively “breaks” the single TLS connection into two separate, secure segments:

Client to proxy: The client connects to the proxy. The proxy presents a generated certificate that impersonates the destination website.
Proxy to server: The proxy initiates its own TLS connection to the actual destination server, performing standard certificate validation on the server’s real certificate.

2. The trust requirement

For this to work without the user seeing a “Your connection is not private” warning, a specific trust configuration must exist:

The private CA: The organization maintains a private root CA on the intercepting appliance.
Deployment: This private root CA must be manually installed into the trusted root store of every managed device in the organization.
Dynamic signing: When a user visits a site, the appliance uses its private CA to create a “fake” (but technically valid) certificate for that site on the fly.

3. Critical considerations

The privacy trade-off: While this detects threats, it also means the organization can technically view sensitive data unless specific “Bypass Lists” are configured.
Certificate pinning: Applications that use certificate pinning (hard-coding the expected public key of the server) will often break during interception, as the public key provided by the proxy does not match the hard-coded “real” key.
Security responsibility: The intercepting middlebox becomes a high-value target. If the middlebox’s private key is compromised, an attacker could intercept all traffic across the entire organization without triggering any browser warnings.

Some notes and clarifications

1. Why the root CA should not be installed on the server

It is a common misconception that the entire chain, including the root, should be sent by the server. However, root CAs are trust anchors, not identity markers:

Trust is a client-side decision. A client trusts a certificate because it already possesses the root CA in its local trust store.
Sending the root CA from the server adds no security value. This can also lead to unnecessary performance overhead.

2. Missing intermediate CA on the server

Deploying only the leaf (server) certificate without its Intermediate CAs is a leading cause of intermittent TLS issues:

Errors such as unable to get local issuer certificate.
Trust failures on devices such as mobiles and CLI tools, though desktop browsers work fine.

The correct fix is configuring the server to present the full certificate chain, including both the leaf certificate and intermediate CA.

However, when the server cannot be changed, a temporal workaround is:

Install the missing intermediate CA on the client, or
Bundle it into the application or container image.

We should note that this is a “brittle” fix that increases the administrative burden during certificate rotation.

3. Self‑signed and private CAs

A self‑signed certificate provides full encryption. What it lacks is external identity validation. Clients must explicitly trust the issuing root CA.

Even for private PKI (Public Key Infrastructure), the root CA is a client-side trust anchor and thus the server should not send it.