Mutual TLS authenticates peers within an identity scope

In a fresh, non-resumed certificate-authenticated handshake, a server can request a client certificate, verify a presented certificate, and require a valid certificate as a condition of continuing. Those are distinct configuration choices. In a library such as OpenSSL, verification modes affect whether an absent required client certificate aborts that handshake. Disable session resumption when testing both an untrusted certificate and no certificate in this fresh-handshake fixture. TLS 1.3 PSK resumption can omit Certificate and CertificateVerify while retaining policy-bound authenticated context; separately test the resumed identity and current authorization policy. Seeing CertificateRequest alone does not prove enforced rejection.

Once verification succeeds, map the certificate to a workload principal using documented identifiers and issuer context. A DNS or URI identifier is meaningful only under a policy that defines its issuance and expected scope. Workload identity systems can use trust domains to distinguish identically named services managed by different authorities. Avoid equating a free-form subject string with an authorization role. The identifier's provenance and the key-possession proof matter together; a copied certificate without its corresponding private key does not complete the same authentication.

A frontend service may authenticate to a backend with its own workload certificate while handling requests from many users. The backend still needs trustworthy user and tenant context if access depends on them. Permission for the frontend to call the backend does not mean every user behind it may access every object. Decide which service is responsible for each authorization decision and how delegated context is validated. Otherwise a broadly trusted workload can become a confused deputy for an unprivileged requester.

A TLS-terminating proxy changes the peer visible to the next hop. Passing an arbitrary client-identity header through unchanged can let a caller claim another principal unless the trusted boundary strips, replaces, and protects that assertion. If the proxy uses its own certificate to the backend, the backend authenticates the proxy on that leg. Original-client identity requires an additional trustworthy propagation design; it is not automatically preserved as cryptographic peer identity through every intermediary. Test a direct bypass path as well as the intended proxy path.

Create a small policy table that states allowed calls, forbidden actions, and cross-tenant denials. Exercise each with valid workload authentication so an earlier certificate failure does not hide a missing authorization rule. Then independently test certificate absence, unknown issuers, expired credentials, and unexpected workload identifiers with resumption disabled for those fresh certificate-authentication fixtures. Logging should distinguish TLS identity failure from application permission denial without exposing private keys or reusable credentials. This makes a denial explainable and prevents a generic connection error from being counted as proof of the wrong control.

Use the probability lab only to examine random-test coverage of a synthetic policy population. Reset, set both p=0.1 for an independently selected case exposing a missing denial and n=20, predict zero detections, then Play or Step. The exact binomial distribution neither authenticates a certificate nor evaluates a policy. Shared policy templates and repeated similar cases can correlate failures, so a clean random run cannot replace the explicit allowed and denied principal/action/resource cases just described.