WEB / WEB-05.02

Certificate chains and hostname validation

Separate certificate binding, local trust anchors and reference service identity.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Path + name

Select verifier context first
Reference identity and local anchor are selected independently of peer data.
Client · TLS
reference=api.example.org; local anchor selected; checks pending
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Certificate list at the client
The semantic list from an encrypted Certificate message arrived; trust and name checks are pending.
Client · TLS
certificate list received: leaf-atlas + int-atlas; validation pending
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Local path construction
Construct the selected prospective path from the leaf-first TLS list; the anchor is a separate input.
Client · TLS
selected path=int-atlas -> leaf-atlas; anchor local
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Path-check gate
Signature/time/constraints/status conditions are selected to pass; no real certificate validator runs.
Client · TLS
path checks=true; hostname pending; TLS proof unmodeled
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Independent name result
The normal SAN matches; live handshake proof is outside the scene.
Client · TLS
path=true; SAN name=true; certificate slice accepted; TLS proof unmodeled
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted

Name mismatch

Select verifier context first
Reference identity and local anchor are selected independently of peer data.
Client · TLS
reference=notes.example.org; local anchor selected; checks pending
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Certificate list at the client
The semantic list from an encrypted Certificate message arrived; trust and name checks are pending.
Client · TLS
certificate list received: leaf-atlas + int-atlas; validation pending
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Local path construction
Construct the selected prospective path from the leaf-first TLS list; the anchor is a separate input.
Client · TLS
selected path=int-atlas -> leaf-atlas; anchor local
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Path-check gate
Signature/time/constraints/status conditions are selected to pass; no real certificate validator runs.
Client · TLS
path checks=true; hostname pending; TLS proof unmodeled
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted
Independent name result
The path passes, but reference notes.example.org does not match SAN api.example.org. The certificate slice is rejected for that reason; CN fallback does not change the result.
Client · TLS
certificate slice rejected; no accepted service identity
Server · TLS
certificate list ready: leaf-atlas + int-atlas; anchor omitted

Intermediate absent

Select verifier context first
Reference identity and local anchor are selected independently of peer data.
Client · TLS
reference=api.example.org; local anchor selected; checks pending
Server · TLS
certificate list ready: leaf-atlas; anchor omitted
Certificate list at the client
The semantic list from an encrypted Certificate message arrived; trust and name checks are pending.
Client · TLS
certificate list received: leaf-atlas; validation pending
Server · TLS
certificate list ready: leaf-atlas; anchor omitted
Local path construction
No retrieval is selected for the missing local intermediate.
Client · TLS
path incomplete; no intermediate/cache/retrieval
Server · TLS
certificate list ready: leaf-atlas; anchor omitted
Path-check gate
The incomplete path is not accepted in this context.
Client · TLS
path rejected; hostname unevaluated; TLS proof unmodeled
Server · TLS
certificate list ready: leaf-atlas; anchor omitted
Incomplete path skipped hostname checking
The path cannot be completed without int-atlas and with no selected cache/retrieval. Hostname checking is skipped, leaving hostnameMatched null. This is not labeled a name mismatch or live TLS-proof failure.
Client · TLS
certificate slice rejected; no accepted service identity
Server · TLS
certificate list ready: leaf-atlas; anchor omitted

ACTORS · STATE · DATA FLOW

A certificate carries a signed binding

An X.509 certificate binds subject/public-key information, issuer, validity and extensions using a CA signature. It does not contain the private key. Seeing a public leaf certificate alone does not prove that the peer possesses that private key; TLS CertificateVerify separately binds such proof to the handshake context.

The artifact produces no DER or PEM: leaf-atlas and int-atlas aliases show issuer relationships and check fields. A subject label is not a verification decision for api.example.org; modern web service identity uses SAN DNS/IP identifiers and an independently selected reference identity.

CA authority starts from local trust policy

Trusting the public key of anchor-atlas is a local client input. Sending the same root from the server does not create new authority. Being self-signed is not sufficient for trust either; why and for which scope the anchor is trusted belongs to verifier policy.

RFC5280 path validation takes inputs such as trust-anchor key/name/constraints, a prospective path and current time. An anchor need not be supplied as a root-certificate file. This example selects a local anchor alias; it does not execute browser public trust-store policy, CA issuance audits or root-program assessment.

The TLS list and validated path differ in orientation

In a TLS Certificate list, the sender’s end-entity certificate comes first; subsequent entries SHOULD directly certify the previous one. The example sends [leaf-atlas,int-atlas]. The local anchor is omitted and already depends on verifier context. The leaf issuer alias links to the intermediate subject; the intermediate issuer links to the anchor name.

The RFC5280 algorithm expresses the path from the certificate nearest the anchor towards the target: [int-atlas,leaf-atlas] here, with the anchor as a separate input. TLS1.3 implementations can handle extraneous or arbitrarily ordered supporting certificates, but the leaf must be first. Alternative and cross-signed paths can exist, so the received list is not one universal path. The missing-intermediate branch selects no local cache or retrieval; under that condition a path cannot be completed.

A signature alone is not path validation

Issuer signatures, validity time, CA basic constraints/key usage, applicable name/policy constraints and critical extensions are distinct checks. The selected TLS-server purpose also matters for the leaf; extendedKeyUsage can constrain use when present. Drawing issuer arrows towards an anchor does not mean all these checks have run.

The artifact selects checks as declarative booleans; it does not parse ASN.1, execute certificate-signature mathematics or build a full policy tree. RFC5280 validity includes both notBefore and notAfter; equality cases calculate that boundary separately. Revocation status and policy also require current evaluation; this fixture selects an acceptable-status condition, claiming neither an online OCSP/CRL result nor identical browser policies.

Hostname verification does not take its expectation from the certificate

The client constructs reference DNS-ID api.example.org from https://api.example.org/. A presented SAN DNS name must match it; the selected exact ASCII comparison is case-insensitive. A CNAME target or connected IP does not automatically rename the reference DNS-ID in this ordinary web example. Path checks may pass while hostname matching fails.

RFC9525 removes commonName fallback for service identity: without a SAN match, even an identical CN does not establish a match in this modern profile. If the application profile supports wildcards, one * may appear only as the complete left-most label and match exactly one label: *.example.org matches api.example.org, but not example.org or a.api.example.org. Partial a*.example.org is ignored. Stricter application or issuance policies can prohibit wildcards; public-suffix issuance rules such as *.org are not implemented here.

IP and IDN require more than one string rule

A literal IP URL produces an IP-ID reference, requiring exact comparison with address octets in an iPAddress SAN. A DNS SAN string of "192.0.2.10" is not a substitute for an iPAddress SAN. Resolving to one IP does not make different DNS names equivalent.

IDN reference names require conversion of U-labels to IDNA A-labels before case-insensitive ASCII comparison. This artifact uses ordinary ASCII DNS, documentation IPs and the preselected A-label xn--bcher-kva.example; it is not a full IDNA or browser-normalization implementation. Valid service identity does not additionally certify the semantic trustworthiness of displayed content or a business owner’s identity.

Read every scenario without motion

Hostname gate

The peer list is not the local anchor
The TLS sent list contains leaf-atlas, int-atlas; anchor-atlas is a locallyTrusted=true input with sentByServer=false. A peer-supplied self-signature does not create local trust policy.
Certificate evidence
Peer list / local anchor separate
Path/name gate
No trust gate
Service acceptance
No service acceptance
Path predicates retain context
name-mismatch gives pathAccepted=true. Passing signatures, validity, constraints and server-purpose predicates does not remove reference-hostname checking.
Certificate evidence
Peer list / local anchor separate
Path/name gate
Path true / name still required
Service acceptance
No service acceptance
The service-identity gate stayed separate
Reference notes.example.org does not match presented SAN api.example.org. hostnameMatched=false and certificateSliceAccepted=false; chain success does not compensate.
Certificate evidence
Peer list / local anchor separate
Path/name gate
Path true / name still required
Service acceptance
Reference name mismatch
CN fallback did not expand scope
In nameMatrix, empty SAN with commonName=api.example.org has expected=false. This modern SAN-only profile does not use CN to repair name failure.
Certificate evidence
SAN-only / CN not fallback
Path/name gate
Path true / name still required
Service acceptance
Reference name mismatch
A certificate signature is not live key proof
A CA signature is a path predicate for public-key binding. Live possession proof belongs to CertificateVerify/Finished; liveTlsKeyProofExecuted=false remains unchanged here.
Certificate evidence
SAN-only / CN not fallback
Path/name gate
Path/name slice / live proof absent
Service acceptance
Reference name mismatch
The failure gate ended within scope
The certificate slice is rejected for name mismatch. This is neither an actual certificate attack, user authorization nor a verdict on a whole TLS implementation.
Certificate evidence
SAN-only / CN not fallback
Path/name gate
Path/name slice / live proof absent
Service acceptance
Name mismatch / acceptance withheld

Intermediate gap

The peer list is not the local anchor
In this missing-intermediate branch the peer supplies only leaf-atlas. anchor-atlas is a separate locally trusted input, not sent by the server. Missing int-atlas is not the same as a missing local anchor.
Certificate evidence
Peer: leaf-atlas / anchor local
Path/name gate
No trust gate
Service acceptance
No service acceptance
Path predicates retain context
missing-intermediate supplies only leaf-atlas with cacheOrRetrievalSelected=false and pathAccepted=false. This local context is not generalized to browser caches or alternate paths.
Certificate evidence
Peer: leaf-atlas / anchor local
Path/name gate
Path false / no retrieval
Service acceptance
No service acceptance
The service-identity gate stayed separate
An incomplete path leaves hostnameMatched=null and certificateSliceAccepted=false. A missing check is not filled with true; external retrieval is not selected here.
Certificate evidence
Peer: leaf-atlas / anchor local
Path/name gate
Path false / no retrieval
Service acceptance
Certificate slice withheld
Missing issuer stops before name checking
leaf-atlas names Atlas intermediate as issuerAlias, but int-atlas is unavailable and no cache/retrieval is selected. The anchor key does not replace the missing issuer certificate. This branch does not proceed to SAN comparison; hostnameMatched stays null.
Certificate evidence
leaf-atlas present / int-atlas missing
Path/name gate
Path false / no retrieval
Service acceptance
Certificate slice withheld
A certificate signature is not live key proof
A CA signature is a path predicate for public-key binding. Live possession proof belongs to CertificateVerify/Finished; liveTlsKeyProofExecuted=false remains unchanged here.
Certificate evidence
leaf-atlas present / int-atlas missing
Path/name gate
Path/name slice / live proof absent
Service acceptance
Certificate slice withheld
The failure gate ended within scope
Available certificates and no-retrieval context stop the path gate; no actual trust-store, parser or network behavior is measured.
Certificate evidence
leaf-atlas present / int-atlas missing
Path/name gate
Path/name slice / live proof absent
Service acceptance
Path incomplete / acceptance withheld

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: a presented root is trusted

A presented root’s self-signature does not explain why the verifier trusts its key. The required mistake is replacing independent trust-anchor policy with peer-supplied data.

Keep local trust input separate from the peer’s chain. The selected missing-intermediate check stops at local lookup; it makes no automatic request to an external endpoint.

Broken assumption: a valid chain makes hostname irrelevant

A certificate from a selected trusted CA for another service does not automatically authenticate the service named by the URL. The required condition is skipping reference-identity matching because path checks passed.

Independently select the reference name from URL or configuration and compare it with presented SAN identifiers. In the modern profile, a matching CN must not compensate for SAN failure.

Broken assumption: a certificate signature proves possession

The CA signature covers the public-key binding; that data alone does not show that the live peer controls the private key. The CertificateVerify handshake signature and Finished provide separate evidence.

Keep path, name, handshake proof and application-policy results distinct. Valid certificate fields are not full TLS completion or user permissions.

Read every scenario without motion

SAN matrix

Both chain directions were separated
tlsSentList is leaf-first: leaf-atlas, int-atlas. prospectivePathAnchorToTarget is int-atlas, leaf-atlas; anchor-atlas is local input, not a prospective-path member.
Certificate metadata
Sent leaf→int / path int→leaf
Name/time calculation
No matrix calculation
Acceptance review
No acceptance proof
Name-match rules were calculated
*.example.org matches api.example.org but not example.org or a.api.example.org. Partial wildcard a*.example.org and wildcardsAllowed=false are separate negative controls.
Certificate metadata
Sent leaf→int / path int→leaf
Name/time calculation
One-label wildcard / no partial wildcard
Acceptance review
No acceptance proof
The reference type was preserved
IP-ID 192.0.2.10 matches presentedIp but not the same string in presentedDns. ASCII case-insensitive DNS matching and preNormalizedALabel IDN carry separate type predicates.
Certificate metadata
DNS-ID ≠ IP-ID / normalized A-label
Name/time calculation
One-label wildcard / no partial wildcard
Acceptance review
No acceptance proof
UTC validity equality was calculated
notBefore=2026-10-01T00:00:00Z and notAfter=2026-10-31T00:00:00Z are inclusive. One second before/after fails; UTC arithmetic is not a certificate cryptography test.
Certificate metadata
DNS-ID ≠ IP-ID / normalized A-label
Name/time calculation
Endpoints inclusive / ±1s outside
Acceptance review
No acceptance proof
The acceptance conjunction retained its gaps
validationConditions are supplied Boolean predicates. Passing path/name can accept the selected certificate slice; nativePathValidatorRun=false and liveTlsKeyProofExecuted=false prevent adding a full TLS outcome.
Certificate metadata
DNS-ID ≠ IP-ID / normalized A-label
Name/time calculation
Endpoints inclusive / ±1s outside
Acceptance review
Certificate slice / handshake unknown
Regression stayed within the bounded matrix
This matrix compares exact DNS, wildcard, IP-ID and CN-only conditions separately. An actual client decision needs the reference identity used, presented SAN and path/name-check result. The matrix measures no DER/ASN1 parsing, CRL/OCSP or browser acceptance.
Certificate metadata
DNS-ID ≠ IP-ID / normalized A-label
Name/time calculation
Endpoints inclusive / ±1s outside
Acceptance review
SAN matrix consistent / handshake unknown

Validity boundary

Certificate interval and verifier time differ
leaf-atlas supplies notBefore 2026-10-01T00:00:00Z and notAfter 2026-10-31T00:00:00Z. These certificate fields are compared with the verifier's evaluation time at; presenting a validity range does not set the client's clock.
Certificate metadata
leaf-atlas: 1 Oct–31 Oct UTC
Name/time calculation
No matrix calculation
Acceptance review
No acceptance proof
Validity includes both boundaries
The evaluation uses notBefore ≤ at ≤ notAfter, including both endpoints. This date comparison answers validity only; issuer signature, SAN and revocation require separate checks.
Certificate metadata
leaf-atlas: 1 Oct–31 Oct UTC
Name/time calculation
notBefore ≤ at ≤ notAfter
Acceptance review
No acceptance proof
Before-start and equality are distinct
At 2026-09-30T23:59:59Z the interval has not started, so the result is false. One second later, 2026-10-01T00:00:00Z equals notBefore and that row is true. Time changes for the same certificate, rather than its trust anchor.
Certificate metadata
30 Sep 23:59:59 false / 1 Oct 00:00:00 true
Name/time calculation
notBefore ≤ at ≤ notAfter
Acceptance review
No acceptance proof
End equality differs from one second later
At 2026-10-31T00:00:00Z equality with notAfter is true. One second later, 2026-10-31T00:00:01Z is outside the interval and false. These rows calculate certificate validity, not an application session's lifetime.
Certificate metadata
30 Sep 23:59:59 false / 1 Oct 00:00:00 true
Name/time calculation
31 Oct 00:00:00 true / 00:00:01 false
Acceptance review
No acceptance proof
Date arithmetic is not full TLS proof
The normal branch supplies passing path conditions including validity. Date-row arithmetic is not an actual certificate signature or full PKIX-validator result. Even with accepted path and SAN, liveTlsKeyProofExecuted remains false in this scene.
Certificate metadata
30 Sep 23:59:59 false / 1 Oct 00:00:00 true
Name/time calculation
31 Oct 00:00:00 true / 00:00:01 false
Acceptance review
Certificate slice / handshake unknown
Verifier time needs separate evidence
Actual validity evidence needs the verifier's evaluation time, the certificate interval it used and the related path result. This example compares UTC boundaries without observing client clock policy, revocation information or browser acceptance.
Certificate metadata
30 Sep 23:59:59 false / 1 Oct 00:00:00 true
Name/time calculation
31 Oct 00:00:00 true / 00:00:01 false
Acceptance review
Validity matrix consistent / runtime unknown

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Draw the two chain orientations

The TLS list is leaf-first; the selected validation path is intermediate-to-leaf, with a local anchor input. Mark issuer/subject aliases and signature-check conditions separately.

The missing-intermediate branch has no cache or retrieval. Do not generalize that selected condition to all browser outcomes; alternate paths and cached intermediates belong to different contexts.

Calculate the SAN match matrix

Compare exact ASCII, one-label wildcard, apex and deeper-name rows. Case differences do not break matching, while wildcard label count changes the result.

The CN-only row remains false in the modern profile; the IP-ID row does not match a DNS SAN string. The IDN example compares only its already-normalized A-label form.

The acceptance gate is a conjunction

Path, hostname and peer-key proof are required together. The scene completes only its certificate/path/name slice: even the normal final step leaves live TLS key proof outside the scene.

Calculate validity boundaries using actual UTC instants; notAfter equality is inclusive. Do not describe boolean fixtures as real revocation, policy-tree or certificate-parser tests.

Bind an automated client’s reference identity to its intended service before connection and keep certificate checks enabled in normal configuration. Presenting notes.example.org instead of api.example.org means reachable but a different identity; terminate the attempt with an error and record the identity mismatch. Disabling hostname checks to solve connectivity does not secure the successful path. Under the same configuration, verify that the correct identity is accepted while name mismatch never proceeds to protected use.

NOW APPLY IT TO THE CASE

Which separate decisions involve local trust, reference name and live proof?

The Atlas leaf certificate has api.example.org in its SAN. If the reference identity is notes.example.org, a successful path still does not match the hostname. Local anchor, intermediate availability and UTC validity are separate conditions.

Who is the peer of the case’s secure connection? Explain TLS peer trust, browser origin and user object permission as separate decisions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas · certificate-path-name-matrix

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "referenceUrl": "https://api.example.org/",
    "referenceDnsId": "api.example.org",
    "serviceIdentity": "RFC9525 SAN-only DNS/IP bounded examples",
    "derPemProduced": false,
    "nativePathValidatorRun": false,
    "privateKeyBytesPresent": false
  },
  "anchor": {
    "id": "anchor-atlas",
    "name": "Atlas Root teaching alias",
    "publicKeyAlias": "anchor-public",
    "locallyTrusted": true,
    "sentByServer": false,
    "partOfProspectivePath": false
  },
  "certificates": [
    {
      "id": "leaf-atlas",
      "subjectAlias": "Atlas leaf",
      "issuerAlias": "Atlas intermediate",
      "publicKeyAlias": "leaf-public",
      "sanDns": [
        "api.example.org"
      ],
      "notBefore": "2026-10-01T00:00:00Z",
      "notAfter": "2026-10-31T00:00:00Z",
      "ca": false,
      "keyUsage": [
        "digitalSignature"
      ],
      "extendedKeyUsage": [
        "serverAuth"
      ],
      "issuerSignatureValidSelected": true
    },
    {
      "id": "int-atlas",
      "subjectAlias": "Atlas intermediate",
      "issuerAlias": "Atlas Root teaching alias",
      "publicKeyAlias": "intermediate-public",
      "ca": true,
      "keyUsage": [
        "keyCertSign"
      ],
      "issuerSignatureValidSelected": true,
      "applicableConstraintsPassSelected": true
    }
  ],
  "tlsSentList": [
    "leaf-atlas",
    "int-atlas"
  ],
  "prospectivePathAnchorToTarget": [
    "int-atlas",
    "leaf-atlas"
  ],
  "validationConditions": {
    "signatures": true,
    "validity": true,
    "caAndKeyUsage": true,
    "applicableConstraints": true,
    "criticalExtensions": true,
    "selectedServerPurpose": true,
    "selectedRevocationPolicyAcceptable": true
  },
  "nameMatrix": [
    {
      "reference": "api.example.org",
      "type": "DNS-ID",
      "presented": [
        "api.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": true
    },
    {
      "reference": "API.EXAMPLE.ORG",
      "type": "DNS-ID",
      "presented": [
        "api.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": true
    },
    {
      "reference": "api.example.org",
      "type": "DNS-ID",
      "presented": [
        "*.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": true
    },
    {
      "reference": "example.org",
      "type": "DNS-ID",
      "presented": [
        "*.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": false
    },
    {
      "reference": "a.api.example.org",
      "type": "DNS-ID",
      "presented": [
        "*.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": false
    },
    {
      "reference": "api.example.org",
      "type": "DNS-ID",
      "presented": [
        "a*.example.org"
      ],
      "wildcardsAllowed": true,
      "expected": false
    },
    {
      "reference": "api.example.org",
      "type": "DNS-ID",
      "presented": [
        "*.example.org"
      ],
      "wildcardsAllowed": false,
      "expected": false
    },
    {
      "reference": "api.example.org",
      "type": "DNS-ID",
      "presented": [],
      "commonName": "api.example.org",
      "wildcardsAllowed": true,
      "expected": false
    },
    {
      "reference": "xn--bcher-kva.example",
      "type": "DNS-ID",
      "presented": [
        "xn--bcher-kva.example"
      ],
      "wildcardsAllowed": true,
      "preNormalizedALabel": true,
      "expected": true
    },
    {
      "reference": "192.0.2.10",
      "type": "IP-ID",
      "presentedIp": [
        "192.0.2.10"
      ],
      "expected": true
    },
    {
      "reference": "192.0.2.10",
      "type": "IP-ID",
      "presentedDns": [
        "192.0.2.10"
      ],
      "presentedIp": [],
      "expected": false
    }
  ],
  "validityCases": [
    {
      "at": "2026-09-30T23:59:59Z",
      "withinInclusiveValidity": false
    },
    {
      "at": "2026-10-01T00:00:00Z",
      "withinInclusiveValidity": true
    },
    {
      "at": "2026-10-31T00:00:00Z",
      "withinInclusiveValidity": true
    },
    {
      "at": "2026-10-31T00:00:01Z",
      "withinInclusiveValidity": false
    }
  ],
  "cases": [
    {
      "case": "normal",
      "availableCertificates": [
        "leaf-atlas",
        "int-atlas"
      ],
      "cacheOrRetrievalSelected": false,
      "pathAccepted": true,
      "hostnameMatched": true,
      "certificateSliceAccepted": true,
      "liveTlsKeyProofExecuted": false
    },
    {
      "case": "name-mismatch",
      "availableCertificates": [
        "leaf-atlas",
        "int-atlas"
      ],
      "reference": "notes.example.org",
      "pathAccepted": true,
      "hostnameMatched": false,
      "certificateSliceAccepted": false,
      "liveTlsKeyProofExecuted": false
    },
    {
      "case": "missing-intermediate",
      "availableCertificates": [
        "leaf-atlas"
      ],
      "cacheOrRetrievalSelected": false,
      "pathAccepted": false,
      "hostnameMatched": null,
      "certificateSliceAccepted": false,
      "liveTlsKeyProofExecuted": false
    }
  ],
  "limits": "Declarative issuer/path/name relationships; no DER/ASN1, signature verification, actual trust store, CRL/OCSP, browser policy, live handshake or network retrieval."
}

anchor: Local trust input separate from peer-supplied data.
certificates: Field aliases without real certificate bytes.
tlsSentList: Selected leaf-first TLS-list order.
prospectivePathAnchorToTarget: Validation orientation with the anchor as a separate input.
nameMatrix: Modern SAN-only bounded ASCII/IP examples.

Field and decision fixtures, not full PKIX, DER, revocation or actual browser-validation results.

Two reality checks

Sending a root certificate makes the client trust it.

The anchor is an independent local-policy input; the peer’s list does not create trust.

*.example.org covers subdomains at every depth.

Where permitted, a complete left-most * matches exactly one label, not the apex or two labels.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The chain path is accepted, but reference notes.example.org does not match SAN api.example.org. Is the certificate slice accepted?

No; hostnameMatched=false.
Yes; a trusted root approves all hostnames.

Read the explained answer

No; hostnameMatched=false. — A trusted issuer path does not authorize another DNS service name; certificateSliceAccepted remains false.

The root alias is absent from the server list. Is this alone a missing-chain error?

Selected lesson artifact fields; teaching example

anchor: {"id":"anchor-atlas","name":"Atlas Root teaching alias","publicKeyAlias":"anchor-public","locallyTrusted":true,"sentByServer":false,"partOfProspectivePath":false}
tlsSentList: ["leaf-atlas","int-atlas"]
prospectivePathAnchorToTarget: ["int-atlas","leaf-atlas"]

No; the local anchor is trusted and the leaf+intermediate list is supplied.
No path can be built unless the peer sends the root.

Read the explained answer

No; the local anchor is trusted and the leaf+intermediate list is supplied. — The anchor has locallyTrusted=true and sentByServer=false. The TLS list is leaf-first; the prospective path is shown here anchor-to-target.

Why does SAN *.example.org match api.example.org but not a.api.example.org or example.org?

Read the explained answer

In this qualified DNS-ID profile, the wildcard covers one complete left-most label. api is one label; a.api is two; example.org supplies no wildcard label. If wildcard policy disallows it, even the first match fails; legacy Common Name fallback is not used here.

□ I limited the wildcard to one label.

□ I preserved SAN and wildcard-policy conditions.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Internet X.509 Public Key Infrastructure4.1.1 Certificate Fields · 4.1.2.5 Validity · 4.2.1.3 Key Usage · 4.2.1.6 Subject Alternative Name · 4.2.1.9 Basic Constraints · 4.2.1.10 Name Constraints · 4.2.1.12 Extended Key Usage · 6.1 Basic Path Validation · 6.1.1 Inputs · 6.1.3 Basic Certificate Processing · 6.2 Using the Path Validation Algorithm
Service Identity in TLS6.1.1 Constructing Reference Identifiers — Rules · 6.2 Preparing to Seek a Match · 6.3 Matching the DNS Domain Name Portion · 6.4 Matching an IP Address Portion · 7.7 Certificate Trust · Appendix A Changes from RFC6125 · 6.6 Outcome
TLS 1.3 — current specification (2026)1 Introduction · 1.2 Relationship to RFC8446 · 2 Protocol Overview · 4.2 Hello Messages · 4.3 Extensions · 4.4.1 Encrypted Extensions · 4.5 Authentication Messages · 4.5.1 Certificate · 4.5.2 Certificate Verify · 4.5.3 Finished · 5.2 Record Payload Protection · 5.3 Per-Record Nonce · 7.1 Key Schedule · 7.4.2 Elliptic Curve Diffie-Hellman
TLS 1.3 — original specification (2018; obsoleted by RFC9846)2 Protocol Overview · 4.4.2 Certificate · 4.4.3 Certificate Verify · 4.4.4 Finished · 5.2 Record Payload Protection

YOUR NOTES / THIS BROWSER

Certificate chains and hostname validation

1. Core · Mechanism

Path + name

Name mismatch

Intermediate absent

A certificate carries a signed binding

CA authority starts from local trust policy

The TLS list and validated path differ in orientation

A signature alone is not path validation

Hostname verification does not take its expectation from the certificate

IP and IDN require more than one string rule

2. Red · Trust & Impact

Hostname gate

Intermediate gap

Broken assumption: a presented root is trusted

Broken assumption: a valid chain makes hostname irrelevant

Broken assumption: a certificate signature proves possession

3. Blue · Secure development & defense

SAN matrix

Validity boundary

Draw the two chain orientations

Calculate the SAN match matrix

The acceptance gate is a conjunction

Which separate decisions involve local trust, reference name and live proof?

Two reality checks

The chain path is accepted, but reference notes.example.org does not match SAN api.example.org. Is the certificate slice accepted?

The root alias is absent from the server list. Is this alone a missing-chain error?

Why does SAN *.example.org match api.example.org but not a.api.example.org or example.org?

Sources and scope