Securing Communication with SSL/TLS
ZIO HTTP supports securing communication between entities—typically clients and servers—using SSL/TLS. This is crucial for protecting sensitive data in transit and ensuring both the integrity and authenticity of the communication.
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols designed to provide secure communication over a network. Although the terms are often used interchangeably, TLS is the modern, more secure successor to SSL. SSL, originally developed in the 1990s, had several vulnerabilities, which led to the development of TLS as an improved replacement. Despite this, the term “SSL” is still commonly used out of habit—much like how people still say “dial a number” even though phones no longer have rotary dials.
SSL/TLS relies on a system called Public Key Infrastructure (PKI), which uses digital certificates to verify the identities of the communicating parties and to establish secure connections.
In simple terms, PKI acts like an identity check—it ensures a website is who it claims to be—while SSL/TLS establishes the encrypted connection. When you visit a secure website, PKI verifies the site's legitimacy through its certificate, and SSL/TLS creates an encrypted tunnel so your data can travel safely. PKI handles identity verification, and SSL/TLS handles secure communication.
We aim to offer a comprehensive guide on this topic through a series of articles. Before diving into the details, it's important to understand the fundamental concepts. This article covers the core principles to help you build a strong foundation. In the following articles, we’ll explore each implementation approach in depth.
If you're already familiar with PKI and SSL/TLS, feel free to skip this article and move directly to the implementation guides:
- Implementing TLS With Self-Signed Server Certificate
- Implementing TLS With Root CA-Signed Server Certificate
- Implementing TLS With an Intermediate CA-signed Server Certificate
- Implementing Mutual TLS (mTLS)
Certificates and Public Key Infrastructure (PKI)
SSL/TLS relies on a Public Key Infrastructure (PKI) to establish trust between parties. PKI is a framework that secures communication and verifies identities using digital certificates and public/private key pairs. A certificate is a digital document that binds a public key to an entity, such as a server or client.
For example, an SSL certificate for the website "example.com" contains the site's public key and confirms that the domain name "example.com" is associated with it. When you visit the secured "example.com" website, your browser checks the site's certificate to ensure that it is valid and issued by a trusted Certificate Authority (CA). If the certificate is valid, your browser establishes a secure connection by generating a session key, encrypting it with the website's public key (extracted from the certificate), and securely sending it to the server. Only the server can decrypt the session key using its private key. From that point on, the browser and server use the session key to encrypt all data using fast symmetric encryption.
A Certificate Authority (CA) is a trusted third party that issues digital certificates. It verifies the identity of the entity requesting the certificate and signs the certificate with its private key, creating a chain of trust. When your browser encounters a certificate signed by a CA, it checks whether the CA is in its list of trusted authorities. If it is, the browser trusts the certificate and establishes a secure connection.
However, browsers have a limited number of trusted CAs built in. So what happens if the CA that issued a certificate is not pre-installed in the browser? This is where the concept of a Certificate Chain comes into play. It allows the browser to verify the certificate even if the issuing CA is not directly trusted.
Understanding the Certificate Chain (Chain of Trust)
A Certificate Chain, also known as a Chain of Trust, is a sequence of certificates that links your website's SSL certificate to a trusted root Certificate Authority (CA). When a browser encounters a certificate that is not directly trusted, it can follow the chain of trust to find a certificate that is trusted.
To understand how this works, we have to learn about the different types of certificates involved in SSL/TLS communication and how they relate to each other in a hierarchical structure. There are three main types of certificates:
End-entity certificates are the certificates deployed on servers, applications, or devices to establish secure connections and prove identity. These contain the public key and identity information (like a domain name or email address) for the specific entity they represent. When you visit an HTTPS website, the SSL certificate presented is an end-entity certificate. These certificates sit at the bottom of the trust chain and cannot be used to sign other certificates; they only authenticate the final endpoint.
Intermediate certificates act as a bridge between root and end-entity certificates, forming the middle layer of the certificate chain. Signed by root CAs or other intermediates, they have authority to issue end-entity certificates or additional intermediate certificates. This delegation allows organizations to keep root certificates secure and offline while still managing day-to-day certificate issuance, creating a hierarchical structure that enables selective revocation without affecting the entire trust chain.
Root certificates are the foundational trust anchors of the PKI system, representing the highest authority level. These self-signed certificates contain the root CA's public key and are embedded directly into operating systems and browsers as pre-trusted entities. Root CAs keep their private keys in highly secure, offline environments and typically only sign intermediate certificates rather than end-entity certificates directly. All certificate validation ultimately traces back to these trusted roots.
At the bottom of a certificate chain sits the end-entity certificate (leaf certificate), which contains the public key for a specific entity like a website and is signed by an intermediate CA. Above this are one or more intermediate certificates that bridge the gap between the end-entity and root. Each intermediate is signed by the certificate directly above it in the chain. At the top is the root certificate, self-signed by the root CA and pre-installed in browsers and operating systems as a trusted authority. This hierarchical structure creates a verifiable trust path from any certificate up to a universally trusted source.
Think of the trust chain like a chain of personal recommendations. You might not know someone directly, but if your trusted friend vouches for their friend, who vouches for another person, you can trace that trust back to someone you know.
Without this chain structure, your browser would need to personally "know" and trust every single website's certificate individually—that would mean storing millions of certificates. Instead, browsers only need to trust a small number of root certificates, and these roots can vouch for intermediates, which can vouch for many websites.
This system also provides safety through isolation. If one intermediate certificate gets compromised, only the certificates it signed are affected—not every certificate in existence. It's like having multiple managers in a company instead of the CEO signing every document personally.
How SSL/TLS Works in Practice
Now, let's see how SSL/TLS works in practice when you visit a secure website. Think of certificates like digital ID cards for computers and websites, but with a clever twist involving special key pairs and a chain of trust.
Every TLS-enabled website has two mathematically connected keys:
- Private Key: Like a secret signature that only the website knows - kept completely secret
- Public Key: Like a stamp of that signature that can be shared with everyone
These keys have a special relationship: anything "signed" with the private key can be verified using the public key, but you can't figure out the private key from the public key.
When you visit a website, here's what happens (please note that this is a simplified explanation):
Website Shows Its Papers: The website presents not just its own certificate, but the entire chain:
- Its own certificate (signed by Intermediate CA)
- The Intermediate CA's certificate (signed by Root CA)
- Sometimes multiple intermediate certificates
Browser Verifies the Chain: Your browser works backwards up the chain:
- "Is the website's certificate properly signed by the Intermediate CA?" ✓
- "Is the Intermediate CA's certificate properly signed by the Root CA?" ✓
- "Do I trust this Root CA?" (checks its built-in list) ✓
Identity Verification: Once the chain is verified:
- Browser says: "Prove you're really example.com"
- The website uses its private key to sign a response
- Browser uses the public key from the website's certificate to verify that signature
- If it matches, the connection is secure
The power of this approach is that your browser only needs to trust a few Root CAs, but through the chain of trust, it can verify millions of websites worldwide.
One-Way TLS vs. Mutual TLS (mTLS)
The process we've described so far - where your browser verifies a website's identity but the website doesn't verify yours - is called one-way TLS (also known as standard TLS or server-side authentication). This is what happens in most everyday web browsing scenarios.
In one-way TLS:
- Only the server is authenticated - the client (browser) verifies the server's identity using certificates
- The client remains anonymous - the server has no cryptographic proof of who the client is
- The connection is still encrypted - data flows securely in both directions, but only server identity is verified
This works perfectly for most web applications where you want to ensure you're talking to the real bank website, but the bank doesn't need to cryptographically verify your identity upfront (they'll verify you through username/password or other means after the secure connection is established).
What is Mutual TLS (mTLS)?
Mutual TLS (mTLS) takes security a step further by requiring both parties to authenticate each other using certificates. Instead of just the server proving its identity to the client, the client must also prove its identity to the server using its own certificate.
Think of it like police officers where:
- One-way TLS is like when a police officer approaches you - they show their badge to prove they're legitimate law enforcement, and you verify the badge is real, but you don't need to show your ID back to them
- Mutual TLS (mTLS) is like when two undercover officers meet - they both need to show each other their credentials and verify each other's legitimacy before proceeding with their operation
How mTLS Works
In an mTLS handshake, the process extends beyond standard TLS:
- Server Presents Its Certificate: Just like in one-way TLS, the server presents its certificate chain to the client
- Client Verifies Server: The client validates the server's certificate chain and identity (same as one-way TLS)
- Server Requests Client Certificate: Here's where mTLS differs - the server asks the client to present its own certificate
- Client Presents Its Certificate: The client sends its own certificate (and chain if applicable) to the server
- Server Verifies Client: The server validates the client's certificate chain and identity
- Mutual Authentication Complete: Both parties have cryptographically verified each other's identities
When is mTLS Used?
mTLS is typically employed in scenarios requiring high security and where both parties need to be certain of each other's identity:
- Microservices Architecture: Secures service-to-service communication in distributed systems, particularly in containerized environments like Kubernetes where services need to verify each other's identity.
- API Security: Protects high-value APIs handling financial transactions, personal data, or proprietary information by requiring cryptographic proof of client identity beyond simple API keys.
- IoT Device Management: Authenticates devices before network access, preventing unauthorized devices from joining IoT deployments and protecting against device impersonation.
- Zero Trust Networks: Serves as a foundational component requiring every connection to be authenticated and encrypted regardless of network location.
- Financial Services: Enables secure interbank communications, payment gateway connections, and regulatory compliance for banks and fintech companies.
- Cloud Integration: Provides secure authentication for cloud-to-cloud communications and hybrid architectures without relying on shared secrets.
mTLS vs Other Authentication Methods
It's important to understand how mTLS differs from other authentication approaches:
- mTLS vs Username/Password: Unlike traditional username and password authentication, mTLS operates at the transport layer before any application data is exchanged. This fundamental difference means that certificates cannot be easily shared or compromised like passwords, eliminating the risk of common password-based attacks such as brute force attempts and credential stuffing. Additionally, mTLS works automatically without requiring user interaction once certificates are properly configured, providing seamless authentication.
- mTLS vs API Keys: While API keys offer a simple authentication mechanism, mTLS provides significantly stronger cryptographic proof of identity through certificate-based authentication. Certificates come with built-in expiration and revocation mechanisms that provide better security lifecycle management. They are also much harder to accidentally leak since they aren't simple strings that can be inadvertently logged or exposed. However, unlike API keys, certificates cannot be easily rotated programmatically, which can be both an advantage for security and a disadvantage for operational flexibility.
- mTLS vs OAuth/JWT: The key distinction here lies in the authentication layer where each method operates. mTLS authenticates at the connection level, while OAuth and JWT tokens work at the application level. This difference makes them complementary rather than competing technologies - mTLS can be effectively combined with OAuth to create layered security that ensures "the right device with the right user." It's important to note that mTLS focuses solely on authentication (verifying identity) and doesn't handle authorization (determining permissions), unlike OAuth which addresses both concerns.
Standards, Encodings and File Formats
When working with SSL/TLS, you'll encounter various standards, encodings, and file formats. Understanding these is crucial for effectively managing certificates and secure communication.
In this series of articles, we use X.509 certificates, which are the most common format for SSL/TLS certificates. X.509 is a standard that defines the format of public key certificates, including the structure of the certificate itself and how it should be signed.
Here are some of the key components of an X.509 certificate:
- Version: Indicates the version of the X.509 standard used (e.g., v1, v2, v3).
- Serial Number: A unique identifier assigned by the Certificate Authority (CA) to the certificate.
- Signature Algorithm: Specifies the algorithm used to sign the certificate (e.g., SHA256 with RSA).
- Issuer: Distinguished Name (DN) of the Certificate Authority (CA) that issued the certificate.
- Validity: The time period during which the certificate is valid, including start and end dates.
- Subject: Distinguished Name (DN) of the certificate holder (e.g., the server or organization the certificate represents).
- Subject Public Key Info: Contains the public key of the certificate's subject and the algorithm used with that key.
The following is an example of an X.509 certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:1b:2c:ce:d0:09:9e:28:6c:c6:6c:04:4a:4f:7e:c9:fb:06
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, O=Let's Encrypt, CN=E5
Validity
Not Before: Jun 2 15:35:11 2025 GMT
Not After : Aug 31 15:35:10 2025 GMT
Subject: CN=zio.dev
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:6d:d6:81:4c:da:b4:71:<reducted>
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
47:C0:B2:73:CA:24:16:7C:62:59:37:CB:E7:2A:02:EA:73:30:CD:0B
X509v3 Authority Key Identifier:
9F:2B:5F:CF:3C:21:4F:9D:04:B7:ED:2B:2C:C4:C6:70:8B:D2:D7:0D
Authority Information Access:
CA Issuers - URI:http://e5.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:*.zio.dev, DNS:zio.dev
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://e5.c.lencr.org/7.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 0D:E1:F2:30:2B:D3:0D:C1:40:62:12:09:EA:55:2E:FC:
47:74:7C:B1:D7:E9:30:EF:0E:42:1E:B4:7E:4E:AA:34
Timestamp : Jun 2 16:33:41.242 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:AF:62:38:A3:6C:F6:11:05:77:46:ED:
C0:34:3E:44:50:43:24:67:83:B8:62:7B:DE:7C:F1:39:
16:6F:B2:D2:3D:02:20:46:0B:EA:A5:36:E0:80:99:2E:
B8:E2:8D:97:5F:FA:1B:95:16:8C:F3:88:52:C5:17:E9:
96:14:8A:74:81:CC:7E
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : CC:FB:0F:6A:85:71:09:65:FE:95:9B:53:CE:E9:B2:7C:
22:E9:85:5C:0D:97:8D:B6:A9:7E:54:C0:FE:4C:0D:B0
Timestamp : Jun 2 16:33:43.251 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:C1:04:E6:A8:65:FE:5B:D6:DF:17:27:
BF:BC:FB:16:B6:A0:D1:03:14:46:AA:01:92:45:83:5E:
A6:0C:00:31:7B:02:20:2F:3D:2D:18:5C:F8:0A:02:B1:
62:F7:38:B2:E9:08:7F:04:C6:05:76:E4:26:FD:C5:81:
D7:33:20:FD:F4:65:73
Signature Algorithm: ecdsa-with-SHA384
Signature Value:
30:64:02:30:1d:c0:d3:dc:3f:fd:ef:54:d8:1c:28:05:57:36:
05:de:a6:83:7e:a3:5e:ee:54:7e:5c:09:44:91:4a:45:c0:16:
07:d3:d7:e9:cc:fe:83:0d:63:49:7f:75:e1:3b:2f:9e:02:30:
52:f8:7c:67:85:0d:3a:d9:80:df:74:3b:67:36:89:81:19:2f:
3e:50:62:9c:89:0b:9b:7e:52:93:ea:a2:01:54:85:02:18:2c:
8a:6f:19:c2:8d:13:96:11:27:bf:f3:a4
Each certificate can be encoded in different formats, with the most common being:
PEM (Privacy-Enhanced Mail): Base64 encoded format with header and footer lines (e.g.,
-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----). This is the most widely used format for SSL/TLS certificates.Here is an example PEM file:
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
... (more base64 data) ...
-----END CERTIFICATE-----DER (Distinguished Encoding Rules): Binary format that is not human-readable. It is often used in Java applications and some Windows systems.
Certificates are usually stored in files with the following common file extensions:
- .crt - Most common, usually PEM format
- .cer - Can be DER or PEM format
- .pem - Always PEM format
- .der - Always DER (binary) format
Besides the PEM and DER formats, you may also encounter envelope formats, such as PKCS#12 and PKCS#7:
- PKCS#12 (.p12 or .pfx): A binary format that can contain both the certificate and its private key, often used for importing/exporting certificates with their private keys. It is password-protected to secure the private key. These are used when we need to bundle the private key and certificate.
- PKCS#7 (.p7b or .p7c): A format that can contain multiple certificates (like a certificate chain) but does not include the private key. It is often used for distributing certificates and building certificate trust chains.
We may also store public keys in a file with a .pub or .pem extension and store private keys in files with .prv, .key or .pem extension.
There are more formats and file extensions, but for the purpose of this guide, we will focus on the most commonly used formats: PEM for certificates and private keys and PKCS#12 for bundles containing both certificates and private keys.
Now that we have covered the most basic concepts of SSL/TLS, certificates, and PKI, we can proceed to the implementation articles where we will explore how to set up SSL/TLS in ZIO HTTP applications using different approaches, including self-signed certificates, CA-signed certificates, intermediate CA-signed certificates, and mutual TLS (mTLS).
Conclusion
SSL/TLS and PKI form the foundation of secure internet communication. The key concepts covered—certificate chains, trust hierarchies, and the distinction between one-way TLS and mutual TLS—provide the knowledge needed to make informed security decisions for your applications.
PKI's hierarchical design allows a small number of trusted root CAs to secure millions of websites through intermediate certificates, creating a scalable trust system that spans from internal applications to global services.
With these fundamentals in place, you're ready to proceed to the implementation guides. Each approach serves specific use cases, and understanding their proper application will help you build more secure applications.