Skip to content

Locked Tunnels (mTLS)

Lock your tunnels to devices you trust with mutual TLS. Issue per-device certificates, revoke them instantly, and block everyone else at the door.

A locked tunnel only accepts connections from devices you've personally approved. Every connection is verified with a cryptographic certificate, like a keycard for your service. No keycard, no entry. Lose a laptop? Revoke its keycard from the dashboard and it's locked out instantly.

This is mutual TLS (mTLS), the same technology banks and governments use to secure their internal systems. Localport makes it a single toggle.

When to use a locked tunnel#

Locked tunnels are for anything where "public URL plus a password" isn't enough:

  • Industrial IoT. Factory sensors and gateways that must only talk to your systems.
  • Regulated data. Healthcare, finance, or any workflow that needs auditable device identity.
  • Personal security. Your homelab, reachable only from devices you own.
  • Shared services. A dev API that only teammates' laptops can hit, even when the URL leaks.
  • Zero-trust setups. Replacing VPNs with identity-checked tunnels.

How it works, in plain English#

1. You create a trust anchor. Localport generates a private certificate authority for your team, a digital seal only you control. One authority covers every locked tunnel you own, so a caller needs one credential rather than one per tunnel.

2. You issue certificates. For each device, laptop, or service that should have access, you issue a certificate signed by that authority. The private key is generated in your browser and never sent to us, so there is nothing on our side to leak.

3. A valid certificate is necessary, not sufficient. Chaining to your authority gets a caller to the door. What it may actually reach is a separate decision — a grant you write per tunnel. A certificate with no grant reaches nothing. That is deliberate: issuing a credential and handing out access are two acts, and only the second one is a security decision.

4. You can revoke anytime. If a device is lost, compromised, or retired, revoke its certificate from the dashboard. Sessions it currently holds are closed immediately, not at its next reconnect.

All of this happens at the tunnel gateway, before any traffic reaches your service. Your app doesn't need a single line of code changed.

Turning it on#

1. Enable mTLS on a tunnel#

In the dashboard, open your tunnel's settings and toggle Require client certificate. If your team has no certificate authority yet, Localport generates one — for the team, not the tunnel — and its private key is encrypted at rest and never exposed.

Enabling it on a tunnel that is already serving traffic closes the sessions that were open, because those were admitted without a certificate.

Bringing your own authority instead is supported on the same plans: register the public chain and we never receive your signing key. See Bring your own CA below.

2. Issue a certificate for each device#

Click Issue certificate, give the device a name (e.g. alice-laptop, sensor-42), and pick how long it should be valid. The key pair is generated in your browser; only a certificate request is sent. You download the result once, and we cannot show it again because we never had it.

You get:

  • <name>.pem — one file holding the certificate, its chain and the key. This is what the CLI takes.
  • <name>-cert.pem and <name>-key.pem — the same material split, for nginx, curl and anything that wants them separately.
  • <name>.p12 — a PKCS#12 archive for Java keystores, Windows and appliances. You choose the password; it never leaves your browser either.

Then connect to the locked tunnel:

localport connect https://your-tunnel.localport.io --pem ./alice-laptop.pem -p 8080

That exposes the tunnel on 127.0.0.1:8080, so anything on your machine can reach it normally. With a PKCS#12 archive use --p12 ./alice-laptop.p12 and supply the password through --p12-pass-env.

For third-party TLS clients, point them at the split files.

A machine that should credential itself#

Downloading a file is right for a laptop or an appliance. A server or a CI job should not hold one, so it enrols instead and renews on its own:

# once, with an enrollment token from the dashboard
localport identity enroll lpk_...

# a person, on a laptop or a jump box
localport login

After that first minute there is no long-lived secret on the machine: the certificate is what obtains the next certificate, and it rotates itself.

3. Revoke when needed#

Go back to the dashboard and click Revoke on any certificate. The change is live immediately: sessions that certificate currently holds are closed, not left running until they end. If the device is offline, it fails the moment it tries.

Narrowing or removing a grant behaves the same way — the connections it covered are closed.

Certificates expire, and that's a feature

Short-lived certificates (30 to 90 days) mean a stolen credential doesn't stay useful forever. Rotate them routinely; the dashboard shows you what's expiring next.

Works with any service#

Locked tunnels are transparent to your application. Your web server, database, IoT broker, or custom TCP service stays exactly as it is. Localport handles certificate verification at the tunnel gateway.

Supported on:

  • HTTPS tunnels. Browsers and curl prompt for a client certificate; devices provide one automatically.
  • TCP tunnels. Every connection must present a valid certificate before a single byte reaches your service.

Two combinations are refused rather than silently weakened. TLS passthrough cannot be locked: verifying a client certificate means terminating TLS at the gateway, so passthrough and mTLS are mutually exclusive — use a tcp tunnel instead. Shared tunnels cannot be locked either: a shared tunnel fans one request to every client, so there is no single destination to grant access to.

Requests without a valid certificate are refused at the gateway. Plain HTTP requests are rejected with a clear error. Revoked or expired certificates are denied even after a successful network handshake.

Bring your own CA#

If you already run a PKI, register its public chain instead of using ours. We store the chain and nothing else — there is no field in the API for a private key, so your signing key never reaches our infrastructure. You sign your own certificates with your own tooling and we verify against your chain.

Two things are required when you register one, and both are load-bearing:

  • A trust domain (acme.corp). It is the namespace your CA owns. Everything it signs resolves inside it, which is what stops one authority presenting an identity that belongs to another.
  • A CRL URL. We cannot revoke a certificate your CA issued — only you can. We poll your published revocation list every 15 minutes and honour it. Without one, removing the whole authority would be the only lever you had.

If your certificates carry SPIFFE URI SANs we read the identity from there. If they carry plain common names — which most existing PKI does — tell us so at registration, and the identity becomes acme.corp/<common-name>. Grants name that form.

What you control#

  • Your certificate authority stays yours. For a registered CA we hold only the public chain. For one we generate, the private key is encrypted at rest with a key you can rotate, and it is used for nothing but signing certificates you asked for.
  • We never hold a client private key. Every issuance path is a certificate request: the key is generated where it will be used — your browser, your machine, your CI job — and only the request reaches us.
  • Granular revocation. Revoke a single device without touching any other.
  • Audit trail. Every certificate issuance, connection, and revocation is logged in the dashboard.
  • Full lifecycle. Issue, download, expire, renew, and revoke, all from one place.

Requirements#

  • Pro plan or higher for locked tunnels
  • One certificate per device or client (issued in seconds from the dashboard)

Use cases#

  • Homelab. Lock Home Assistant, Proxmox, or a private Jellyfin to your phone and laptop only.
  • IoT fleets. Identify every device individually and revoke the ones you retire.
  • Internal APIs. Expose a staging API to your team without exposing it to the internet.
  • Partner integrations. Give a specific customer a certificate they can't share.
  • Regulated workloads. Meet device-identity requirements without standing up a PKI.

Next steps#

Previous Shared Tunnels Next Custom Domains