Mutual TLS for Galera clusters tightens passbolt database trust

At a glance

What this is: This is a Passbolt lab walkthrough showing how mutual TLS changes trust in a MariaDB Galera-backed passbolt deployment by binding database trust to certificates instead of IP addresses.

Why it matters: It matters because IAM and platform teams running self-hosted secrets systems need to govern database access as an identity problem, not just a network encryption problem.

Context

MariaDB Galera Cluster is a multi-primary database architecture that keeps replicas synchronised across nodes, which changes how a self-hosted passbolt deployment handles availability and maintenance. In this setup, the security question is not only whether traffic is encrypted, but whether the nodes and the application can prove who they are before replication or login proceeds.

Passbolt’s lab frames mutual TLS as the missing trust layer for clustered database access. That is directly relevant to identity governance because certificates, hostnames, and DNS become part of the access control path for a critical backend that stores credentials.

The article’s configuration is a practical lab, but the model it tests is broader than one deployment. Any team running clustered databases for secrets, identity services, or other sensitive workloads should treat transport identity as part of the access architecture, not a network afterthought.

Key questions

Q: How should security teams authenticate clustered database nodes without relying on IP-based trust?

A: Use mutual TLS so each node presents a certificate and validates its peers against a trusted CA. That makes cluster membership a cryptographic identity decision rather than a network-location assumption, which is much safer when nodes move across subnets, racks, or data centres.

Q: Why does mutual TLS matter for a self-hosted secrets application backed by a database cluster?

A: Because the application is not only protecting traffic, it is protecting the trust relationship with the database that stores credentials. mTLS ensures the client and the database both prove identity before access is granted, which reduces the risk of brittle shared-network trust.

Q: What do teams get wrong about TLS in clustered database environments?

A: They often treat encryption as the finish line, but TLS without mutual authentication still leaves peer identity under-validated. In a cluster, that is a governance gap because the system needs to know not just that traffic is encrypted, but who is talking to whom.

Q: When should organisations use certificates instead of firewall rules to control database access?

A: Use certificates when the topology is likely to change, the database is distributed, or the application is sensitive enough that identity should follow the workload. Firewall rules still matter, but they should not be the primary proof of trust for clustered database access.

Technical breakdown

Why Galera clustering changes the trust model for passbolt

Galera is a virtually synchronous, multi-primary database cluster, so node-to-node replication and client connections are part of one distributed trust boundary. That matters because the application no longer talks to a single fixed database endpoint. Instead, it relies on cluster membership, DNS, certificate subjects, and replication channels staying aligned as nodes move, scale, or fail over. In that model, simple encryption is not enough. The system needs to verify that each peer is the expected node and that the client is the expected application before it accepts data or replication traffic.

Practical implication: Treat clustered database access as an identity and trust design problem, not just a connectivity problem.

How mutual TLS binds peer identity to cluster traffic

Standard TLS protects confidentiality, but mTLS adds mutual authentication, so both sides present certificates and validate them against a trusted CA. In the Galera flow, each node proves itself before replication proceeds, and passbolt proves itself before MariaDB accepts the connection. Hostname validation through SANs matters because cluster nodes may be addressed by short names or DNS aliases. That shifts trust from mutable network location to explicit cryptographic identity. The result is a more stable control plane for environments where nodes can move across subnets, racks, or data centres.

Practical implication: Use certificate identity and SAN design as first-class inputs to cluster topology and client connectivity.

Why certificate lifecycle now carries access governance weight

The lab uses one root CA to sign node and client certificates, which simplifies trust distribution but also concentrates governance responsibility. If the CA, server certificates, or client certificate for passbolt are mishandled, access breaks or trust expands beyond what was intended. Because MariaDB enforces client authentication with TLS and SSL requirements, certificate issuance and revocation become part of operational access control. In other words, the database is not just checking a password. It is checking whether the calling identity is part of the trusted certificate chain.

Practical implication: Govern certificate issuance, renewal, and revocation as part of privileged database access management.

NHI Mgmt Group analysis

Identity-bound transport trust is the decisive control in clustered database access. Passbolt’s lab shows that encrypted database traffic still leaves a governance gap if the application and database nodes are not mutually authenticated. When cluster members can move across subnets or data centres, IP-based trust becomes brittle and hard to audit. The practitioner lesson is that database connectivity for sensitive systems should be governed as a certificate-backed identity relationship, not a network shortcut.

Certificate architecture becomes access architecture once the database is clustered. A single CA can simplify operations, but it also defines the root of trust for every node and client certificate in the environment. That means SAN design, hostname consistency, and client certificate handling are no longer implementation details. They are part of the access model that determines who can join the cluster and who can connect to it. The governance implication is that database trust must be designed alongside topology.

Galera changes the security value of availability engineering. Rolling maintenance, no replica lag, and multi-node resilience are operational benefits, but they only remain safe when the trust fabric keeps pace with the cluster fabric. If nodes are authenticated by certificates rather than IPs, the architecture can scale without rewriting firewall rules for every topology change. That makes mTLS a governance enabler for distributed secrets backends, not merely a transport setting.

Clustered secrets systems need a named trust boundary, not implicit network confidence. A passbolt deployment backed by Galera is a good example of how identity governance reaches into the database tier. The trust boundary is not the subnet; it is the certificate chain, the hostname mapping, and the authenticated client identity. Practitioners should treat that boundary as part of their NHI and platform access model, because it governs how critical credentials are stored and served.

Operational convenience should not be confused with trust reduction. Galera makes distributed database operations easier, but the security gain comes only when the surrounding identity controls are explicit. Certificates, DNS, and client requirements such as REQUIRE SSL define whether the cluster accepts traffic from the intended application path. The practical conclusion is straightforward: if the database is part of a credential system, the access path itself must be governed with the same discipline as the secrets it protects.

What this signals

Certificate-backed trust is becoming the practical control plane for distributed database identity. Once replication and application access span multiple hosts, network position stops being a reliable proxy for trust. Practitioners should expect more of their access decisions to move from firewall logic into certificate lifecycle governance and hostname validation.

Passbolt’s lab also shows why clustered secrets backends need explicit trust boundaries. If the certificate chain, SANs, and DNS mapping are not managed together, the cluster may still function, but its identity assurances become fragile in ways that are hard to see during normal operations.

For practitioners

• Define certificate-backed database trust boundaries Map which database nodes and applications are allowed to authenticate via mTLS, and document the trusted CA, hostnames, and client certificates that make that trust valid.
• Align SANs with cluster naming conventions Make sure server certificate SANs match every hostname actually used by cluster members and clients, including short names and DNS aliases, so validation does not depend on ad hoc network identity.
• Separate replication identity from host location Stop treating IP address or subnet membership as proof of trust for Galera peer traffic, and govern peer authentication through certificates instead of network position.
• Govern client certificate issuance and revocation Put passbolt database client certificates under the same lifecycle controls you would use for privileged access, including ownership, renewal, and removal when the application path changes.

Key takeaways

• Passbolt’s Galera lab shows that database clustering changes trust, not just availability, because nodes and clients must prove identity before access proceeds.
• The security value comes from certificate-based peer authentication, which replaces brittle IP-based assumptions with cryptographic identity.
• Teams running clustered secrets or database services should govern certificate lifecycle, SAN alignment, and client authentication as part of access control.

Key terms

• Mutual Tls: Mutual TLS is a transport security method where both client and server present certificates and authenticate each other. In implant frameworks, it helps prevent impersonation, supports encrypted sessions, and ties each deployment to its own trust material rather than shared credentials.
• Galera Cluster: Galera Cluster is a multi-primary MariaDB replication architecture where nodes can read and write while synchronising write-sets across the cluster. For security teams, the important point is that node membership and trust become part of the identity model, not just database availability engineering.
• Certificate SAN: A Subject Alternative Name is the hostname or identifier list embedded in a certificate that determines what names the certificate is valid for. In clustered environments, SAN management is critical because hostname mismatch can break validation, force exceptions, or create silent trust drift.
• Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.