The certificate carries a public key
A typical X.509 public-key certificate contains the information to be signed, a signature algorithm and a signature value. Signed fields include a serial number, issuer, validity, subject, public key and extensions, binding their contents against alteration.
SubjectPublicKeyInfo identifies a public key and its algorithm, rather than storing the holder’s private key. A certificate can cross an untrusted network because recipients validate it; obtaining its public copy does not confer possession of the corresponding private key.
References: [1]
Trusted issuance still needs a name match
TLS service verification starts with reference identifiers derived from the intended address or other trusted input, then compares them with presented certificate identifiers. RFC 9525 requires reference identifiers to be constructed independently of the server’s claims.
IP identifiers match the subjectAltName address octet for octet, while DNS matching has separate rules, including limits on wildcards. The updated specification removes commonName fallback. Neither a valid signature nor encryption alone substitutes for matching the intended service.
References: [2]
Time and usage constraints matter
notBefore and notAfter define a declared validity interval. Validation also handles a certification path, applicable revocation information and usage restrictions. When keyUsage and extendedKeyUsage are both present, both constrain use rather than granting one certificate every purpose.
Successful checking accepts a name–key binding under selected trust and protocol conditions. It does not establish the truth of a website’s content or the merit of a transaction. Possessing the certificate file also differs from proving use of its corresponding private key in a protocol.