--- title: "A Trusted Certificate Still Has to Match the Intended AI Service" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/tls-service-reference-name-certificate-trust" last-updated: "2026-10-21" --- # A Trusted Certificate Still Has to Match the Intended AI Service Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. In certificate-based TLS, the client compares an independently established expected service name with the appropriate name in the server certificate, alongside separate certificate and handshake checks. A trusted certificate containing only the DNS-ID api.example.test matches that intended DNS name. It does not match models.example.test, even if both names reach the same address. Evaluate the match for the endpoint you intend to use. ## Service identity connects an expectation to a presented name RFC 9525, Service Identity in TLS, published in November 2023, distinguishes the client's reference identifier from the server's presented identifier. For the explicit DNS-ID and ordinary ASCII DNS names considered here, the certificate's DNS-ID is a dNSName entry in its subjectAltName extension. The client compares its expected DNS name with that entry. A successful comparison identifies the matched reference name; the certificate does not choose the intended destination for the client. This distinction makes a certificate relevant to a particular connection. Describing it as trusted leaves the reader without the other half of the comparison: trusted for which intended name? A proposal for an AI service needs that name to remain visible when its certificate evidence is assessed. References: [S1](https://www.rfc-editor.org/rfc/rfc9525.html) ## The expected name needs a basis outside the arriving certificate For HTTPS, RFC 9110, HTTP Semantics, constructs the reference identity from the service's host. An endpoint URL can therefore supply the expected DNS name. RFC 9525 requires reference identifiers to be constructed independently of the identifiers presented by the server. Taking whichever name appears in the arriving certificate and treating it as the expectation would make the comparison circular. It would answer whether the certificate names itself, while leaving the intended service unidentified. Likewise, a correctly matched name derived from an incorrect endpoint choice cannot repair that earlier choice. The application owner's intended service and the endpoint named in the offer need to refer to the same destination before a matching result becomes useful purchase evidence. References: [S1](https://www.rfc-editor.org/rfc/rfc9525.html), [H1](https://www.rfc-editor.org/rfc/rfc9110.html) ## TI-54: the same certificate supports two different conclusions Consider fictional example TI-54. One hypothetical server certificate contains only the DNS-ID api.example.test. Stipulate that its certification path, time validity, permitted certificate use and all other unmentioned certificate and handshake checks are satisfied. These assumptions isolate name matching; no certificate or network test has been performed. A client expecting api.example.test finds that name in the presented DNS-ID. Its service-name comparison succeeds. A second client expects models.example.test and receives the same certificate. That comparison fails: the only presented DNS-ID is api.example.test. The trusted issuer and satisfied time checks are unchanged, but they cannot supply the missing name. Suppose both names reach the same address. The second conclusion remains a mismatch. Address equality has added no models.example.test identifier to the certificate. Evidence establishing the api.example.test match cannot be carried across to the second intended name merely because the physical destination appears unchanged. RFC 9110's origin model retains the host name as part of the origin; shared infrastructure does not remove that distinction. References: [S1](https://www.rfc-editor.org/rfc/rfc9525.html), [H1](https://www.rfc-editor.org/rfc/rfc9110.html) ## Trust, validity and channel protection retain their own jobs Certificate validation concerns more than the name comparison. RFC 5280's path-validation framework includes signature, validity-period and revocation checks. Those checks concern the acceptability of the certificate and its path; passing them does not insert an absent service name. Conversely, finding the expected name does not establish that those other checks passed. The certificate alone is also different from an authenticated TLS exchange. In certificate-based TLS 1.3, RFC 8446's CertificateVerify message supplies proof of possession of the corresponding private key. TLS channel protection then concerns confidentiality and integrity between its peers. A copied certificate document is not that handshake evidence, and an encrypted-connection statement alone does not report which expected name was compared. Each claim needs evidence appropriate to the fact it asserts. References: [P1](https://www.rfc-editor.org/rfc/rfc5280.html#section-6.1.3), [T1](https://www.rfc-editor.org/rfc/rfc8446.html), [N1](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html) ## A matched service name leaves model behavior and access to the application A DNS-ID names a domain, not a model version, model artifact or inference operation. RFC 9525 also expressly separates certificate checking from checks on rogue servers or faulty applications. A successful comparison therefore cannot establish that the named endpoint is benign, uncompromised or serving the model the buyer intended. Permission is another application question. RFC 9110 treats HTTP access authentication separately from HTTPS certificate verification. Establishing the server's name does not grant the API caller access to a protected resource. The related JWT guide explains token recipient, time and permission decisions; the related MACsec/TLS guide explains where transport protection ends. Neither decision should be substituted for the expected-name comparison here. References: [S1](https://www.rfc-editor.org/rfc/rfc9525.html), [H1](https://www.rfc-editor.org/rfc/rfc9110.html) ## Make the evidence statement specific enough to decide For TI-54, the useful conclusion is precise: api.example.test was the expected reference name, api.example.test was the presented DNS-ID, and the name comparison matched under the stated assumptions. That supports the name portion of the intended api.example.test connection. It supports no equivalent conclusion for models.example.test. Apply that distinction when reading an offer's evidence. A record that identifies only an issuer or says the connection was encrypted leaves the intended-name comparison unresolved. A result tied to another hostname answers another question. Keep the endpoint being purchased visible in the conclusion, together with the separate certificate and handshake evidence on which the offer relies. That gives the buyer a defined service-identity claim to assess without treating it as approval of the whole application. References: [S1](https://www.rfc-editor.org/rfc/rfc9525.html), [P1](https://www.rfc-editor.org/rfc/rfc5280.html#section-6.1.3), [T1](https://www.rfc-editor.org/rfc/rfc8446.html) ## Connect a separate cabling requirement to its physical handoff If the surrounding AI deployment also requires fiber or copper installation, use Leviathan's Structured Cabling & Fiber Installation service and the project inquiry linked below to discuss approved connections, routes, materials responsibilities and returned connection records. That physical package has its own handoff. TLS implementation and service-identity acceptance remain with the appointed application and security owners. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [S1 — RFC 9525: Service Identity in TLS](https://www.rfc-editor.org/rfc/rfc9525.html). Checked 2026-10-20. November 2023; sections 1.5 and 6 define the identifiers and their comparison; section 7.7 limits conclusions about application behavior. This article isolates an explicit DNS-ID case. - [H1 — RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html). Checked 2026-10-20. June 2022; sections 4.3.1 and 4.3.4 connect HTTPS origin and host identity; section 11 distinguishes access authentication. RFC 9525 supplies the service-identity rules used here. - [P1 — RFC 5280: Internet X.509 PKI Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280.html#section-6.1.3). Checked 2026-10-20. May 2008; section 6.1.3 supports the distinction between path-validation checks and the intended service-name comparison. - [T1 — RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.html). Checked 2026-10-20. August 2018; section 1 explains channel properties and section 4.4.3 explains certificate private-key possession evidence. These are separate from choosing the expected DNS name. - [N1 — NIST SP 1800-16B: TLS Server Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html). Checked 2026-10-20. June 2020 final; section 2 explains a client's intended-address comparison and the distinct role of private-key possession. Used for background, without adopting management procedures. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical fiber and copper installation to agreed routes, endpoint labels and connection records, using customer-furnished or separately sourced materials. ## Related Leviathan resources - [Locate MACsec frame protection and TLS channel endpoints](/articles/macsec-frame-protection-tls-channel-endpoints) - [Separate JWT recipient, time and permission decisions](/articles/jwt-access-token-audience-time-and-permission) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Discuss a separate physical cabling requirement](/contact?service=structured-cabling&from=%2Farticles%2Ftls-service-reference-name-certificate-trust) - [TCP Can Receive Later Bytes While the Stream Still Waits on a Gap](/articles/tcp-cumulative-ack-sack-received-byte-gaps) ## Define the physical connections around your AI equipment Share a nonconfidential outline of the approved equipment endpoints, cable routes, appointed materials supplier and required connection records to discuss physical cabling scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/tls-service-reference-name-certificate-trust)