Shipping Mutual TLS at the Edge

Tokens in HTTP headers are fine for most things. They're not fine for partner APIs that need to prove they are who they claim to be, device fleets where a leaked token could masquerade as a whole class of clients, or internal services where simply knowing a URL shouldn't be enough to get a response. For those, you want mutual TLS: the client presents a certificate, Ngris validates it against a CA you trust, and the connection only proceeds if it checks out. Today we're shipping first-class mTLS on every Ngris endpoint.

TL;DR

• Upload a client CA to your account's CA library.
• Pick a mode on any endpoint: disabled, optional, or required.
• Select which CAs to trust for that endpoint.
• Ngris enforces at the TLS handshake — rejected clients never reach your origin.
• Optional attribute-level filtering with the new Require Client Certificate traffic-policy rule.

When You'd Reach For This

• Partner integrations. Your partner presents a cert issued by your shared CA. No tokens to leak, no rotation routines to babysit.
• Device fleets. Each device carries its own signed cert provisioned at manufacture. Revoke one and only that one is locked out.
• Internal services behind public DNS. The URL being known isn't enough — callers must prove identity before any request is processed.
• Zero-trust perimeters. mTLS is the baseline trust check; service-to-service auth on top refines it.

The Three Modes

Every endpoint picks one:

Enforcement is at the TLS handshake, not the HTTP layer. When a connection is rejected, it never reaches your origin — no request is logged, no work is done by your server, no bandwidth is charged against your quota beyond the handshake itself.

Setting It Up

Three steps from zero:

1. Go to Dashboard → Secure Tunnels → mTLS and upload your CA certificate (PEM).
2. Open the endpoint, click the Mutual TLS tab, pick a mode.
3. Click Add Client CA, select the CA you just uploaded, apply, and save.

Changes apply to new connections immediately. Already-established connections are unaffected until they reconnect — which is the behavior you want when tightening security mid-stream (no existing client abruptly disconnects).

Attribute-Level Filtering

Endpoint-level trust answers "is this client signed by a CA we trust?". Sometimes you also want to answer "which client is this?". That's what the new Require Client Certificate traffic-policy rule is for. Three matchers, AND-ed together, each optional:

• Subject CN regex — e.g. ^production-service$ to accept exactly one identity.
• SAN regex — matches any DNS, email, or URI SAN on the cert. Useful for accepting any cert with an email from a specific corporate domain.
• Issuer CN regex — restrict to certs issued by a specific CA even when you trust several on the endpoint.

A common pattern: trust both an internal CA and a partner CA on the same endpoint (different business relationships, both legitimate), then use a rule matching on Issuer CN to route or restrict based on who issued each cert.

Try It

# Valid client cert — succeeds
curl --cert client.crt --key client.key https://myapp.ngris.io/

# No cert on a "required" endpoint — rejected at the handshake
curl https://myapp.ngris.io/
# → OpenSSL alert: sslv3 alert certificate required

Full walkthrough, including how to generate test CAs and client certs with openssl, lives in the Mutual TLS docs.

Questions about deploying mTLS for your use case? Reach us at hi@ngris.com.