feat(tls-cert-auth): validate SAN alongside CN (enables SPIFFE X.509-SVID auth without JWT-SVID)

[sinnwise]

Product: Machine Identities (Auth)

Deployment Type: Self-hosted

Feature

Extend TLS Certificate Auth (/api/v1/auth/tls-cert-auth/login) to optionally validate the client certificate's Subject Alternative Name (SAN) alongside the existing Common Name (CN) check.

Today the auth method only matches the cert's Subject CN against allowedCommonNames (see identity-tls-cert-auth-service.ts, where subjectDetails.CN is compared to the allow-list). There is no way to authorize based on a SAN entry.

Motivation: SPIFFE X.509 without JWT-SVID

In SPIFFE/SPIRE X.509 deployments where JWT-SVID is not enabled across the estate, workloads only have X.509-SVIDs. A SPIFFE X.509-SVID carries its identity in the SAN URI field (spiffe://trust-domain/path) and leaves the Subject CN empty — so the current CN-only check cannot authorize these workloads.

With SAN validation, an X.509 SPIFFE setup could:

1. Provide the SPIRE trust bundle / roots to Infisical (as the trusted CA for TLS Cert Auth).
2. Use TLS Cert Auth where the workload presents its X.509-SVID fetched from the SPIRE agent socket.
3. Authorize on the SAN URI (the SPIFFE ID), completing service identity validation without needing JWT-SVID.

Proposed behaviour

• Add an optional allowedSubjectAlternativeNames (or SAN-type-aware) allow-list to the TLS Cert Auth identity config.
• During login, match against the cert's SAN entries (URI / DNS / IP) in addition to / instead of CN.
• Keep CN validation as-is for backwards compatibility; SAN validation is additive and opt-in.

Additional context

• Existing CN check: backend/src/services/identity-tls-cert-auth/identity-tls-cert-auth-service.ts.
• Complements the existing SPIFFE JWT-SVID auth (feat(pki-118): add spiffe machine auth #5610) by covering X.509-only SPIRE estates.

[linear]

ENG-5247