What Really Happens During an HTTPS Connection? TLS Explained

When you open an HTTPS page, your browser and the website need to do more than switch on encryption. They must negotiate how to communicate securely, establish shared keys, and check that the server has a certificate valid for the hostname you requested. Those steps happen before the browser sends ordinary HTTP content.

Understanding how HTTPS TLS works helps developers diagnose connection errors and make better security decisions. This guide follows a browser-to-server connection, explains certificates and trust chains, and shows how to inspect a handshake without mistaking a valid certificate for proof that a site is trustworthy.

Key takeaways

• HTTPS is HTTP sent through a TLS-protected connection; TLS provides encryption, integrity checks, and server authentication.
• A browser checks that the server's certificate chains to a trusted root and is valid for the requested hostname, among other requirements.
• TLS negotiates protocol and cryptographic parameters, then derives shared keys to protect application data.
• A valid HTTPS connection does not prove that a site is honest, free of malware, or safe to use.

HTTPS and TLS: how they fit together

HTTPS is not a separate kind of web content. It is HTTP carried over a secure transport. For the common HTTP/1.1 and HTTP/2 setup, the browser establishes a TCP connection, negotiates TLS, and then sends HTTP requests inside the encrypted connection. HTTP/3 uses QUIC, which incorporates TLS 1.3 handshake mechanisms rather than placing TLS over TCP in the same way.

TLS protects data in transit against passive reading and unauthorized modification. It also authenticates the server to the client when certificate validation succeeds. The browser does not need to trust the website's operator as a person or business to perform that technical validation; it checks whether the connection meets its certificate and policy rules.

A TLS 1.3 handshake, step by step

The details differ by TLS version and connection setup. Here is the usual shape of a TLS 1.3 handshake without client-certificate authentication:

1. The browser sends a ClientHello. It offers supported TLS versions and cryptographic options, provides key-agreement material, and commonly includes the hostname using Server Name Indication (SNI). It may also offer an application protocol such as HTTP/2 using ALPN.
2. The server chooses parameters. In its ServerHello, it selects a supported version and key-agreement option and provides its corresponding key share. Both sides can now derive matching handshake secrets from the key agreement and the handshake transcript.
3. The server sends its identity and proves possession of a key. The server sends its certificate chain and a CertificateVerify message. The latter proves that the server controls the private key corresponding to the certificate's public key and binds the proof to the handshake. In TLS 1.3, most handshake messages after ServerHello are encrypted with handshake keys.
4. Both sides confirm the handshake. Each side sends a Finished message, which is checked using key material derived from the handshake. This helps detect tampering with the negotiation.
5. The browser sends HTTP over the protected connection. The peers use derived traffic keys to encrypt and authenticate application data. The certificate's public key is not normally used to encrypt each HTTP request; key agreement establishes shared secrets from which traffic keys are derived.

TLS 1.3 commonly uses ephemeral Diffie–Hellman key agreement, which can provide forward secrecy: later exposure of a server's long-term certificate private key alone should not reveal past session traffic captured from those connections. This depends on the negotiated setup and protection of ephemeral secrets. Resumed sessions have their own details, and TLS 1.3 early data (0-RTT), when enabled, has replay considerations; applications should not treat it as suitable for every request.

Certificates, hostname checks, and trust chains

A TLS certificate binds a public key to one or more identities, typically DNS names. A browser validates more than whether a certificate is present:

• Hostname: The requested hostname must match an identity in the certificate, usually in its Subject Alternative Name (SAN) entries. A certificate for shop.example.test does not automatically cover example.test or a different hostname.
• Validity and use: The certificate must meet time-validity, key-usage, and other applicable requirements. Browser behavior and policy can impose additional checks.
• Chain of trust: The server normally sends its certificate and any intermediate certificates needed to build a path to a root certificate trusted by the browser or operating system. A root certificate is generally a trust anchor in the client store; it is not made trustworthy merely because the server sent it.
• Signatures and policy: The client verifies signatures along the path and applies its certificate and security policies. Revocation checking and related behavior can vary across browsers and environments.

A missing intermediate certificate, an expired certificate, a hostname mismatch, or an untrusted issuer can cause a browser warning or connection failure. The server's certificate chain is part of the evidence for the server's network identity, not a quality rating for the site's content or business.

The X.509 certificate path model is described in RFC 5280, while TLS 1.3 is specified in RFC 8446. Browsers also apply implementation-specific trust stores and validation policies, so the standards do not imply identical user-interface behavior in every browser.

What gets encrypted—and what does not

After the handshake, TLS protects application data in transit using symmetric traffic keys and authenticated encryption. This makes it difficult for an on-path observer to read or alter the HTTP contents without detection, assuming the connection and endpoints are secure.

TLS does not hide every connection detail. Depending on protocol version, network setup, and features in use, observers may learn information such as IP addresses, timing, traffic volume, and some connection metadata. DNS lookups may also be visible to the network unless protected separately. TLS does not protect data after it reaches a compromised browser, server, or intermediary that is authorized to terminate the connection.

Practical example: inspect a connection

For a simple, authorized inspection of a public test hostname, OpenSSL's client can display negotiated details and the server's presented certificates. This command makes a network connection to the named host; use it only where you are permitted to connect.

openssl s_client -connect example.com:443 -servername example.com -showcerts

-servername sends SNI, which matters when a server hosts multiple sites at one IP address. Look for the negotiated protocol and cipher information, the certificate chain, and the verification result. Exact output varies by OpenSSL version and server configuration. A successful verification result is useful evidence that OpenSSL accepted the chain under its local trust configuration; it is not a guarantee that a browser with a different trust store or policy will behave identically.

You can also inspect a connection in your browser's developer tools. Open the page, select the Security or connection-details panel (the label varies), and review the certificate identity, issuer, and negotiated connection details. A browser's address bar and certificate viewer help diagnose transport security; they do not certify that a site's claims or downloads are safe.

For URL structure—not TLS validation—a URL parser can help you inspect URL components. Parsing a URL does not establish a secure connection or validate a certificate.

Common mistakes and troubleshooting

• Treating the padlock as an endorsement. It indicates a protected connection that passed the browser's checks, not that the site's operator is legitimate or its content is safe.
• Ignoring hostname mismatches. A trusted issuer cannot make a certificate for the wrong hostname valid. Check the exact hostname in the address bar and the certificate's SAN entries.
• Installing a certificate without fixing the cause. For a site you administer, confirm that the certificate is current, covers every required hostname, and that the server sends the necessary intermediate certificates. Do not tell users to bypass browser warnings.
• Assuming a browser and command-line tool use identical trust. They may rely on different trust stores, settings, or validation behavior. Compare the exact error and environment before drawing conclusions.
• Assuming encryption prevents endpoint compromise. TLS protects data in transit, not a user's device or the server after data is decrypted.

Recommended practices for developers

• Serve HTTPS consistently and configure certificates for every hostname users are expected to visit.
• Automate certificate renewal where appropriate, and monitor expiry and deployment failures.
• Configure modern TLS versions and cipher suites using the guidance for your server and platform; avoid copying a configuration without checking its compatibility and maintenance status.
• Keep private keys secret and restrict access to the systems and processes that need them.
• Treat certificate errors as real failures to investigate. Do not disable certificate verification in application code to make a connection succeed.
• Remember that TLS is one layer of security. Use secure application design, authentication, authorization, input handling, and endpoint protection as well.

Conclusion

An HTTPS connection is the result of negotiation, certificate validation, key establishment, and protected data exchange. The certificate helps the browser authenticate the requested hostname through a trust chain; the handshake establishes the keys used to protect HTTP traffic. These safeguards are essential, but they do not establish that a website is honest or that its content is safe. Understanding that distinction makes TLS easier to troubleshoot and HTTPS claims more precise.