mTLS and TLS 1.3

Every connection in the Mezusphere architecture is encrypted with TLS. Public-facing traffic uses TLS 1.2+ for broad browser and device compatibility. Internal connections between Mezusphere’s edge and Warpgates use TLS 1.3 with mutual authentication (mTLS), where both sides present certificates and verify each other’s identity.

Public TLS

When end users connect to a service published through Mezusphere, their traffic is encrypted with TLS at the edge. Mezusphere handles the complete certificate lifecycle:

• Automatic issuance: certificates are provisioned when a route is created
• Automatic renewal: certificates are rotated before expiration with no customer action required
• Strong defaults: TLS 1.2+ with modern cipher suites, supporting all major browsers and operating systems

You do not need to configure certificate managers, integrate with Let’s Encrypt, set up cert-manager in Kubernetes, or manage certificate stores. Public TLS is a platform primitive.

What this replaces

Mutual TLS (mTLS)

All connections between Warpgates and Mezusphere’s edge nodes use TLS 1.3 with mutual authentication. This means:

• Warpgate presents a certificate to the edge, proving its identity
• The edge presents a certificate back to Warpgate, proving it is a legitimate Mezusphere node
• Both sides verify the other’s certificate before any traffic flows

This mutual verification prevents man-in-the-middle attacks and ensures that Warpgates only send traffic to genuine Mezusphere edge nodes, and edge nodes only forward traffic to verified Warpgates.

How it works

1. Warpgate starts and authenticates to the control plane using its service account credential
2. Warpgate receives a short-lived TLS client certificate from Mezusphere’s internal certificate authority
3. Warpgate connects to edge nodes using this certificate for mutual authentication
4. The edge node verifies Warpgate’s certificate against the internal CA
5. Certificates are rotated automatically before expiration

You do not interact with the mTLS layer directly. There are no certificates to generate, no keystores to manage, and no CA bundles to distribute. The internal PKI handles everything.

Internal PKI

Mezusphere operates its own internal certificate authority (CA) that issues and manages certificates for all platform components. This PKI provides:

• Component identity: every Warpgate, edge node, and control plane service has a cryptographically verifiable identity
• Automatic issuance: certificates are issued during component registration without manual steps
• Short-lived certificates: certificates have limited lifetimes and are rotated automatically, reducing the impact of any single certificate compromise
• Unified trust model: all platform components participate in the same trust hierarchy

The internal PKI is what enables the “zero-trust” security properties of the platform: every connection is authenticated, every component is verified, and no traffic flows without cryptographic proof of identity.

Network requirements

Because Warpgate initiates all connections outward, your network requirements are minimal:

Warpgate works behind NAT, in private subnets, and in restricted network environments. The only requirement is outbound HTTPS connectivity on port 443.