Security teams face a deceptively simple question: "How can you confidently distinguish trusted connections from imposters?"
For decades, passwords have been the default answer. Familiar, widely supported, and easy to introduce, they’ve served well - but as systems become more distributed, automated, and network-exposed, password-based authentication is increasingly difficult to trust. Credentials travel through configuration files, deployment pipelines, logs, and other environments where accidental exposure is almost inevitable.
Modern authentication is less about what a client knows and more about whether it can be trusted. That shift is driving broader adoption of certificate-based models, where trust is cryptographically enforced. To support this approach, SingleStore now offers mutual TLS (mTLS) as a native authentication mechanism for database users.
Passwords, API keys, and tokens all rely on the same fragile assumption: possession of a secret implies legitimacy. In practice, this assumption weakens as systems scale.
Key challenges with shared secrets:
Secrets travel farther than intendedCredentials move across machines, environments, and services. Once leaked - through misconfiguration, logs, backups, or compromised hosts - they can be reused until revoked.
Operational burden grows quicklySecure storage, rotation, auditing, and distribution introduce complexity and potential errors across teams and environments.
Trust is implicit, not verifiedPasswords verify knowledge, not identity. Anyone holding the secret is trusted, regardless of how it was obtained.
These limitations are driving teams toward authentication models that reduce reliance on shared secrets and establish trust explicitly.
TLS is widely used to encrypt database connections. Traditionally, the server proves its identity, and the client authenticates later using a password.
Mutual TLS extends this model by authenticating both sides during the handshake:
The server presents a certificate to the client
The client presents a certificate to the server
Both are validated against trusted Certificate Authorities (CAs)
The connection proceeds only if mutual trust is established
Authentication is no longer a separate step - it is built into connection establishment.
mTLS shifts authentication from shared secrets to verifiable trust relationships. Key advantages:
Trust is tied to certificates, not credentialsAuthentication depends on possession of a private key associated with a trusted certificate.
Untrusted clients are rejected earlyConnections with missing or invalid certificates are refused during the TLS handshake.
Impersonation is significantly harderWithout access to valid certificate material, attackers cannot establish a trusted connection.
mTLS is especially valuable where identity assurance and trust boundaries matter:
Regulated industries requiring cryptographic verification
Systems exposing sensitive or high-impact operations
Distributed platforms with multiple internal integrations
Organizations aiming to reduce or eliminate shared credentials
While managing certificate lifecycles - issuing, rotating, and revoking - requires discipline, it provides clearer ownership, stronger guarantees, and a more durable foundation for secure access.
SingleStore’s mTLS support establishes trust directly within the database connection path, not as an external or application-level check.
Each SingleStore cluster is configured with a trusted Certificate Authority (CA) bundle, which can be uploaded by customers. This CA bundle defines the trust boundary for that specific cluster. When a client attempts to connect, SingleStore evaluates the client certificate as part of the TLS handshake and verifies that it:
Is cryptographically valid
Chains back to the cluster’s configured trusted CA
Has not expired or been rejected
(Optionally) matches an expected identity
Because this verification is performed by the cluster itself, arbitrary certificates are never accepted. A client cannot generate a self-signed certificate and connect — unless the certificate chains to a CA trusted by that SingleStore cluster, the TLS handshake fails and the connection is rejected before authentication completes.
SingleStore extends this trust model into database user configuration. Users can be explicitly configured to require certificate-based authentication using:
REQUIRE X509REQUIRE SUBJECTto bind access to a specific certificate identity (Subject DN)
This allows SingleStore to enforce not just certificate presence, but certificate intent. Even when a certificate is issued by a trusted CA, access is granted only if it satisfies the user’s configured requirements.
To adopt mTLS in SingleStore:
Configure the cluster with a trusted CA bundle
Issue client certificates from that CA to applications or users
Configure database users to require certificate authentication
Optionally enforce Subject DN matching for stronger identity guarantees
Start with high-risk or high-value workloads
Reference the SingleStore documentation (https://docs.singlestore.com/cloud/connect-to-singlestore/connect-with-mysql/connect-with-mysql-client/connect-to-singlestore-helios-using-tls-ssl/) for step-by-step guidelines on configuring users to support mTLS connections.
In this model, trust is established and enforced by SingleStore itself during connection establishment, on a per-user basis (using REQUIRE X509 or REQUIRE SUBJECT). Rather than relying on shared secrets passed to the database, access is granted only when a client presents a certificate that participates in the cluster’s configured trust chain.
As systems evolve, authentication models based solely on shared secrets are increasingly fragile. Mutual TLS offers a more durable alternative - granting access only when trust is cryptographically established.
With native mTLS support and optional certificate identity verification, SingleStore enables teams to adopt clearer, stronger authentication while maintaining flexibility. Whether applied selectively or broadly, mTLS provides a solid foundation for trustworthy database access.
