mTLS (1.25): Community or Enterprise feature, and how to revoke a client certificate?

[e-minguez]

Thanks for shipping mTLS for public resources in 1.25 — it's been a long-awaited one (#46). I'm planning to use it in front of Home Assistant for the companion app, and two things aren't clear from the docs or the release post:

1. Is mTLS a Community or Enterprise feature?

The docs and release notes don't say it's Enterprise-only, but:

• The resource mTLS routers added in 1.25.0-rc.0 #3926 live under server/private/routers/resource/ (createResourceMtlsCertificate.ts, deleteResourceMtlsCertificate.ts, listResourceMtlsCertificates.ts).
• disable_enterprise_features flag hides mTLS authentication option for public resources #3961 reports that setting disable_enterprise_features on CE hides the mTLS option in the UI, while already-configured mTLS keeps working.

So which one is intended? Is mTLS part of CE, and #3961 a bug? Or is it an Enterprise feature that's free under the EE license terms, in which case the docs could say so?

2. How should a client certificate be revoked?

Pangolin trusts whole CAs, up to 20 per resource. I couldn't find any way to stop trusting a single client certificate signed by a trusted CA:

• The docs say nothing about CRLs, OCSP or blocking a certificate by serial number. The only related line is "Removing the last CA turns mTLS off automatically."
• server/lib/mtlsCertificate.ts only parses and stores CA certificates. I found nothing CRL-related in the code.
• Traefik's clientAuth (caFiles / clientAuthType) has no CRL support either, so I assume this can't just be passed through.

As it stands, a lost or compromised device means creating a new CA, replacing it on every resource and reissuing every other client's certificate. Could you clarify:

• Is that the intended way to revoke today?
• Is revocation on the roadmap, for example a per-resource CRL upload, or a deny-list by serial number or fingerprint checked at the Badger stage using the data already in X-Forwarded-Tls-Client-Cert-Info?
• Either way, could the docs mention the current behaviour?

If revocation is wanted, I'm happy to open a separate feature request.

[MohammadThabetHassan]

I can't speak for the CE/EE intent, that needs a maintainer, but on revocation I can say what the code does today. applyMtlsConfig in server/lib/traefik/mtls.ts writes the uploaded PEMs straight into a Traefik TLS option as clientAuth.caFiles with clientAuthType: RequireAndVerifyClientCert, so the check is Go's crypto/tls verifying the client chain against that pool, and nothing on that path looks at CRLs or OCSP. So yes, right now the only way to stop trusting a certificate is to remove the certificate it chains to.

You don't need to replace your CA and reissue every device to get per-device revocation, though. Go treats every certificate in the client CA pool as a trust anchor and doesn't require it to be a self-signed root, and parseCaCertificates in server/lib/mtlsCertificate.ts only parses the PEM (no root or self-signed check). So you can keep your root offline, give each device (or group of devices) its own intermediate CA, sign that device's client cert with it, and upload the intermediates to the resource instead of the root:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout phone-ca.key -out phone-ca.csr -subj "/CN=HA phone CA"
openssl x509 -req -in phone-ca.csr -CA root.crt -CAkey root.key -CAcreateserial -days 825 \
  -out phone-ca.crt \
  -extfile <(printf "basicConstraints=critical,CA:true,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign")
# then sign the phone's client cert (extendedKeyUsage=clientAuth) with phone-ca.crt / phone-ca.key

Losing the phone then means deleting HA phone CA from the resource while every other device keeps working. MAX_MTLS_CERTIFICATES_PER_RESOURCE is 20, so that's up to 20 devices or groups per resource, which is plenty for a Home Assistant setup.

Two things to keep in mind:

• Client auth is only checked during the TLS handshake, so removing a CA blocks new connections, but a keep-alive or HTTP/2 connection the lost device already has open stays up until it closes. Restarting Traefik on the node closes them if you need it immediate.
• If the resource uses a resource policy with mTLS turned on, getMtlsCaCertificatesByResource takes the policy's CA list instead of the resource's, so remove it from the policy.

For proper revocation, your Badger idea fits data Pangolin already forwards: the passTLSClientCert middleware it adds sends serialNumber plus issuer CN/O in X-Forwarded-Tls-Client-Cert-Info, so a serial deny-list checked there would work without Traefik having CRL support.

[oschwartz10612]

#3961 is a bug and is going to be fixed. The routes are not in the private directory on the main branch if you check ;} Remove certs so they are no longer included. You can have more than one cert. We can consider improving how you revoke certs in the future.