A standard TLS connection encrypts traffic but does not, in most scenarios, prove who the client actually is. Passwords, API keys, IP allowlists and token-based controls add security layers, but they can be shared, leaked, copied or used in the wrong context. mTLS, by contrast, verifies that the client holds the private key, producing a stronger identity signal at the connection level.
In B2B APIs, payment flows, healthcare data sharing, IoT device traffic and management interface access, that difference is critical. Every partner, device or administrator arrives with its own certificate; certificate lifetime, CA chain, CN, fingerprint and verification outcome are all auditable. However, requiring every application to parse that information independently adds operational complexity.
In traditional mTLS deployments, CA bundle management, verify mode selection, error codes, certificate field extraction and forwarding that information to the application are fragmented concerns. One environment may require a mandatory certificate while another needs optional mode during a transition. Legacy CA chains, test certificates and partner migrations all demand a fine balance between strict validation and controlled tolerance.
The right approach is to manage mTLS as a service profile. Verify mode, CA file, CA error strategy, forwarding certificate fields to the backend, and AAM conditional access policies should all live in the same model.
TR7 TLS / mTLS Client-Cert Authentication delivers this model: it lifts the client certificate out of connection-level control and turns it into a usable identity object for backend services and access policies alike.
TR7 applies mTLS verification together with per-service verify mode, CA management, certificate field forwarding and AAM access policy in a single cohesive model.
With none, optional and required modes, each service can apply its own mTLS policy. Certificates can be made mandatory, kept optional during a transition, or disabled entirely for a given service.
Verification code, SHA1 fingerprint, CN and additional certificate fields can be mapped to HTTP headers. The backend reads identity information directly without parsing the certificate itself.
Certificate headers can be parsed into fields such as present, verified, verify, sha1 and cn. Even when verification fails, certificate data can be logged and passed to the decision engine in a controlled way.
CA validation errors can be rejected entirely, tolerated wholesale during a transition, or relaxed only for specific error codes. This lets staging, partner migration and production policies coexist in the same mTLS model.
TLS / mTLS Client-Cert Authentication verifies, parses, logs and shares the client certificate with the backend — all at the edge.
TR7 manages client certificate authentication behavior independently for each service. In none mode no certificate is requested. In optional mode a certificate is parsed when presented; if absent, the connection can continue. In required mode any connection that lacks a certificate is rejected. This structure provides strict security in production, flexibility in staging and staged rollout during migration. Different services on the same platform can enforce different mTLS requirements.
TR7 can validate client certificates against per-service CA files. Partner A's CA chain can be used on one service while Partner B's chain is applied to another. This separation lets different business partners or device groups be managed in isolation on the same ADC, without relying on a single global CA list. A distinct trust root is defined per service.
TR7 can deliver the client certificate verification status to the backend via headers such as x-ssl-verify. Successful verification, certificate absence or a specific verification failure is visible to the application. The backend can make decisions based on the mTLS status of the connection without dealing with the TLS stack or certificate parsing.
TR7 can extract the Common Name and SHA1 fingerprint from the client certificate and forward them as headers to the backend. The CN can serve as a partner, device, user or service identifier. The SHA1 fingerprint offers a practical key for allowlisting, auditing, matching or fast-revoke scenarios. Fingerprints are normalized so that different formatting styles do not produce different identity values.
caErrorStrategy allows different responses to CA validation failures. ignoreAll can tolerate all CA errors in temporary debug or migration scenarios; manualIgnoreList limits tolerance to specific validation error codes. In production this flexibility can be disabled to enforce zero tolerance. The model creates a controlled balance between strict security and real-world migration needs.
TR7 does not only request certificates from incoming clients — it can also present a client certificate when connecting to a backend service. The backend-facing connection can be configured with verify required, a CA file and an ADC client certificate. This enables independent TLS trust policies on both the client-to-TR7 and TR7-to-backend legs. Traffic can be inspected at the edge while the internal connection remains fully secured.
A client certificate is a strong identity signal, but it does not need to carry the full access decision on its own. TR7 can use certificate data as one input to AAM conditional access policies. Certificate, IP address, device posture, user group, time of day and MFA status can all be evaluated together. mTLS becomes one component of a broader zero-trust access decision.
A successful certificate verification does not automatically make a request safe — content and volume controls continue to apply. TR7 runs the mTLS identity layer alongside WAAP, DDoS and bot behavior analysis. mTLS establishes who the client is; WAAP evaluates what the request is doing; the DDoS layer assesses traffic volume. All three controls can operate together in front of the same service.
In optional mode, partners that present a certificate are processed with mTLS identity while clients whose certificate migration is not yet complete can fall through to an alternative authentication mechanism. This pattern lets large B2B migrations roll out safely without forcing all partners onto mTLS on the same day. The backend can decide between certificate-based and API key–based flows based on the presence of the x-ssl-verify header. Once migration is complete, the service can be moved to required mode.
For mTLS connections, fields such as certificate subject, issuer, validity window, verification result and fingerprint can be logged. In a SIEM, it becomes clear which partner accessed which service with which certificate. Events such as expired, self-signed or issuer failures can be analyzed separately. These records produce a strong audit trail for compliance, incident investigation and partner auditing.
mTLS operation is covered end to end: bind behavior, verify codes, header-based certificate detection, fingerprint normalization, CA file scoping and SNI/Host validation.
Verify none, optional or required behavior is set at the service entry point. In required mode a client connection that presents no certificate is rejected. In optional mode a certificate is parsed if present; if absent, the request can continue to an alternative policy flow.
The certificate verification outcome can be expressed as a numeric error code. Zero represents successful verification; other values indicate conditions such as issuer not found, certificate expired, certificate not yet valid or self-signed certificate. This value can be forwarded to the backend as a header.
If x-ssl-verify is empty or indicates that no certificate was used, the client is treated as having presented no certificate. A value of 0 means the certificate has been successfully verified. Any other value means certificate data may be present but verification failed — this can be handled separately in logs and policy decisions.
Fingerprint values can arrive with mixed case and colon-separated formatting. TR7 normalizes the value so that comparison and allowlist operations work consistently. The same certificate is not treated as a different identity because of a formatting difference.
Each service can use its own CA bundle, which allows trust roots to be isolated across partners, device groups and internal services. CA changes should be planned with service impact in mind and must be audited.
On services that use mTLS, SNI and Host validation can be enabled in addition to certificate verification. When certificate, SNI and Host are evaluated together, the request identity, target domain and HTTP routing intent are all validated in combination. This model helps reduce the risk of domain fronting–style abuse.
Each partner connects to the API with a unique client certificate. TR7 logs CN and SHA1 fingerprint values, forwards them to the backend, and makes per-partner audit and rate-limit decisions more straightforward.
Each device can connect to TR7 using a unique certificate loaded at the factory. The device serial number is carried in the CN field, and fingerprint allowlisting makes revocation and access restriction flows faster to manage.
Healthcare organizations can use mTLS when sharing data with provider systems to authenticate at the connection level. When a certificate expires or verification fails, access can be cut automatically without any manual intervention.
System administrators can connect to the TR7 management interface using a client certificate. When combined with MFA and device posture through AAM, a single laptop, a specific certificate and a verified administrator identity are all confirmed together.
Verify the client certificate at the edge, forward it to your backend, and combine it with AAM policy. Let's walk through a live setup on your own services.