HTTPS is the encrypted version of HTTP that protects data between browsers and servers. It relies on TLS certificates issued by trusted certificate authorities. This guide explains how HTTPS works under the hood, the different certificate types, deployment best practices, and how to manage HTTPS certificates at enterprise scale.
HTTPS (HyperText Transfer Protocol Secure) is the encrypted version of HTTP, the protocol used to transfer data between a web browser and a website. HTTPS uses TLS (Transport Layer Security) to encrypt the connection, ensuring that data cannot be read or tampered with in transit.
When you see the padlock icon in your browser's address bar, it means the connection between your device and the server is encrypted using HTTPS. The server has presented a digital certificate issued by a trusted certificate authority (CA), and your browser has verified it.
HTTPS was originally reserved for sensitive pages like banking and login forms. Today, it's the default for the entire web. Since 2018, Google Chrome marks all HTTP sites as "Not Secure," and search engines penalize unencrypted sites in rankings. Over 95% of web traffic now uses HTTPS.
| HTTP | HTTPS | |
|---|---|---|
| Encryption | None (plaintext) | TLS encryption |
| Authentication | No server identity proof | Certificate verifies server identity |
| Data integrity | Can be tampered in transit | Tamper-proof (MAC verification) |
| Default port | 80 | 443 |
| SEO impact | Penalized by Google | Ranking boost |
| Performance | No HTTP/2 support | HTTP/2 and HTTP/3 require TLS |
Key takeaway: HTTPS is not just about encryption. It provides authentication (proving the server is who it claims to be) and integrity (detecting any modification during transit). All three are essential for secure communication.
Before any application data flows, the client and server perform a TLS handshake to establish an encrypted session. In TLS 1.3, this has been streamlined to just three steps.
The client sends a ClientHello message containing its supported TLS versions, cipher suites, and a random value. In TLS 1.3, the client also sends key shares for anticipated key exchange groups, speeding up the process.
The server responds with its chosen cipher suite, its own key share, and its certificate chain. The client verifies the certificate against its trust store, checks the Subject Alternative Name matches the requested domain, and validates the signature chain up to a trusted root CA.
Both sides derive the shared session keys from the key exchange. The client sends a Finished message encrypted with the new keys. Application data can now flow. In TLS 1.3, this entire process takes just 1 round trip (1-RTT), down from 2 round trips in TLS 1.2.
Not all HTTPS certificates are the same. They differ in the level of identity validation performed by the certificate authority and in how many domains they cover.
Verifies domain ownership only. Issued in minutes via automated validation (HTTP-01, DNS-01). Used by most automated issuance workflows. Lowest cost, no organization info displayed.
Verifies both domain ownership and the legal existence of the organization. Takes 1 to 3 business days. The organization name appears in the certificate's Subject field. Common for business websites.
The highest level of validation. Requires extensive verification of the organization's legal, physical, and operational existence. No longer shows the green bar in browsers, but still provides the strongest identity assurance.
Wildcard certificates (*.example.com) cover all subdomains. SAN certificates list multiple specific domains. Both reduce the number of certificates to manage.
Deploying HTTPS is more than just installing a certificate. A production-grade deployment involves several configuration steps to maximize security and performance.
Generate a CSR, submit it to a CA, and install the returned certificate along with the full chain (intermediates + root). Configure your web server to reference the private key and certificate files.
HTTP Strict Transport Security tells browsers to always use HTTPS. Add the header: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. This prevents protocol downgrade attacks.
Configure a 301 permanent redirect from all HTTP URLs to their HTTPS equivalents. This ensures no traffic flows over unencrypted connections and preserves SEO link equity.
Ensure all resources (images, scripts, stylesheets, fonts, APIs) are loaded over HTTPS. A single HTTP resource on an HTTPS page triggers a "mixed content" browser warning and can break functionality.
TLS 1.3 (RFC 8446, published in 2018) is a major overhaul of the TLS protocol. It's faster, simpler, and more secure than TLS 1.2. All modern browsers and servers support it, and it should be the default for any new deployment.
TLS 1.3 completes the handshake in a single round trip, compared to two in TLS 1.2. For returning clients, 0-RTT resumption allows sending application data in the very first message, reducing latency to near-zero for repeat connections.
TLS 1.3 dropped support for RSA key exchange, CBC mode ciphers, RC4, SHA-1, MD5, DES, and 3DES. Only AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) remain. This eliminates entire categories of historical attacks like BEAST, POODLE, and Lucky13.
Every TLS 1.3 connection uses ephemeral Diffie-Hellman key exchange, providing perfect forward secrecy. Even if the server's private key is compromised later, past session data remains protected.
The most common cause of HTTPS outages. An expired certificate triggers a full-page browser warning that most users cannot bypass. With 47-day lifespans, manual tracking is no longer viable.
Loading HTTP resources on an HTTPS page. Browsers block mixed active content (scripts, iframes) entirely and may warn about mixed passive content (images). Audit all resource URLs and use protocol-relative or HTTPS URLs.
The certificate's SAN doesn't match the requested domain. Common when the bare domain (example.com) is missing from a certificate that only covers www.example.com.
Allowing TLS 1.0/1.1, RC4, or export-grade ciphers makes your server vulnerable to known attacks. Disable everything below TLS 1.2 and prefer TLS 1.3 cipher suites. Use tools like SSL Labs to verify your configuration.
A single website needs one certificate. An enterprise runs hundreds or thousands of HTTPS endpoints across web servers, load balancers, CDNs, APIs, and microservices. Managing certificates at this scale requires a fundamentally different approach.
With the CA/Browser Forum mandating 47-day maximum validity for TLS certificates, every HTTPS certificate must be renewed roughly 8 times per year. For an organization with 5,000 certificates, that's 40,000 renewal operations annually. Manual processes collapse at this volume.
The ACME protocol enables fully automated certificate issuance and renewal. Clients like certbot, cert-manager, and acme.sh handle the entire lifecycle without human intervention. Use the TLS Renewal Calculator to estimate your renewal workload.
Use certificate lifecycle management to monitor all HTTPS certificates from a single dashboard. Set up alerts for certificates expiring within 14 days, 7 days, and 1 day. Detect certificates using deprecated algorithms or weak key sizes.
Know which certificates are deployed where, so that if a key compromise occurs, you can revoke and replace affected certificates quickly. Discovery and inventory are prerequisites for effective incident response.
Automated HTTPS certificate issuance: Evertrust PKI issues TLS certificates via ACME, REST API, and other protocols. Certificates renew automatically, keeping your HTTPS endpoints secure without manual intervention.
Complete HTTPS visibility: Evertrust CLM discovers every HTTPS certificate across your infrastructure, from public-facing websites to internal APIs. Get alerts before any certificate expires.
47-day ready: With native ACME support and automated lifecycle management, Evertrust ensures your organization is prepared for the new short-lived certificate era. No more renewal firefighting.
