A common point of failure in infrastructure is the untrusted certificate error that seems to defy logic. These issues are rarely about a single certificate file. They are about a break in the Chain of Trust, the hierarchy that connects your server to a trusted authority. Learning to navigate this hierarchy is the single most effective way to solve the majority of infrastructure-level SSL and TLS failures.

Anatomy of a Chain

When you run openssl s_client -connect google.com:443 -showcerts, the first thing you see is the Depth List. This provides a map of the entire hierarchy.

depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
depth=1 C=US, O=Google Trust Services, CN=WR2
depth=0 CN=*.google.com

In this output, OpenSSL counts down toward the website. Depth 2 is the Root, which represents the ultimate authority. Depth 1 is the Intermediate, and Depth 0 is the Leaf, the actual certificate for the website you are visiting.

This three-tier structure exists for security management. Think of it like a high-security building. You have a Master Key, the Root CA, that stays locked in a fireproof vault. In professional security environments, the computer holding this key is often “air-gapped,” meaning it is never connected to a network. This ensures the Master Key is never used for daily tasks. Instead, you use it once to authorize a Manager’s Key, the Intermediate CA. That manager then walks the halls and issues Apartment Keys, the Leaf Certificates, to tenants. If a manager loses their key, you can revoke it using the Master Key without rebuilding the entire vault.

Every certificate contains two critical fields that create the links in the chain. The Subject identifies who the certificate belongs to, while the Issuer identifies who vouched for it. In a valid chain, the Issuer of one certificate must be the Subject of the next one up.

Certificate 0 (Leaf)
   s:CN=*.google.com
   i:CN=WR2

Certificate 1 (Intermediate)
   s:CN=WR2
   i:CN=GTS Root R1

Certificate 2 (Root)
   s:CN=GTS Root R1
   i:CN=GTS Root R1

The Leaf says its issuer is WR2, which matches the subject of the Intermediate. The Intermediate identifies its issuer as GTS Root R1, which matches the subject of the Root. Notice that the Root certificate has an identical Subject and Issuer. This is a Self-Signed Certificate. Because there is no higher authority to vouch for the Root, it essentially vouches for itself. This is why Trust Stores are essential. Your computer must already possess a copy of this Root certificate in its list of trusted authorities to believe it.

The Cryptographic Stamp

Matching names are not enough to establish trust because anyone can write a fake name on a digital file. Each certificate includes a Digital Signature to provide mathematical proof of its origin. When an Intermediate signs a Leaf, it uses its Private Key to create a cryptographic stamp. Your computer then uses the Intermediate’s Public Key, which is found inside the Intermediate’s own certificate, to verify that stamp.

This verification continues up the chain until it reaches the Root. Since the Root is the final authority, your computer does not verify its signature against another certificate. Instead, it checks its own Trust Store. This is a pre-installed list of Master Keys that your operating system or browser is allowed to believe.

Managing Trust and Common Failures

Understanding this hierarchy simplifies the process of debugging SSL errors. The most frequent issue is the missing intermediate certificate. This happens when a server provides the Leaf but fails to send the Intermediate. While some browsers might have the Intermediate cached from previous sessions, a new visitor will see a trust error because the link back to the Root is broken.

If a certificate needs to be cancelled before it expires, the authority uses revocation. This is handled through a Certificate Revocation List (CRL), a simple list of cancelled serial numbers, or the Online Certificate Status Protocol (OCSP), which allows a browser to check a certificate’s status in real time. If the “Manager’s Key” mentioned in our analogy is compromised, the “Owner” adds it to these lists so browsers know to stop trusting it immediately.

In corporate environments, organizations often act as their own Root Authority. If you try to access an internal site from a device that has not been told to trust the company Root, the handshake will fail. The certificate is technically valid, but the owner is not recognized by your Trust Store.

Applications handle this trust through different mechanisms. Many tools like curl or Go applications rely on the System Trust Store. On Ubuntu or Debian, you place the root certificate in /usr/local/share/ca-certificates/ and run update-ca-certificates. Java environments use a dedicated file called cacerts, which requires the keytool utility for imports. Infrastructure tools like Nginx or Kong often require you to explicitly point to CA bundles in their configuration files.

Verification with OpenSSL

The openssl utility is the standard tool for identifying exactly where a security handshake is falling apart. At the center of these debugging efforts is s_client. This is essentially a generic SSL and TLS client. Just as you might use netcat (nc) to test a raw TCP connection, you use s_client to establish a secure connection, perform the handshake, and inspect the certificates provided by the server.

You can verify a remote certificate and check its trust status using a brief connection.

openssl s_client -connect google.com:443 -brief

A successful connection returns Verification: OK. If the Root is missing or unrecognized, you will see Verification error: self-signed certificate. An expired certificate will return Verification error: certificate has expired.

To inspect the full chain, including all intermediates, use the -showcerts flag. This displays the certificate chain with subjects and issuers for the leaf and all intermediates. If a website supports multiple protocols, you can force a specific version to test for legacy compatibility or modern security requirements.

# Force TLS 1.2 to test older client compatibility
openssl s_client -connect google.com:443 -tls1_2

# Force TLS 1.3 to ensure modern security is active
openssl s_client -connect google.com:443 -tls1_3

For websites that host multiple domains on a single IP address, you must use the -servername flag. This tells the server which specific certificate you are looking for through Server Name Indication (SNI). Without this flag, the server might return the wrong certificate, leading to a false trust error.

openssl s_client -connect google.com:443 -servername google.com -brief

If you need to perform an inspection without connecting to the server again, you can download the certificate locally.

openssl s_client -connect google.com:443 -servername google.com </dev/null | openssl x509 -outform PEM > server_cert.pem

The following command then converts the binary or PEM data into human-readable text, showing the public key details, serial numbers, and all extensions.

openssl x509 -in server_cert.pem -text -noout

If you need to verify a local certificate against a specific root, use the verify command. This is particularly useful when testing your companys internal CA files before deploying them to your application.

openssl verify -CAfile internal-root-ca.pem leaf-cert.pem

Common Challenges

While the theory of chains is consistent, these two scenarios represent the most frequent issues encountered during deployment.

Subject Alternative Name (SAN) Mismatches

Historically, certificates used the Common Name (CN) field to identify a domain. However, the CN is limited to a single value. Modern standards have replaced this with the Subject Alternative Name (SAN) extension, which supports a list of multiple hostnames and IP addresses.

Modern TLS libraries prioritize the SAN extension over the legacy Common Name field. If a certificate contains a SAN list, the library ignores the Common Name entirely. If the SAN extension is missing, many clients reject the connection as insecure. To avoid this, ensure your certificate generation scripts explicitly include the subjectAltName extension for all required hostnames.

Untrusted Container Environments

Minimal container images often lack the ca-certificates package. This leaves the application without a list of trusted root authorities, causing even valid connections to public APIs to fail with an “unknown authority” error. Resolve this by installing the ca-certificates package in your Dockerfile to provide the environment with a standard set of trusted roots.

Summary

The Chain of Trust is a logical progression from a specific website back to a globally recognized authority. By understanding the relationship between Subjects and Issuers, you can move beyond treating SSL errors as mysterious warnings and start treating them as broken links in a predictable chain. Whether you are managing internal company certificates or debugging a public-facing proxy, the process remains the same: identify the missing link, verify the signature, and ensure the Root is present in your Trust Store.