A signed certificate is only one part of validation

Path construction searches for a chain from the presented leaf through suitable issuers to a configured trust anchor. Path validation checks the candidate under the applicable rules. These are different tasks: failing to find an intermediate is not the same as finding a path whose constraints reject it. The root's self-signature is not what makes it trusted. Trust comes from the client's configured anchor information and policy; an attacker can create a perfectly self-signed certificate without earning that trust.

Issuer signatures, basic constraints, path-length constraints, critical extensions, name constraints where applicable, and key usage all contribute to validation. An intermediate that is not permitted to act as a CA cannot simply sign its way into that role. Extended key usage can further restrict the leaf's intended purpose, such as server authentication. A validator must apply its rules to the relevant path rather than treating a recognized issuer organization name or a familiar certificate filename as sufficient evidence.

For a DNS-named service, the client starts with a reference identity obtained from the intended service configuration or application context and compares it with appropriate subjectAltName identifiers. RFC 9525 does not use the certificate's commonName as a fallback identity. A certificate valid for one unrelated name is not valid for the name the client intended, even if the same trusted CA issued it. For an IP-address reference identity, the typed IP-address identifier matters; a DNS string that happens to spell digits is not automatically equivalent.

Server Name Indication helps a server choose a virtual host; it does not itself perform the client's identity verification. Likewise, allowing the presented certificate to tell the client which name it meant to contact reverses the trust direction. Test a correct chain with the wrong service name and require rejection. Keep wildcard and internationalized-name handling within the verifier's documented rules rather than writing an improvised suffix comparison. The simple examples here use exact DNS-name matches so that the expected identity is unambiguous.

A diagnostic tool can display a verification error yet continue its handshake for inspection. That behavior must not be confused with a production client's acceptance policy. Review whether errors actually terminate the connection and whether the application proceeds after the library reports them. Also verify the clock and trust store used by the real process, since a test shell can use different configuration. A successful check against an administrator's machine does not establish that every workload has loaded the intended anchors.

In the probability lab, model a synthetic fleet in which an independently selected instance has a 0.1 probability of using a mistaken trust configuration. Reset, set both p=0.1 and n=20, predict the zero-detection probability, then Play or Step to inspect the exact outcomes. The bars enumerate a binomial distribution; playback does not sample new instances or validate certificates. Correlated images and shared trust bundles break the independence assumption, so targeted checks of each deployment group remain necessary.