Mutual TLS in Axual Platform
This guide explains how Axual Platform authenticates connections with mutual TLS, the four distinct roles a component’s keystores and truststores play, and why certificate issuance is automated rather than done by hand. No commands appear here: How to Configure Certificates on an Axual Component holds the procedure.
Type |
Explanation |
Goal |
Understand what each keystore and truststore is for, so the right Secret ends up in the right value. |
Audience |
Operators and infrastructure engineers who issue or configure the platform’s certificates. |
When to use |
Read before configuring a component’s TLS settings, and whenever it is unclear which store a certificate belongs in. |
Why mutual TLS
Mutual TLS (mTLS) is the default method for authenticating client connections to Apache Kafka, Apicurio Registry and the other platform components. Ordinary TLS proves the server’s identity to the client. Mutual TLS proves both, because each side verifies that the other holds the private key matching the certificate it presented.
That matters for a streaming platform because authorisation depends on identity. A Kafka broker grants or denies access to a topic based on the principal it derives from the client’s certificate, so an unauthenticated client has no principal at all and the broker cannot place it against any rule.
Axual components negotiate TLSv1.2. The accepted cipher suites and key lengths are listed in Certificate and key requirements.
The four stores, and why a component needs all of them
Because every connection is authenticated in both directions, a component is both a server and a client, and each of those roles needs both a key to present and a set of certificates to trust. That is what produces four stores rather than one.
- Server Keystore
-
Holds the keypair the component presents on the endpoint it hosts, whether that endpoint is raw TCP or HTTPS. For an HTTPS endpoint the certificate’s CN must match the fully qualified domain name callers use, or the caller rejects the connection before any authorisation happens.
- Server Truststore
-
Holds the certificates the component trusts when validating a client that connects to it. It contains public certificates only, typically certificate authorities, and never a keypair.
- Client Keystore
-
Holds the keypair the component presents when it connects out to another component. Only needed where the other end requires a client certificate, which on this platform is the normal case.
- Client Truststore
-
Holds the certificates the component trusts when validating the remote end of an outbound connection. Only needed where those remote endpoints are TLS encrypted.
The split between the two truststores exists so the two directions can diverge. Internal components usually share a single truststore Secret, because they all trust the same internal certificate authority, and a deployment only separates them when inbound and outbound traffic are anchored to different authorities.
Why certificate issuance is automated
Every component needs certificates for mTLS, and certificates expire. Issuing them by hand recurs on every renewal interval, for every component, and a certificate that expires unnoticed takes its component offline rather than degrading it.
That is why Axual recommends cert-manager for issuing and renewing certificates, paired with Reloader to restart the pods that hold them. Renewal without a restart leaves a component using the certificate it loaded at startup, so the two tools solve halves of the same problem.
The platform does not require either. It reads Kubernetes Secrets, and whether those Secrets are produced by cert-manager or written by hand makes no difference to it, which is why the formats are documented independently of the tool that creates them.