Mutual TLS for Galera clusters tightens passbolt database trust

At a glance

What this is: This is a lab walkthrough showing how MariaDB Galera Cluster and mutual TLS secure passbolt database connectivity and node-to-node replication.

Why it matters: It matters because IAM and NHI teams need to treat database access as an identity problem, where certificates, hostnames, and trust chains shape both resilience and blast radius.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Passbolt's article on passbolt with MariaDB Galera Cluster and mTLS

Context

Mutual TLS, or mTLS, is two-way certificate authentication. In this lab, it is the mechanism that lets passbolt trust MariaDB nodes by identity rather than by network location, which is a more durable model for distributed database access.

The governance issue is not just transport encryption. For NHI and workload identity programmes, clustered databases become an access-control problem as soon as replication, client access, and failover cross subnets or sites. That makes certificate lifecycle, hostname discipline, and trust-chain management part of identity security rather than infrastructure hygiene.

Key questions

Q: How should security teams govern certificate-based access for clustered databases?

A: Treat certificates, hostnames, and CA trust as a single identity boundary. Assign ownership, track expiry, validate SANs against DNS, and require certificate-backed access for privileged applications. If any one of those elements drifts, the cluster may still run, but the trust model has already weakened.

Q: Why do mTLS and workload identity matter in distributed database environments?

A: Because distributed databases depend on knowing which node or application is connecting, not just whether traffic is encrypted. mTLS authenticates both sides of the session and gives teams a way to enforce identity across subnets, sites, and failover paths without relying on IP-based trust.

Q: What breaks when certificate SANs do not match cluster hostnames?

A: Peer validation fails, replication can become unstable, and operators often compensate with manual exceptions or relaxed trust settings. That creates a governance problem as much as a technical one, because the environment starts depending on informal fixes instead of verified identity.

Q: Who should own lifecycle management for database certificates?

A: The team that owns the database service should own the full certificate lifecycle, with IAM or security governance setting standards for issuance, rotation, and revocation. Without explicit ownership, certificates tend to outlive their intended purpose and become unmanaged trust assets.

Technical breakdown

Why Galera cluster identity depends on certificate trust

MariaDB Galera Cluster is a multi-primary replication topology, which means each node can both accept writes and replicate write-sets to peers. In that model, the cluster must know which node is which, and mTLS provides that identity layer. The lab uses a root CA to sign node certificates, then binds those certs to hostnames through SAN entries so the cluster can verify peers even when nodes move between networks. That replaces IP-based trust with cryptographic peer identity, which is more stable in distributed deployments.

Practical implication: Treat cluster node certificates as identity documents and manage them with the same discipline as any other non-human credential.

How passbolt authenticates to MariaDB with mTLS

The application does not simply open a TLS session and send a password. It presents a client certificate, the database validates that certificate against the trusted CA, and the user account is configured to require SSL. That means both the transport and the application identity are enforced at connection time. The useful detail here is that mTLS creates a second proof of legitimacy beyond the database password, which shrinks the value of a stolen credential if the certificate is missing or invalid.

Practical implication: Use certificate-bound application access for privileged database connections, especially where password reuse or secret exposure is a realistic concern.

Why hostname validation and SANs matter in clustered identity

The lab depends on hostnames such as galera1.local and matching SAN entries in certificates, because certificate validation fails when the name used to connect does not match the name in the cert. That sounds like a networking concern, but it is actually an identity control. Once names and certs drift apart, failover becomes fragile and administrators start compensating with exceptions, which is how trust boundaries erode. DNS, SANs, and certificate issuance therefore operate as one governance unit.

Practical implication: Standardise host naming and certificate issuance together so cluster mobility does not create ad hoc trust exceptions.

NHI Mgmt Group analysis

Identity-bound transport trust is now part of database governance, not a networking optional extra. This lab shows that clustered passbolt deployments cannot rely on IP addresses or perimeter rules alone once nodes span subnets, racks, or sites. mTLS turns the database tier into a certificate-governed identity plane, which aligns closely with OWASP NHI and Zero Trust thinking. Practitioners should treat cluster membership, peer authentication, and certificate issuance as one control domain.

Certificate lifecycle is the real control surface behind secure distributed databases. The lab works because the CA, server certificates, client certificate, and hostname mappings all stay in sync. That is the same governance pattern NHIs require elsewhere: issuance, validation, rotation, and revocation are inseparable. Where teams miss this, they end up securing the connection while leaving the identity artefacts unmanaged.

Maximum availability does not justify weak identity assumptions. Galera is attractive because it removes replica lag and supports rolling maintenance, but those benefits only hold if trust is anchored in certificates rather than static network rules. For identity programmes, that means high-availability design must be reviewed as part of NHI governance, not as a separate infrastructure decision. The practitioner takeaway is to align resilience engineering with credential governance.

Hostname-based certificate trust is the named concept this lab makes visible. The cluster depends on hostnames remaining stable enough for SAN validation, which means the security model breaks if identity and naming drift apart. That is not just a deployment issue. It is an assumption that the environment will preserve a clean mapping between machine identity and network name. Practitioners should regard that mapping as part of the trust architecture.

mTLS reduces the blast radius of database credentials, but only when application identity is certificate-bound. Passbolt’s database account requires SSL and the client certificate must chain to the trusted CA. That means password knowledge alone is insufficient, which is exactly the sort of control NHI programmes need when secrets are portable and long-lived. The lesson is to pair strong transport auth with strict credential governance.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That rotation gap is why teams should pair lifecycle control with NHI Lifecycle Management Guide before certificate sprawl turns into persistent trust debt.

What this signals

Hostname-bound certificate trust is becoming a governance pattern, not a deployment detail. As more workloads and databases stretch across sites, the enterprise cannot assume that access will remain safe simply because transport is encrypted. Teams that already manage NHIs as lifecycle assets are better positioned to extend that discipline to clustered database identities.

The strongest signal for practitioners is that mTLS only stays effective when certificate ownership, rotation, and revocation are operationalised. The difference between a secure cluster and a fragile one is often whether identity artefacts are treated as managed credentials or left as long-lived infrastructure assumptions.

Identity blast radius: the practical limit of how far one certificate or trust anchor can be abused before governance notices. In clustered databases, reducing that blast radius means tightening certificate scope, expiry, and validation rather than relying on network segmentation alone. For teams aligning to NIST Cybersecurity Framework 2.0, this sits squarely in protect and detect.

For practitioners

• Inventory database identities as NHIs Document every MariaDB node certificate, application client certificate, CA, and hostname binding as part of the identity estate. Include ownership, issuance date, expiry date, and revocation path so cluster trust can be governed, not just deployed.
• Bind cluster trust to SAN-consistent hostnames Standardise node names across DNS, certificate SANs, and Galera configuration so replication does not depend on IP addresses. This prevents brittle exceptions when nodes move between subnets or data centres.
• Require certificate-backed database access for privileged apps Use client certificates for application-to-database access and enforce REQUIRE SSL on sensitive accounts. That adds a second factor of trust beyond the password and makes stolen credentials less useful without the matching certificate.
• Rotate and revoke database certificates on a lifecycle schedule Set a renewal cadence for root CA, server certs, and client certs, and test revocation as part of change management. A distributed database that cannot tolerate certificate turnover is already carrying identity debt.
• Test failover under real certificate validation Run node replacement and rolling upgrade drills with certificate verification turned on, then confirm the cluster remains primary and passbolt health checks still pass. This exposes hidden assumptions before they become production outages.

Key takeaways

• mTLS turns clustered database access into an identity problem, not just an encryption problem.
• The main operational risk is not the cluster topology itself, but certificate lifecycle drift across nodes, apps, and DNS.
• Teams should govern database certificates like NHIs, with explicit ownership, rotation, and revocation controls.

Key terms

• Mutual TLS: Mutual TLS is a transport security pattern where both sides of a connection present certificates and verify each other. In identity terms, it turns a network session into an authenticated relationship, which is especially useful for workloads and databases that need stronger assurance than passwords alone.
• 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.
• Non-Human Identity: A non-human identity is any machine, workload, service account, token, or certificate that acts within an environment without being a person. These identities must be governed with ownership, lifecycle controls, and least privilege because they often outnumber human users and are easier to overlook.

What's in the full article

Passbolt's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step certificate generation commands for the Galera root CA, server certificates, and passbolt client certificates.
• Exact Docker and MariaDB configuration snippets for replication mTLS and client-side TLS.
• Verification commands for cluster health, TLS status, and passbolt connectivity checks.
• Troubleshooting notes for DNS mismatch, certificate SAN errors, and non-primary cluster states.

👉 Passbolt's full walkthrough covers certificate architecture, replication configuration, and validation checks.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.