TLS 1.3, mTLS and PKI security audit guide

A TLS 1.3, mutual TLS and PKI security audit does not end when a browser displays a padlock. The assessment must verify protocol versions, negotiated parameters, service-identity validation, certification paths, key purpose, failure behaviour, 0-RTT, rotation and the trust boundaries on both sides of the connection. A successful handshake can still protect a connection to the wrong host, admit an unintended client or depend on a key that the organisation cannot revoke quickly.

This technical methodology applies to public web applications, APIs, service-to-service traffic and private PKI. It connects RFC requirements to implementation tests so that the final report explains exploitable conditions and operational failure modes rather than presenting only a cipher list.

TLS, mTLS and PKI solve different problems

TLS protects channel confidentiality and integrity and normally authenticates the server with a certificate. Mutual TLS adds a client certificate so that both endpoints present a cryptographic identity. PKI is the system that issues, distributes, renews and revokes certificates and defines trusted authorities, profiles and policies.

These layers are not interchangeable. TLS does not repair excessive application permissions. A client certificate proves possession of a private key, but does not automatically determine which tenant records the holder may read. A private root CA does not create security if its key is copied across ordinary servers. Assess protocol security, identity and authorisation as separate controls.

Layer	Evidence required	Example failure
TLS	the channel negotiates an approved version and parameters	fallback to a deprecated protocol
Server identity	the expected service name matches the certificate	a client ignores SAN mismatch
Mutual TLS	the client has an appropriate trusted certificate and key	every certificate from a corporate CA is admitted
PKI	paths, profiles, rotation and revocation operate correctly	an expired intermediate stops every service
Authorisation	the certificate identity receives minimum access	one shared certificate opens multiple workloads

Protocol baseline: TLS 1.2 and TLS 1.3

RFC 9325 recommends supporting and preferring TLS 1.3 and disabling deprecated versions. TLS 1.2 may remain in a compatibility baseline where required, but it needs a modern configuration. TLS 1.0 and TLS 1.1 should not survive as an undocumented fallback. NIST SP 800-52 Revision 2 provides another useful profile, particularly for US government systems and organisations adopting comparable requirements.

TLS 1.3 simplifies cipher suites and removes many historical constructions, but it does not make every deployment safe. Enumerate supported versions on every public and internal listener, inspect load-balancer termination, verify the proxy-to-backend connection and test the actual client library. The front end may offer TLS 1.3 while an internal hop is unencrypted or accepts any backend certificate.

Do not base the conclusion on one scanner. Combine positive and negative handshakes, infrastructure configuration and runtime observation. A CDN, WAF, ingress controller and service mesh may expose different profiles according to SNI, ALPN, address or region. An IPv6 listener can also differ from the IPv4 path.

Cryptographic negotiation and key-exchange groups

In TLS 1.3, a cipher suite identifies the AEAD construction and hash, while key-exchange groups are negotiated separately. RFC 9325 discusses X25519 and secp256r1 as widely deployed choices. Determine which groups are offered, whether the negotiated mode provides forward secrecy and whether the organisation’s policy creates compatibility gaps for required clients.

Also establish:

whether TLS 1.2 accepts legacy algorithms or non-forward-secret suites;
whether certificate signature algorithms work for the supported client population;
whether a middlebox weakens the profile on a second TLS hop;
whether private keys are shared more broadly than the architecture requires;
whether protocol settings are managed through code or a controlled baseline;
whether exceptions have owners, business justification and expiry dates.

A top grade from a public TLS scanner is useful evidence, but it cannot inspect a mobile application with verification disabled, a private API or a custom client that trusts every certificate. Treat transport testing as part of web application penetration testing and API penetration testing, not as an isolated dashboard.

Service identity: validate SAN, not Common Name

RFC 9525 defines current service-identity verification. A client compares the expected identity with the appropriate identifier in the Subject Alternative Name extension. Common Name is no longer a valid fallback for identifying a host. The assessment should prove which name the client expects and how it behaves when no identifier matches.

Negative tests include a certificate that is:

valid for another DNS name;
issued with a wildcard at a different or broader label level;
cryptographically valid but chained to an untrusted CA;
expired or not yet valid;
presented without a required intermediate;
populated with the desired text only in Common Name, without the correct SAN.

Each case should terminate the connection. Logging a warning and continuing is a vulnerability. This failure is especially common in API clients, webhook receivers, update agents and integration code where verification was temporarily disabled to make a test environment work.

IP addresses, DNS names and URIs are distinct identifier types. A dNSName SAN should not silently validate a connection made to a literal IP address. Service-mesh or SPIFFE deployments may use URI identifiers; the policy must then select the intended SAN type rather than accepting any SAN value signed by the CA.

Hostname verification also needs an authoritative source of the expected name. If the application derives it from attacker-controlled input, correct library validation may compare against the wrong reference identity. Review redirects, proxy configuration, connection pooling and DNS resolution as part of that data flow.

Certification-path construction and validation

RFC 5280 defines the X.509 certificate and CRL profile and a certification-path validation algorithm. A relying party must build a path to a configured trust anchor and check signatures, validity periods, CA constraints, name constraints, policy constraints and key purpose. Finding a certificate with a similar issuer string is not sufficient.

Frequent private-PKI failures include:

using an online root CA for everyday issuance;
sharing one intermediate across servers, clients, devices and code signing;
missing or incorrect CA Basic Constraints;
overly broad Key Usage and Extended Key Usage values;
no name constraints for an external or higher-risk subordinate CA;
distributing roots through uncontrolled scripts or base images;
lacking a certificate inventory and accountable service owners;
assuming that every platform builds the same alternative certification path.

Keep the root key strongly protected and use it rarely. Separate intermediate authorities by purpose and risk. Compromise of a client-certificate issuance service should not permit the attacker to issue a trusted certificate for the organisation’s public web estate.

Test full server chains as presented on the wire. Servers should normally send the leaf and required intermediates, but not depend on a client having fetched or cached an intermediate previously. Validate behaviour across the actual Java, .NET, mobile, browser, appliance and embedded clients in scope because path-building differences can turn a nominally correct deployment into an outage.

Key Usage and Extended Key Usage

Key Usage and Extended Key Usage constrain how a certificate may be used. A server certificate should be appropriate for server authentication, and a client certificate for client authentication. If the relying party ignores EKU, or the CA issues multipurpose credentials, boundaries between identities become unclear.

Build a matrix containing certificate profile, allowed SAN types, issuer, EKU, validity, renewal mechanism, private-key store and trust scope. Then perform cross-purpose tests: will a certificate issued for a different system or role be accepted? A signature from the corporate CA must not be the only admission criterion.

Review template administration as carefully as runtime validation. An operator who can add arbitrary SANs, request a different EKU or choose an unintended template may bypass otherwise correct mTLS controls. Log issuance requests, approvals and profile changes, and separate the right to request from the right to alter CA policy.

Mutual TLS: authentication is not authorisation

Mutual TLS is an effective identity mechanism for workloads and B2B clients, but it is easy to turn it into one enormous trust zone. The server must validate the path, validity, purpose and expected identity. Only then should the application map that identity to permissions.

Avoid a shared certificate for an entire cluster, team or device fleet. Theft of one key then weakens attribution and forces replacement everywhere. Prefer an identity per workload or instance, short certificate lifetimes and automated renewal. Generate and retain the private key in the protected workload or key store rather than copying it into a container image.

RFC 8705 defines OAuth 2.0 mutual-TLS client authentication and certificate-bound access tokens. This is a separate control from merely enabling mTLS on a load balancer. If a proxy terminates TLS, the backend needs an integrity-protected representation of the verified identity. Never trust a client-supplied header resembling X-Client-Cert unless the edge removes any inbound copy and injects its own value over an authenticated backend channel.

Test authorisation with two valid certificates for different identities. Confirm tenant isolation, operation-level permissions and audit attribution. A configuration that rejects invalid certificates but grants every valid client administrator access is not a secure mTLS deployment.

TLS 1.3 early data and replay risk

TLS 1.3 can carry early data, commonly called 0-RTT, during session resumption. It reduces latency, but 0-RTT data does not receive the protocol’s full replay protection. RFC 8446 requires applications to account for that property. State-changing operations such as payments, account creation, password reset, message sending or deployment should not be processed blindly as early data.

Determine whether early data is enabled at the CDN, proxy and origin, which methods and routes may receive it, and how replay is handled across a distributed edge. The straightforward safe choice for many business applications is to disable 0-RTT when there is no documented latency requirement and no robust idempotency design.

An HTTP method labelled safe is not enough if the application implements side effects behind it. Validate application behaviour, not only the verb. Conversely, an idempotency key needs a scope and retention model that remains effective across regions and retries.

Session resumption, ticket keys and rotation

Session resumption improves performance, but keys protecting session tickets become sensitive assets. RFC 9325 recommends secure generation, storage and regular rotation. A cluster must balance availability across nodes against the blast radius created by sharing one ticket key.

Verify that rotation does not invalidate all sessions at once and cause an avoidable outage, while also ensuring that a compromised ticket key does not remain usable indefinitely. Ticket keys do not belong in logs, source repositories or plaintext container configuration. Treat them with the same ownership, access review and incident response applied to other service keys.

Record how resumption interacts with certificate replacement and client authentication. A certificate or access decision changed after the original connection should not remain effectively trusted longer than policy permits because an old session can be resumed.

Revocation: CRLs, OCSP and operational reality

A certificate may need to be revoked before expiry because its key was lost, it was mis-issued or its owner changed. CRLs and OCSP are PKI mechanisms, but enforcement depends on the relying client. RFC 9325 discusses status checking and OCSP stapling limitations. Test not just whether a URL exists, but how the real client behaves for a revoked status, timeout and unavailable responder.

In private mTLS, short lifetimes often reduce exposure more reliably than a revocation mechanism clients do not enforce, but they do not eliminate incident response. The organisation must be able to deny an identity, remove trust, withdraw permissions and replace the key. Fail-open preserves availability but may admit a compromised certificate; fail-closed strengthens enforcement but can let a responder outage stop the service. Document the decision according to risk and design for responder resilience.

OCSP stapling can improve privacy and availability by letting the server provide a signed status response, but it still needs correct refresh and monitoring. Do not interpret the mere presence of a stapled response as proof that every failure state is handled securely.

Certificate lifecycle and automated renewal

Without automation, certificates tend to expire during the least convenient maintenance window. ACME, defined by RFC 8555, standardises automated certificate issuance and renewal. A private-PKI equivalent should authenticate the workload, restrict the requested profile and record issuance events.

Monitor and alert on:

certificates approaching expiry;
failed renewal and increasing retry counts;
issuance outside an approved profile;
changes in issuer, SAN, EKU or algorithm;
sudden issuance volume for one identity;
use after workload decommissioning;
private keys found in repositories, images or backups;
unexplained changes in the trust store.

The inventory should connect serial number, fingerprint, issuer, subject/SAN, owner, service, environment, key store and renewal path. A spreadsheet with no runtime discovery quickly becomes unreliable. Use active inventory and certificate-transparency monitoring for public certificates where appropriate, while recognising that private certificates will not appear there.

A technical TLS and PKI audit methodology

1. Define the complete surface

Collect domains, addresses, ports, SNI values, private endpoints, ingress controllers, load balancers, service meshes, webhooks, brokers and mobile clients. Include outbound TLS. SSRF or manipulated DNS can direct a client toward a different server, making strict identity validation critical.

2. Examine real handshakes

Verify versions, ALPN, cipher suites, groups, signatures, the presented chain, certificate order, stapling and resumption. Repeat across each SNI and architectural hop. Rate-limit intrusive checks and agree production testing windows.

3. Exercise client failure paths

In a controlled environment, present the wrong hostname, an untrusted issuer, a missing intermediate, an inappropriate EKU and an expired certificate. The client must fail closed without a hidden “continue anyway” path.

4. Test mTLS identity and authorisation

Use an intended certificate, a revoked certificate, another profile and another valid identity. Check account mapping, tenant isolation and decision logging. Confirm that the edge cannot be bypassed with a user-supplied identity header.

5. Review PKI operations

Assess CA key protection, templates, administrator roles, approvals, HSM or KMS use, backups, disaster recovery, intermediate rotation and the compromise procedure. Rehearse renewal and withdrawal in a test environment.

6. Express application impact

Do not stop at “the server accepts TLS 1.0”. Determine which protected endpoint is reachable, what data uses the channel, whether exploitation requires a man-in-the-middle position and whether a supported client negotiates the weak path. Prioritise findings with the vulnerability-management process and Secure by Design principles.

Evidence checklist for the final report

a list of endpoints and TLS termination layers;
negotiated handshake parameters without private keys or user data;
the complete path and SAN, EKU and CA-constraint results;
negative-certificate tests and observed client behaviour;
an mTLS identity-to-permission matrix;
evidence that renewal, rotation and withdrawal work;
an owner and remediation deadline for each exception;
a regression check suitable for CI or continuous monitoring.

Frequently asked questions

Does TLS 1.3 make a service secure by itself?

No. You still need certificate and service-name validation, safe clients, end-to-end termination review, protected keys and application authorisation.

Does mTLS replace OAuth or access control?

No. It can authenticate a client or bind a token to a certificate, but the application must still authorise the requested operation and resource.

Is a wildcard certificate always a vulnerability?

Not necessarily, but it increases the impact of key theft and reduces isolation. Consider the number of services, key storage, automation and whether per-service certificates are practical.

Can a public scanner assess private PKI?

Not comprehensively. It cannot observe private clients, backend connections, mTLS mapping, CA protection or key-rotation procedures. Those require architectural access and controlled testing.

Turn the audit result into a regression control

A report creates lasting value when the remediation is continuously enforced. Breachroad combines TLS and PKI analysis with penetration-test preparation, application testing and cloud review. The outcome is a risk-ranked plan plus controls that can move into infrastructure as code, CI and certificate monitoring.