What Does an HTTPS Certificate Verify? — Viewing the Entry Point of a TLS Connection Through a Sequence Diagram

About This Article
This article reviews current RFCs for TLS 1.3 and service name verification to clarify the role that server certificates play in HTTPS.

Verification Status: 📘 Official Specifications Confirmed / Public Site Observations Not Fixed
Because TLS implementations and browser displays vary by environment, this explanation focuses on protocol-level roles rather than specific product screens.

An HTTPS server certificate is not simply a “file that encrypts communication.” Within a TLS connection, it serves as material to verify the identity of the remote server by binding the connection destination’s name to its public key and using a certificate chain that leads to a trusted Certificate Authority (CA).

TLS combines this verification with key exchange to establish the session key used for communication.

Overview of the TLS 1.3 Flow

sequenceDiagram
    participant C as Client
    participant S as HTTPS Server

    C->>S: ClientHello
    S-->>C: ServerHello
    S-->>C: Certificate
    S-->>C: CertificateVerify
    S-->>C: Finished
    C->>C: 証明書・名前・署名等を検証
    C-->>S: Finished
    Note over C,S: 暗号化されたapplication data

While actual TLS 1.3 handshakes vary depending on conditions, grasping the relationship of “receive certificate → verify identity and certificate chain → verify that the server holds the private key → complete handshake” makes the overall process easier to understand.

What Does a Certificate Verify?

Typical evaluation points include the following:

• Whether the service name you are trying to connect to matches the identifier in the certificate

• Whether the certificate’s validity period and other attributes are correct

• Whether a certificate path to a trusted Certificate Authority can be constructed and verified

• Whether the server can demonstrate during the TLS handshake that it holds the private key corresponding to the certificate’s public key

flowchart TB
    A[Server certificate] --> B[名前の一致]
    A --> C[有効性]
    A --> D[Certificate chain]
    D --> E[Trust storeの信頼 anchor]
    A --> F[CertificateVerify]
    F --> G[対応する秘密鍵を持つことの証明]

What is Compared Against the URL Hostname?

Under the current IETF RFC 9525, service identity DNS names are evaluated by matching them against appropriate identifiers such as the dNSName within the subjectAltName.

Understanding that you only need to look at the Common Name, which frequently appeared in older explanations, is no longer appropriate for current service identity verification.

Example Domain

www.example.com

↓ reference identifier: www.example.com ↓ Matched against certificate's subjectAltName, etc.

If the names do not match, even if a different legitimate certificate is presented, it cannot be determined to be the “certificate for the service you attempted to access.”

What Is a Certificate Chain?

Rather than trusting a server certificate in isolation, the issuer is traced back to verify up to the trust anchor in the client’s trust store.

flowchart TB
    A[Server / Leaf certificate] --> B[Intermediate CA]
    B --> C[Root CA]
    C --> D[Client trust store]

Although actual path building and validation are more complex, this relationship is easy for beginners to grasp as an initial mental model.

Does Having a Certificate Mean All Communication Content Is Encrypted Entirely with That Public Key?

TLS 1.3 does not use a simple structure where the public key of the certificate directly encrypts the entire body of a web page.

Key agreement is performed during the handshake, and application data is protected using the secrets derived from it. While certificates are important for server authentication, it is more accurate not to equate them with the session data encryption method.

When Encountering Certificate Errors with curl

curl performs TLS certificate verification. If names do not match or a trust chain cannot be built, a verification error occurs.

In routine use, routinely relying on -k / –insecure as a way to “make errors go away” should be avoided.

flowchart TB
    A[curl HTTPS] --> B{certificate verification}
    B -->|OK| C[HTTPS requestを継続]
    B -->|NG| D[verify error]
    D --> E[名前・期限・chain・CA設定を調査]
    E -. 安易に検証無効化しない .-> D

Verification errors are not an obstructive feature; they are a safety mechanism that notifies you when the identity of the connection destination cannot be confirmed.

Does a Correct DNS Mean a Correct Certificate?

Being able to reach the correct IP address via DNS and being able to authenticate the connection target’s identity via TLS are separate layers.

flowchart LR
    A[DNS] --> B[接続先IPを得る]
    B --> C[TCP接続]
    C --> D[TLS handshake]
    D --> E[certificateでservice identityを検証]
    E --> F[HTTP]

Viewing these in separate layers makes it easier to avoid confusing DNS issues, TCP connectivity issues, TLS certificate errors, and HTTP errors.

Summary

• Server certificates bind the connection destination identity and the public key

• Clients verify names, certificate paths, validity, and more

• TLS 1.3 also confirms that the server holds the private key via mechanisms such as CertificateVerify

• Web body content is not entirely encrypted raw by the certificate’s public key

• DNS, TCP, TLS, and HTTP should be separated as distinct layers

• Do not disable certificate verification casually

Official and Primary Information Sources

RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
https://www.rfc-editor.org/rfc/rfc8446.html

RFC 9525 — Service Identity in TLS
https://www.rfc-editor.org/rfc/rfc9525.html

curl — TLS certificate verification
https://curl.se/docs/sslcerts.html