Validate a TLS peer, then decide what it may do

TL;DR: A certificate-authenticated TLS connection needs an accepted certification path, the intended service identity and proof of the corresponding signing capability. These checks establish the channel's peer under a trust policy. They do not establish that the peer's software is benign or that an authenticated caller may read a particular document.

Where you are. Module one, lesson two. You will produce a TLS validation and identity-propagation review for EvidenceDesk.

The failure report

A test client connects successfully to the document API using a certificate issued for a different service. Its developer says the certificate is signed by a trusted CA, so validation succeeded. Diagnose the missing check before reading further.

A trusted chain and the intended peer name are different claims. The client must derive its reference identity from trusted configuration or the requested service, not replace it with a name supplied by an untrusted endpoint. In this case, accepting a certificate for an unrelated service is a defect even if every signature in the chain is valid.

RFC 9525 describes service-identity verification, including the appropriate presented identifiers and matching rules. Use the platform's maintained verifier. Do not build your own wildcard or hostname matching from string suffix tests.

What the checks actually establish

A certificate path links the leaf certificate through permitted issuers to a trust anchor the client accepts. Validation includes signatures, validity periods, intended use and applicable constraints. Trust stores and additional policy differ among clients. The path a server sends is input to path construction; a self-signed root sent by that server does not make itself trusted.

In the certificate-authenticated TLS 1.3 handshake considered here, the peer demonstrates the certificate's signing capability over the handshake. The certificate itself is public. Copying it without usable signing authority does not supply that proof. Conversely, a compromised service authorized to use a protected signing key may still operate as that identity without exporting the key.

RFC 5280 defines certificate-path validation; RFC 8446 defines the TLS 1.3 handshake. Resumed sessions can use previously established state rather than a fresh certificate exchange, so inspect resumption and lifetime policy when your requirement concerns changed credentials or revoked trust.

A certificate says nothing by itself about the correctness of the document parser, the tenant check or the destination of an AI-generated reply. An attacker-operated service can have a valid certificate for its own name. Correctly identifying that service does not make it an approved recipient of customer documents.

Keep a failure matrix

Add revocation and distrust behavior to the matrix for the clients you operate. Determine what happens when relevant status information is stale or unavailable. Do not assume all libraries consult the same sources or fail in the same way. Test the actual verifier configuration with controlled fixtures.

Transparency and issuance policy help in different ways

Certificate Transparency provides auditable issuance evidence and can support monitoring for unexpected certificates. It does not establish that the named site is honest or automatically prevent a misissued certificate from being used. Client CT requirements vary with trust program and certificate type; do not claim every certificate used by every TLS client must be publicly logged.

CAA records express which certificate authorities a domain authorizes to issue, under the issuance rules that process those records. They are not a replacement for a client's chain and name checks. RFC 9162 describes a CT protocol, and RFC 8659 describes CAA processing. Record who monitors your service's issuance and who acts on an unexpected result.

Pinning needs a concrete operating plan

Pinning adds a restriction on acceptable certificates or keys. It is useful only if its threat model and operational cost justify that extra constraint. For a client fleet you control, identify what is pinned, which ordinary validation checks still apply, how rotation works and how old clients recover when the current pin becomes unusable.

Pinning an entire leaf certificate differs from pinning its public key. A renewed certificate can retain the same key, so renewal does not necessarily break a public-key pin. Key rotation does change that match. Backup pins, deployment overlap and an update path need testing; an expiry or fail-open fallback changes the protection and belongs in the design decision.

Follow the OWASP pinning guidance when evaluating whether the application and deployment control make pinning appropriate. Do not introduce it as a universal TLS upgrade or confuse an application pin with a policy all browsers enforce.

Mutual TLS still ends somewhere

Suppose the edge authenticates an internal worker with a client certificate. The receiving service maps that verified identity to permitted operations and resources. It must reject a recognized worker that asks for another tenant's document outside its assigned task.

If a proxy terminates mutual TLS, the backend does not receive the original cryptographic proof merely because a header names the client. The proxy must remove caller-supplied identity headers, create an authenticated identity assertion and send it over a trusted protected hop. The backend must accept that assertion only from authorized proxies and still enforce resource policy. Otherwise, an ordinary request field can masquerade as an authenticated identity.

Test the identity decision without inventing a TLS verifier

The name you intended to contact must come from trusted application configuration or the user's authenticated navigation context, not from whichever certificate arrived. RFC 9525 separates that reference identity from the identities presented by the service. Certificate parsing, path building and name matching belong in the platform verifier. The application should set the expected identity and keep verification enabled.

Use the synthetic acceptance records below to test what the application does with verifier outcomes. The certificate fixtures are labels, not certificates. A trusted chain for the wrong service still fails. A correct service name on an expired certificate also fails. The sample deliberately cannot validate a real certificate or establish a secure connection.

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Evidence:
    chain_ok: bool
    name_ok: bool
    time_ok: bool
    usage_ok: bool
    handshake_ok: bool
    expected_peer: str

def admit(evidence):
    checks = (evidence.chain_ok, evidence.name_ok, evidence.time_ok,
              evidence.usage_ok, evidence.handshake_ok)
    return evidence.expected_peer == "api.internal.example" and all(checks)

valid = Evidence(True, True, True, True, True, "api.internal.example")
print(admit(valid))  # => True
print(admit(replace(valid, name_ok=False)))  # => False
print(admit(replace(valid, time_ok=False)))  # => False
print(admit(replace(valid, expected_peer="metrics.internal.example")))  # => False

In a real test, obtain those outcomes from the selected TLS implementation using approved local fixtures. Do not take a request field named chain_ok as evidence. Keep the expected identity, trust-store version and connection identifier with the result so that a successful check for one peer cannot authorize an unrelated connection.

Rehearse renewal and identity forwarding

Write separate tests for renewal under the same permitted identity and for an unexpected service identity. If you use pinning, specify whether the pin identifies a certificate, public key or issuing authority. Their renewal behavior differs. A replacement certificate can retain a public key, while a planned key rotation changes it. An emergency override that accepts every certificate is not a recovery plan.

For a proxy deployment, remove any client-supplied identity assertion before creating the trusted one. Authenticate the proxy-to-API channel, constrain which proxies can assert which identities, and ensure that a direct API route cannot bypass this policy. Log the authenticated proxy and asserted workload as distinct fields. If either binding is absent, preserve the distinction as unknown rather than silently treating the assertion as a verified client certificate.

Do this before moving on

Complete the failure matrix for two connections: customer to edge and worker to API. Use configuration review or local synthetic certificate fixtures for a system you are authorized to test. Include a wrong name, untrusted anchor, expired credential, an unauthorized document ID and a caller-supplied proxy identity header.

Then plan one certificate/key rotation. State which clients keep working, which must update and how you would detect a failure before changing production. Your deliverable is the expected behavior and evidence needed, not an instruction to bypass validation when a test fails.

Add an evidence row with a valid name and chain but a failed handshake proof. Explain why replaying a certificate file alone cannot establish possession of the associated private key.

Go deeper

• How TLS works explains the handshake messages behind the channel proof.
• PKI and certificate chains expands path constraints, trust anchors and revocation decisions.
• Certificate issuance end to end follows the issuer side of the credential lifecycle.
• Authentication vs authorization connects a verified service identity to the separate resource decision.

Key takeaways

• Trust path, intended identity and handshake proof are separate checks.
• An authenticated channel still needs application and object authorization.
• Pinning, CT and CAA address different risks and have different operating requirements.
• A terminating proxy must preserve verified identity through an authenticated, constrained path.