mirror of
https://github.com/fosrl/docs-v2.git
synced 2026-10-21 20:19:11 +02:00
add public resource mtls
This commit is contained in:
@@ -53,6 +53,10 @@ These authentication methods do not provide user identity information:
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Client Certificate (mTLS)
|
||||
|
||||
When [mTLS](/manage/access-control/mtls) is enabled on a public resource, verified client certificate details are forwarded in `X-Forwarded-Tls-Client-Cert-Info` (subject, issuer, serial number, validity, and SANs). That header is independent of the `Remote-*` identity headers above and is available whenever the TLS handshake succeeds with a trusted client certificate.
|
||||
|
||||
## AI Gateway
|
||||
|
||||
[AI Gateway](/manage/ai/overview) resources forward the same `Remote-User`, `Remote-Email`, `Remote-Name`, and `Remote-Role` headers to the upstream model API when Pangolin knows the user:
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Client Certificate (mTLS)"
|
||||
description: "Require a trusted client certificate before any other public resource authentication"
|
||||
---
|
||||
|
||||
Client certificate (mTLS) authentication requires browsers and API clients to present a certificate signed by a CA you trust. It is configured on public resources alongside PIN, passcode, email OTP, and other auth methods, but it is enforced earlier: during the TLS handshake, before those methods run.
|
||||
|
||||
Pangolin does not issue or host client certificates. You bring your own CA and distribute client certificates to the devices or clients that should connect.
|
||||
|
||||
<Info>
|
||||
This is separate from [Pangolin Site mTLS](/manage/sites/configure-site#mtls-authentication), which authenticates a Newt site to the control plane.
|
||||
</Info>
|
||||
|
||||
## Requirements
|
||||
|
||||
- The resource must be an **HTTPS** public resource with **SSL** enabled
|
||||
- At least one trusted **CA public certificate** must be uploaded before you can require client certificates
|
||||
|
||||
## Configure mTLS
|
||||
|
||||
On the resource (or a [resource policy](/manage/resources/public/resource-policies)):
|
||||
|
||||
1. Open **Authentication** and enable **Client Certificate (mTLS)** under Other Methods.
|
||||
2. Upload one or more trusted CA certificates (PEM, `.pem`, `.crt`, or `.cer`). Bundles are supported. Upload public CA certificates only—never a private key.
|
||||
|
||||
You can add up to 20 trusted CA certificates. Removing the last CA turns mTLS off automatically.
|
||||
|
||||
## How It Behaves
|
||||
|
||||
- When mTLS is required, clients without a valid certificate fail the TLS handshake. Browsers show a connection error, not the Pangolin login page.
|
||||
- There is no optional mode: if enabled, a valid client certificate is always required.
|
||||
- After the handshake succeeds, other configured auth methods still apply (SSO, PIN, passcode, email OTP, header auth, shareable links, and access rules).
|
||||
- Access rules cannot skip mTLS. Bypass-auth rules only skip later authentication stages.
|
||||
|
||||
## Backend Certificate Details
|
||||
|
||||
When a client connects successfully, Pangolin forwards verified certificate details to your backend in the `X-Forwarded-Tls-Client-Cert-Info` header (subject, issuer, serial number, validity, and SANs). This is separate from the identity headers documented in [Forwarded Headers](/manage/access-control/forwarded-headers).
|
||||
@@ -41,6 +41,14 @@ You can also pass access tokens via query params or headers to resources to enab
|
||||
|
||||
First whitelist specific emails or wildcards, like `*@.example.com`. When users visit the resource, they will be prompted to enter an email. If the email they enter is on the whitelist, a temporary one time passcode will be sent to their email. Users can then enter this OTP to gain access to the resource.
|
||||
|
||||
## Client Certificate (mTLS)
|
||||
|
||||
Require clients to present a certificate signed by a CA you trust. mTLS is configured alongside the other methods above, but it runs first—during the TLS handshake, before PIN, SSO, email OTP, or any other auth. Clients without a valid certificate never reach the login page; the connection fails instead.
|
||||
|
||||
The resource must use HTTP with SSL enabled. Upload trusted CA public certificates, then enable **Require client certificate**. Pangolin does not issue client certificates for you.
|
||||
|
||||
[Read more about Client Certificate (mTLS)](/manage/access-control/mtls).
|
||||
|
||||
## Rules to Access or Deny
|
||||
|
||||
Define ranked rules to either block or allow access from specific IPs, geolocation, URL paths, and more.
|
||||
|
||||
@@ -40,6 +40,7 @@ A resource policy holds the same settings you configure on a public resource's a
|
||||
- PIN and passcode
|
||||
- User and role assignments
|
||||
- Shareable links, access tokens, and email OTP
|
||||
- Client certificate (mTLS)
|
||||
|
||||
**Access rules**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user