Keystore vs Truststore — How SSL Certificate Chain Actually Works (with java Examples)

When you see the 🔒 HTTPS lock icon in your browser, something important has already happened behind the scenes.

Your browser has verified:

• The identity of the server
• The certificate chain
• The trusted Certificate Authority

But where are these certificates stored?
And how does the verification actually work?

This is where Keystore and Truststore come in.

In this article we will cover:

• What a Keystore is
• What a Truststore is
• How the certificate chain works
• How they are used during the TLS handshake
• Examples using keytool
• Common SSL handshake errors
• A quick look at Mutual TLS (mTLS) (two-way TLS (or two-way SSL)

🧾 Certificate Creation Flow

Before talking about keystore and truststore, let's see how a certificate is created.

1. The server generates a public/private key pair.
2. It creates a CSR (Certificate Signing Request).
3. The CSR is sent to a Certificate Authority (CA).
4. The CA verifies the identity of the organization.
5. The CA issues a leaf certificate.
6. The certificate is signed by an Intermediate CA.
7. The intermediate CA is signed by a Root CA.

This produces a certificate chain.
Example chain:

Root CA
↓
Intermediate CA 1
↓
Intermediate CA 2
↓
Leaf Certificate (Server Certificate)
Each certificate is digitally signed by the one above it.

🏪 What is a Truststore?

A Truststore is a secure repository that contains certificates from trusted entities.

These certificates are used to verify the identity of remote systems during secure communication.

A truststore typically contains:

Trusted Root Certificates

These are:

• Self-signed certificates
• Issued by trusted Certificate Authorities
• Preinstalled in operating systems, browsers, or Java runtimes

Intermediate CA Certificates

Intermediate certificates help bridge the chain of trust between a root CA and the server certificate.

🎯 Purpose of Truststore

The truststore is used to validate certificates presented by other parties.

Example:
When a browser connects to:
https://myserver.com

The browser:

1. Receives the server’s certificate
2. Builds the certificate chain
3. Verifies the chain up to a trusted root certificate in its truststore

If the verification succeeds, the connection is trusted.
If not, the browser displays a certificate warning.

🔑 What is a Keystore?

A Keystore is a secure repository that stores your own cryptographic identity.

It usually contains:

• Server private key
• Server leaf certificate
• Sometimes intermediate certificates

Note: The private key stored in the keystore corresponds to the leaf certificate of the server.

The private key is used during the TLS handshake to prove ownership of the certificate.
It must never be shared.

🔄 How Keystore and Truststore Work Together

During the TLS handshake:

Step 1 — Client connects to server

The client initiates a secure connection.

Step 2 — Server sends certificate chain

The server sends:
Leaf Certificate
Intermediate Certificates

Step 3 — Client validates the chain

The client verifies:
Leaf Certificate
↓
Intermediate Certificate
↓
Root CA
The root CA must exist in the client's truststore.

Step 4 — Secure connection established

If the certificate chain is valid and trusted, the TLS session is established.

☕ Java Example — Keystore

In Java applications, keystores are commonly stored as:
.jks
.p12

Create a Keystore

keytool -genkeypair \
-alias myserver \
-keyalg RSA \
-keysize 2048 \
-keystore keystore.jks

This above command generates:

• A private key
• A self-signed certificate

View Keystore Contents

keytool -list -v -keystore keystore.jks
Example output:
Alias name: myserver
Entry type: PrivateKeyEntry
Certificate chain length: 1

☕ Java Example — Truststore

Java provides a default truststore which is:
$JAVA_HOME/lib/security/cacerts
Default password:
changeit
List certificates in the truststore:
keytool -list -keystore $JAVA_HOME/lib/security/cacerts
This truststore contains nearly two hundred trusted CA certificates.

Import Certificate into a Truststore

When the certificate is trusted by the Truststore
Example
keytool -importcert \
-alias myserver \
-file server.crt \
-keystore truststore.jks

⚠️ SSL Handshake Errors Related to Certificate Issues

Many SSL handshake failures occur because of certificate chain or trust problems.
Here are some of the most common errors.

SSL Handshake Failed / Error 525

This indicates that the client and server failed to establish a secure connection.
A common cause is an incomplete certificate chain, where the server does not send the required intermediate certificates.

Certificate Unknown (Java / JSSE)

In Java applications, you may see errors such as:
javax.net.ssl.SSLHandshakeException:
PKIX path building failed
This means the client cannot verify the certificate chain, usually because the issuing CA is not present in the truststore.

ERR_CERT_AUTHORITY_INVALID (Browser)

Browsers show this error when:

• The root CA is not trusted
• The intermediate certificate is missing

• The certificate is self-signed
  The certificate chain was issued by an authority that is not trusted
  This error commonly appears in:

• SQL Server connections

• Internal client-server applications
  It occurs when the client cannot recognize the certificate authority that signed the server certificate.

SSL error: 0x8009001a (SChannel)

In Windows systems using SChannel, this error usually indicates:

• An invalid certificate
• A broken certificate chain
• A trust validation failure

Key Takeaway

Most SSL handshake errors occur because:

• The client truststore does not trust the CA
• The server did not send the full certificate chain
• The certificate has expired or is invalid Understanding keystore and truststore helps quickly diagnose these issues.

🔐 Mutual TLS (mTLS) (Or two-way TLS (or two-way SSL)

In standard TLS:
Client verifies Server
In Mutual TLS (mTLS):
Client verifies Server
Server verifies Client

Both sides present certificates.
Flow:

1. Client connects to server
2. Server presents its certificate
3. Client verifies it using its truststore
4. Server requests client certificate
5. Client sends its certificate
6. Server verifies it using its truststore mTLS is commonly used in:

• Microservices architectures
• Banking systems
• Internal APIs
• Zero-trust security environments

🧠 Summary

Keystore: Stores private keys and certificates used to prove identity
Truststore: Stores trusted CA certificates used to verify others
Certificate Chain: Establishes trust from server certificate to a trusted root CA

Every secure TLS connection depends on this chain of trust.

📌 Final Thought

Next time you see the 🔒 lock icon in your browser, remember:
Behind that simple symbol is a complex system involving:

• certificate chains
• keystores
• truststores
• certificate authorities

—all working together to ensure secure communication.