HTTPS: Secure Web Communication with TLS

Learn how HTTPS uses TLS, certificates, public key infrastructure, and secure handshakes to protect HTTP traffic, plus deployment and troubleshooting guidance.

HTTPS is HTTP communication protected by Transport Layer Security (TLS). It allows a browser and web server to exchange requests and responses while reducing the risk that other parties can read, modify, or impersonate the server connection.

This lesson covers HTTPS from a CCNA perspective: ports, protocol layers, certificates, TLS handshakes, cryptographic algorithms, web-server deployment, enterprise inspection, and troubleshooting.

What HTTPS Protects

Web applications commonly transmit credentials, payment information, session cookies, personal data, and API requests. If these messages use ordinary HTTP, a device that can observe the traffic may be able to read or alter the application data.

HTTPS adds TLS between HTTP and the transport network. TLS provides:

Confidentiality: Encryption helps prevent observers from reading application data.
Server authentication: A certificate helps the client verify that it is connecting to the domain named in the certificate.
Integrity: Authentication tags and related mechanisms detect altered or forged traffic.
Optional client authentication: A server can require a client certificate to authenticate the connecting device or user.

HTTPS does not automatically prove that a website is honest, safe, or free of malicious content. It primarily authenticates a domain identity and protects the connection to that authenticated endpoint.

HTTP Versus HTTPS

Default port: HTTP uses TCP port 80. HTTPS commonly uses TCP port 443.

Encryption: HTTP sends application data without TLS encryption. HTTPS encrypts HTTP data after the TLS session is established.

Server authentication: HTTP does not normally authenticate the server. HTTPS uses a certificate and certificate validation.

Integrity protection: HTTP does not provide cryptographic protection against alteration. HTTPS detects modification of protected traffic.

Typical use: HTTP is appropriate only for traffic that does not require confidentiality or authentication, and is often used to redirect clients to HTTPS. HTTPS is preferred for websites, logins, payments, APIs, and session-based applications.

Visibility to network observers: With HTTP, observers may read methods, URLs, headers, bodies, cookies, and responses. With HTTPS, observers can generally still see destination IP addresses, packet timing, packet sizes, and DNS lookups. Some TLS metadata may also remain visible, depending on the TLS version and configuration, but protected HTTP content is not normally readable.

HTTPS preserves the HTTP application model. HTTP methods such as GET and POST, headers, status codes, URLs, and request-response behavior still exist. TLS adds a protected transport around that exchange; it does not replace HTTP.

HTTPS in the Network Stack

A usual HTTPS-over-TCP stack is:

Application: HTTP request and response data.
Security: TLS encrypts and authenticates the HTTP exchange.
Transport: TCP provides the connection, sequencing, and retransmission.
Network: IP delivers packets between networks.
Data link: Ethernet or Wi-Fi carries frames across the local link.

For traditional HTTPS, the client first completes the TCP three-way handshake with the server's TCP port 443. TLS negotiation then begins over that TCP connection. Only after the secure session is ready does the client normally send protected HTTP data.

HTTP/3 changes the transport arrangement. It carries HTTP over QUIC, a UDP-based transport, with TLS 1.3 integrated into QUIC. Therefore, HTTP/3 does not use the traditional TCP port-443 connection process, although UDP port 443 is commonly used.

See the OSI Reference Model for a review of protocol-layer responsibilities.

Public Key Infrastructure and Certificates

A digital certificate is a signed document that binds a public key to an identity, such as a domain name. A public and private key form a cryptographic pair. The public key can be distributed; the private key must remain secret.

What a Certificate Contains

Important certificate fields include:

Subject and, most importantly for modern hostname validation, Subject Alternative Name (SAN) entries.
Issuer, identifying the CA that signed the certificate.
Validity start and expiration dates.
The server's public key.
The CA's digital signature over the certificate.
Key usage and extended key usage information, such as permission for server authentication.

When a client visits https://store.example.com, the certificate must contain that hostname in an appropriate name field, normally SAN. A certificate valid only for www.example.com does not authenticate store.example.com.

Certificate Authorities and Trust

A certificate authority (CA) issues and signs certificates. A root certificate is a trust anchor installed in an operating system, browser, or network-device trust store. An intermediate certificate is a CA certificate between the root and the server certificate.

A typical chain is:

The server presents its server certificate and usually one or more intermediate certificates.
The client verifies each signature in the chain.
The client checks validity dates, permitted uses, and hostname matching.
The chain must end at a root CA trusted by the client.

A server certificate issued by a publicly trusted CA can normally be validated by browsers without manual installation. A self-signed certificate is signed by itself rather than by a CA trusted by default. It can be useful in controlled testing, but browsers normally warn unless the certificate or its issuing CA is deliberately trusted.

Expiration and Revocation

Certificates have validity periods. An expired or not-yet-valid certificate causes a client warning or connection failure. Certificate revocation is used when a certificate should no longer be trusted before its expiration, for example after private-key compromise.

Certificate Revocation Lists (CRLs): Published lists of revoked certificate serial numbers.
Online Certificate Status Protocol (OCSP): A protocol through which a client or intermediary asks about a certificate's status.

Revocation checking behavior varies by browser, operating system, TLS library, stapling configuration, and network availability. It is not a substitute for protecting private keys and monitoring certificate lifetimes.

The TLS Handshake

The handshake negotiates a secure session before application data is exchanged. It establishes compatible protocol parameters, authenticates the server, creates shared secret material, and derives symmetric session keys.

Conceptual TLS 1.2 Sequence

The client sends ClientHello, including supported TLS versions, random data, cipher suites, and extensions such as SNI.
The server replies with ServerHello, selecting compatible parameters.
The server sends its certificate chain and may send key-exchange information.
The client validates the certificate chain, hostname, dates, key usage, and trust.
The client and server perform key establishment, commonly using an ephemeral Diffie-Hellman exchange.
Both sides derive symmetric session keys and exchange Finished messages that verify the handshake transcript.
Encrypted HTTP requests and responses follow.

High-Level TLS 1.3 Sequence

The client sends ClientHello with supported versions, key-share material, cipher options, and SNI.
The server responds with ServerHello, selects TLS 1.3 parameters, sends its certificate and authentication messages, and provides its key share.
The client validates the certificate and verifies the server's handshake signature.
Both sides derive handshake and application traffic keys, exchange Finished messages, and then protect HTTP data.

TLS 1.3 removes many legacy choices and commonly reduces the number of round trips compared with TLS 1.2. It can also support session resumption. During resumption, a client uses previously established session information, such as a ticket, to avoid repeating the full negotiation. A resumed session still creates fresh traffic keys.

Handshake efficiency: TLS 1.2 commonly requires more message exchanges; TLS 1.3 generally completes with fewer round trips.

Cryptographic approach: TLS 1.2 supports a wider range of historical cipher-suite combinations. TLS 1.3 separates negotiation more clearly and uses modern authenticated encryption and key exchange.

Legacy algorithm support: TLS 1.2 may be configured with unsafe legacy algorithms unless restricted. TLS 1.3 removes many of them.

Forward secrecy expectations: TLS 1.2 can use ephemeral Diffie-Hellman but does not require it in every configuration. TLS 1.3 requires ephemeral key exchange for ordinary handshakes.

Session resumption: Both versions support resumption mechanisms, but TLS 1.3 uses modern tickets and can offer an optional early-data mode with replay considerations.

Cryptography Used by HTTPS

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for large HTTP bodies and ongoing traffic.
Asymmetric cryptography uses a public/private key pair. TLS uses it primarily for authentication and, depending on the exchange, key establishment.
Hashing creates a fixed-size digest used to detect changes and authenticate handshake transcripts. A secure hash is designed to make reversing or finding collisions impractical.
Message authentication verifies that protected data came from a party holding the session secret and was not altered.
Digital signatures use a private key to sign data; a corresponding public key verifies the signature. Server certificates and TLS handshake authentication use signatures.

Ephemeral Diffie-Hellman, including modern elliptic-curve forms, creates temporary key-exchange values for a session. It provides forward secrecy: compromise of the server's long-term private key later should not expose recorded past sessions protected with independent ephemeral keys.

Modern TLS commonly uses authenticated-encryption modes such as AES-GCM and ChaCha20-Poly1305. They provide confidentiality and integrity together. SSL, TLS 1.0, TLS 1.1, weak cipher suites, obsolete key sizes, and deprecated hashes should not be enabled in modern deployments. The term SSL is still used informally, but SSL itself is obsolete and should not describe a secure configuration.

Deploying HTTPS on a Web Server

A server administrator obtains a certificate and private key, protects the private key with restrictive permissions, and binds them to a TLS listener or virtual host on port 443. The server should present the complete server and intermediate certificate chain, but not expose the private key.

Server Name Indication (SNI) is a TLS extension in which the client identifies the requested hostname during the handshake. It allows one IP address and listener to host multiple TLS sites with different certificates. The server uses SNI, together with virtual-host configuration, to select the correct certificate and application.

Redirects, HSTS, and Mixed Content

A common migration pattern leaves port 80 available only to return an HTTP redirect to the equivalent HTTPS URL on port 443. The redirect protects future requests, but the initial HTTP request is still observable and can be manipulated by an attacker. This is why sites should preferably use HTTPS for the entire site.

HTTP Strict Transport Security (HSTS) is a response policy that tells a browser to use HTTPS for a site and to avoid downgrading to HTTP during the policy period. Enable HSTS only after every required hostname, page, redirect, and subresource works correctly over HTTPS. An overly broad or long policy can make recovery difficult after configuration errors.

Mixed content occurs when an HTTPS page loads a resource through HTTP. Scripts, stylesheets, images, fonts, frames, and API calls may be blocked or warned about. Update all resource and integration URLs to HTTPS, including third-party dependencies.

Secure Cookies

Secure causes a cookie to be sent only over HTTPS.
HttpOnly prevents client-side scripts from reading the cookie, reducing some session-theft opportunities.
SameSite controls when browsers send cookies in cross-site contexts and helps reduce certain cross-site request risks.

These attributes complement HTTPS; they do not replace server-side session controls, input validation, or application security.

Inspection, Proxies, and Enterprise Networks

Because HTTPS encrypts application payloads, a conventional router, switch, or passive packet capture generally cannot read HTTP methods, bodies, cookies, or response content after TLS setup. A capture can still show connection addresses, ports, timing, sizes, TCP behavior, and visible handshake metadata.

TLS may terminate at a reverse proxy, load balancer, content delivery network, or web application firewall. That intermediary presents the public certificate and decrypts the client session. It can then forward requests to an application server over a separate protected or controlled internal connection. Operators must decide whether internal traffic also requires TLS.

In outbound enterprise TLS interception, a security gateway creates one TLS session with the managed client and another with the external website. The organization installs an inspection CA certificate in managed client trust stores so the gateway-generated certificates are accepted. This enables policy enforcement and malware inspection, but it also creates privacy concerns, adds operational complexity, requires careful protection of the inspection CA private key, and can interfere with certificate pinning or sensitive applications. Users and administrators should understand the organization's authorization and data-handling policies.

Practical HTTPS Examples

Opening an Online Banking Site

The browser resolves the site's name and connects to TCP port 443.
The site presents a certificate for its domain.
The browser validates the certificate chain, hostname, dates, and trust.
The TLS handshake establishes session keys.
Login credentials and other HTTP data are sent only after protection is active.

Diagnosing a Hostname Mismatch

If a user visits https://store.example.com but the server presents a certificate valid only for www.example.com, hostname validation fails. The browser displays a warning because the certificate does not authenticate the requested identity. A wrong virtual host or missing SNI handling can cause the same symptom.

HTTP-to-HTTPS Migration

A web server can redirect port-80 requests to equivalent HTTPS URLs, then enable HSTS after confirming that all pages, APIs, cookies, and embedded resources work securely. Test every hostname before applying a strict policy.

Load-Balancer Termination

A public load balancer can present the certificate and terminate the client TLS session. It forwards requests to internal application servers. The internal hop should use HTTPS or another controlled protection when its network, data sensitivity, or threat model requires it.

Verification and Troubleshooting

Start with the browser's lock or connection indicator and open its certificate viewer. Inspect the subject alternative names, issuer, validity period, chain, and connection protocol. A browser indicator confirms a validated connection, not that the site's content is trustworthy.

curl -I https://example.com

Use this command to retrieve HTTPS response headers.

curl -v https://example.com

Verbose output shows DNS activity, connection details, TLS negotiation, certificate information, and HTTP headers.

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

This inspects the certificate chain and negotiated TLS connection. The -servername option is important when SNI selects the virtual host.

nc -vz example.com 443

This tests basic TCP reachability to port 443; a successful TCP test does not prove that TLS or HTTP is correctly configured.

nmap --script ssl-enum-ciphers -p 443 example.com

Use cipher enumeration only on systems you own or are authorized to test. It identifies supported TLS versions and cipher choices.

Expired certificate: The certificate validity period ended. Verify dates with a browser or OpenSSL, renew it, deploy the new chain, and automate future renewal.

Hostname mismatch: The requested name is absent from SAN, or the wrong virtual host was selected. Compare the URL with SAN entries and test SNI using OpenSSL.

Untrusted issuer: The certificate is self-signed or issued by a private CA not in the client trust store. Install the intended private trust anchor on managed clients or use an appropriate publicly trusted issuer.

Missing intermediate certificate: The server sends its own certificate but not the required intermediate. Configure the complete server chain.

Server clock issue: Incorrect server or client time makes a valid certificate appear expired or not yet valid. Verify NTP and local clock settings.

Unsupported TLS version or cipher: Client and server have no compatible modern parameters. Review verbose negotiation output and configure compatible TLS 1.2 or TLS 1.3 policies.

Common Failure Workflows

Not trusted: Inspect the issuer and chain. Confirm the required root is trusted and intermediates are sent by the server.
Name mismatch: Compare the requested DNS name with SAN entries. Test the expected SNI name and verify virtual-host certificate bindings.
Service unreachable: Check DNS resolution, TCP port 443, firewall rules, listening sockets, routes, and NAT.
Handshake failure: Use curl -v or openssl s_client to identify protocol, cipher, certificate, key, or middlebox problems. Test another client or network path.
Mixed content: Use browser developer tools to find HTTP resource requests and change application and third-party URLs to HTTPS.
Expired or not-yet-valid certificate: Check certificate dates and NTP on both endpoints, then renew and deploy the correct certificate if needed.

In a packet capture, TCP setup and TLS handshake messages are visible, but application payloads generally appear as encrypted records after TLS setup. A capture cannot normally display readable HTTP content unless the analyst has an authorized decryption method or captures traffic at a TLS termination point.

See Configure NTP on a Cisco Device for the time-synchronization concepts that affect certificate validation.

HTTPS Security Best Practices

Require HTTPS for authentication, payments, session management, APIs, and other sensitive functions; preferably use it for the entire site.
Use valid certificates from an appropriate trusted issuer and include the complete intermediate chain.
Protect private keys with restrictive permissions, secret storage, access controls, backups, and monitoring.
Enable TLS 1.2 and TLS 1.3, favor modern authenticated-encryption suites, and disable SSL, TLS 1.0, TLS 1.1, weak suites, and deprecated hashes.
Automate certificate renewal and monitor expiration before service impact.
Use HSTS carefully after confirming complete HTTPS readiness.
Do not load insecure third-party resources, and do not train users to ignore certificate warnings.
Secure internal TLS termination and forwarding paths according to the sensitivity of the data and the trust boundaries involved.

Exam-Relevant Notes

HTTPS is HTTP over TLS; traditional HTTPS commonly uses TCP port 443, while HTTP commonly uses TCP port 80.
TLS provides confidentiality, server authentication, and integrity. Client-certificate authentication is optional.
The certificate hostname must match the requested hostname, normally through SAN entries.
A certificate chain commonly runs from the server certificate through an intermediate CA to a trusted root in the client trust store.
Asymmetric cryptography authenticates and establishes secrets; symmetric cryptography protects bulk data efficiently.
Ephemeral Diffie-Hellman provides forward secrecy when used correctly.
SNI helps one IP address host multiple TLS names.
HTTPS does not make a website's content trustworthy; it protects the connection to an authenticated domain.
HTTP/3 uses QUIC over UDP with TLS 1.3 integrated.