HTTPS Best Practices

HTTPS is the secure version of HTTP. It protects communication between a client and a server by using TLS to provide encryption, authentication, and integrity. For modern websites and APIs, HTTPS is not an optional performance or security enhancement. It is a fundamental part of a secure deployment.

However, simply installing a certificate does not guarantee that an HTTPS configuration is secure. TLS versions, certificate chains, redirects, private-key protection, protocol settings, HTTP headers, renewal procedures, and application behavior all affect the security and reliability of an HTTPS deployment.

This guide covers practical HTTPS best practices for websites, APIs, and other web services. The goal is to understand what should be configured, what should be avoided, and how to verify that a deployment is working as intended.

HTTPS Best Practices at a Glance

What HTTPS Actually Provides

HTTPS combines HTTP with TLS. TLS establishes cryptographic protections for the connection before HTTP application data is exchanged.

HTTPS does not automatically make the application secure. If an application has a broken authorization check, SQL injection vulnerability, weak password-reset process, or compromised server, TLS does not fix those problems.

Use TLS, Not Plain HTTP

Public websites and APIs should use HTTPS rather than sending sensitive or authenticated traffic over plaintext HTTP. HTTP traffic can be observed or modified by an attacker positioned on the network path.

HTTP
http://example.com
    ↓
plaintext connection

HTTPS
https://example.com
    ↓
TLS-protected connection

Even pages that do not appear to contain sensitive information benefit from HTTPS because modern web applications commonly use authenticated requests, browser APIs, secure cookies, and third-party services that depend on a secure context.

Use Modern TLS Versions

Modern HTTPS deployments should use current TLS protocol versions and avoid obsolete protocols. TLS 1.2 and TLS 1.3 are the important modern versions to consider, while TLS 1.0 and TLS 1.1 are obsolete and should not be enabled for modern deployments.

TLS 1.3 simplifies parts of the protocol and removes several older cryptographic mechanisms. TLS 1.2 remains important because some clients and infrastructure still depend on it.

Prefer TLS 1.3 When Supported

TLS 1.3 should generally be enabled on modern systems because it provides a cleaner protocol design and removes many legacy cryptographic options. It also reduces the number of round trips required during the handshake in common cases.

There is usually no reason to disable TLS 1.3 simply because TLS 1.2 is also enabled. Supporting both can provide compatibility with clients that do not yet support TLS 1.3.

Use a Valid TLS Certificate

A TLS certificate binds a public key to an identity such as a domain name. Browsers and other clients use certificates and certificate chains to determine whether they can trust the server identity.

A certificate used by a public website should be issued by a certificate authority trusted by the intended clients and should contain the correct hostname in its Subject Alternative Name extension.

Subject Alternative Name Matters

Modern hostname verification relies on the Subject Alternative Name extension rather than the legacy Common Name field alone. A certificate should therefore explicitly contain the hostnames it is intended to protect.

Subject Alternative Name:

DNS: example.com
DNS: www.example.com

If a user visits www.example.com but the certificate only covers example.com, hostname verification can fail even if both names belong to the same organization.

Serve the Complete Certificate Chain

A common HTTPS configuration problem is serving only the site's leaf certificate while omitting the required intermediate certificate. Browsers may be able to recover by obtaining missing intermediates in some situations, but servers should provide the appropriate chain rather than relying on clients to reconstruct it.

Server certificate
Intermediate CA
Root CA trust

The root certificate is normally already present in the client's trust store and does not generally need to be sent by the server. The server typically provides its own certificate followed by the required intermediate certificates.

Do Not Send the Root Certificate Unnecessarily

A server generally does not need to send the root CA certificate as part of the TLS certificate chain. Clients are expected to have trusted root certificates in their trust stores.

Sending unnecessary certificates increases the handshake payload and can indicate that the chain configuration was assembled without understanding which certificates the server should provide.

Protect the Private Key

The private key corresponding to a TLS certificate must remain secret. Anyone who obtains the private key may be able to impersonate the server or otherwise undermine the trust relationship associated with the certificate, depending on the environment and remaining controls.

• Restrict filesystem permissions.
• Do not commit private keys to source control.
• Do not put private keys in frontend code or public files.
• Avoid exposing private keys through logs or backups.
• Use appropriate secret-management infrastructure.
• Rotate compromised keys and certificates promptly.
• Consider hardware-backed key protection for high-security environments.

Use Strong Certificate Keys

Certificate key type and parameters should meet current security requirements and the compatibility needs of the target clients. Common choices include RSA and elliptic-curve keys.

ECC can provide strong classical security with significantly smaller keys than RSA. RSA remains widely supported and can still be appropriate when compatibility or infrastructure requirements call for it.

The important point is to use current, supported parameters rather than obsolete key sizes or algorithms.

Use Modern Signature Algorithms

The certificate's signature algorithm and the algorithms used during TLS authentication should be appropriate for modern cryptographic requirements. Older hash functions and obsolete signature schemes should not be selected for new deployments.

The exact algorithms available depend on the certificate authority, TLS version, key type, client compatibility, and server software. Avoid choosing an algorithm simply because it appears in an old configuration guide.

Redirect HTTP to HTTPS

If a website supports both HTTP and HTTPS, HTTP requests should generally be redirected to the HTTPS version. This provides a clear migration path for users who enter an HTTP URL.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

The redirect itself does not encrypt the initial HTTP request. This is why HSTS can provide an additional layer by instructing compatible browsers to use HTTPS without first making an HTTP request after the policy has been learned.

Be Careful With Redirects

The HTTPS redirect should not create loops, redirect to unexpected hosts, or accidentally expose sensitive query parameters to third-party destinations. Verify both the HTTP and HTTPS versions of the site and test common URL patterns.

Applications behind reverse proxies should also correctly understand the original protocol. Misconfigured proxy headers can cause applications to believe a request is HTTP even when the client connected over HTTPS, potentially resulting in redirect loops or incorrect secure-cookie behavior.

Enable HSTS Carefully

HTTP Strict Transport Security tells compatible browsers to use HTTPS for a domain for a specified period. A typical policy might look like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS should be enabled only after HTTPS is correctly configured. includeSubDomains should be used only when the relevant subdomains are also ready for HTTPS-only access.

Consider HSTS Preloading Separately

HSTS preload lists allow participating browsers to know that a domain should use HTTPS before the browser has received an HSTS response from that domain.

Preloading can strengthen HTTPS-only behavior, but it also makes configuration mistakes harder to recover from. Treat it as a long-term operational commitment rather than simply another HTTP header setting.

Prevent Mixed Content

Mixed content occurs when an HTTPS page loads resources over insecure HTTP. Examples include scripts, stylesheets, images, fonts, frames, or API connections that still use http:// URLs.

<script src="http://example.com/app.js"></script>

Modern browsers block many forms of active mixed content automatically, while some passive content may be upgraded or handled differently. The safest approach is to make all application resources HTTPS-compatible and use HTTPS URLs consistently.

Use Secure Cookies

Authentication and session cookies should normally use the Secure attribute so browsers send them only over HTTPS.

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax

Secure works together with HttpOnly and SameSite. Secure protects transport, HttpOnly limits JavaScript access, and SameSite controls cross-site cookie behavior.

HTTPS Does Not Replace Authentication

TLS authenticates the server's identity to the client through the certificate system, but it does not determine whether a user is authorized to access an application resource.

An HTTPS application still needs secure authentication, authorization, session management, password storage, access controls, and account recovery. Encryption protects the connection; it does not decide what an authenticated user is allowed to do.

HTTPS Does Not Prevent Server-Side Vulnerabilities

HTTPS cannot prevent SQL injection, insecure deserialization, broken access control, vulnerable dependencies, command injection, or other server-side vulnerabilities. It protects communication between endpoints, not the correctness of the application itself.

A secure deployment therefore combines HTTPS with application security, secure infrastructure, dependency management, logging, monitoring, and appropriate defensive controls.

Automate Certificate Renewal

Certificate expiration is one of the most avoidable causes of HTTPS outages. Modern deployments should automate certificate issuance and renewal whenever the infrastructure allows it.

Automation reduces the chance that a certificate will expire because someone forgot a calendar reminder. The renewal process should also be monitored so that failed renewals are detected before the existing certificate expires.

Monitor Certificate Expiration

Do not rely exclusively on the certificate authority's renewal system. Monitor the certificate actually served by the production endpoint.

This matters because a certificate can be renewed successfully while the web server continues serving an older certificate due to a deployment, reload, proxy, CDN, or configuration problem.

Verify the Certificate Chain

Certificate validation is based on a chain of trust. The server's certificate is normally issued by an intermediate CA, which chains to a trusted root CA.

Root CA
  ↓
Intermediate CA
  ↓
Server certificate
  ↓
Hostname

A Certificate Chain Viewer can help inspect the certificates involved in a chain and identify missing, unexpected, or incorrectly ordered certificates.

Inspect Certificates Before Deployment

PEM files can contain certificates, private keys, CSRs, and other cryptographic material. Before deploying a certificate, verify that you are using the intended certificate and that its fields match the service.

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

A PEM Certificate Viewer can make it easier to inspect subjects, issuers, validity periods, public keys, extensions, and other certificate metadata.

Use CSRs Correctly

A Certificate Signing Request contains a public key and identity information that is submitted to a certificate authority. The corresponding private key remains under the control of the requester.

Private key
    ↓
CSR
    ↓
Certificate Authority
    ↓
Certificate

The private key should never be sent to the certificate authority merely because a CSR is being requested. The CSR is signed with the private key, allowing the authority to verify proof of possession without receiving the private key itself.

Use Appropriate TLS Cipher Suites

Cipher suite configuration matters primarily for TLS versions where cipher suites expose meaningful choices. TLS 1.3 significantly simplifies this compared with TLS 1.2.

Modern configurations should avoid obsolete algorithms and suites that depend on deprecated cryptographic primitives. The exact list should follow current recommendations for the server software and clients being supported rather than an old static configuration copied from a tutorial.

Avoid Obsolete Cryptography

• Do not enable SSL 2.0 or SSL 3.0.
• Do not enable TLS 1.0 or TLS 1.1 for modern deployments.
• Avoid obsolete weak cipher suites.
• Avoid deprecated hash algorithms for new cryptographic configurations.
• Avoid unnecessarily small RSA keys.
• Do not use expired or revoked certificates.
• Do not reuse private keys unnecessarily across unrelated services.

Use Forward Secrecy

Forward secrecy means that compromise of a long-term private key should not allow an attacker to decrypt previously recorded sessions, assuming the protocol and configuration provide the necessary properties.

Modern TLS commonly achieves this through ephemeral Diffie-Hellman key exchange, such as ECDHE. TLS 1.3 uses ephemeral key exchange as part of its design.

This is another reason not to interpret an RSA certificate as meaning that the entire TLS connection uses RSA encryption. The certificate and ephemeral session key exchange can use different cryptographic mechanisms.

Use HTTPS Everywhere in the Application

Secure only the login page is not enough. If other pages contain authenticated sessions, personal information, API requests, or user-generated content, they should also be served through HTTPS.

Modern applications should normally use HTTPS for the entire site rather than switching between HTTP and HTTPS depending on whether a page appears sensitive.

HTTPS for APIs

APIs should also use HTTPS. API requests commonly contain credentials, access tokens, personal data, application data, or other information that should not travel over plaintext connections.

POST /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Content-Type: application/json

The Authorization header and request body are protected by TLS while the connection is established securely. HTTPS does not remove the need to protect tokens from application logs, URLs, client-side exposure, or compromised endpoints.

Do Not Put Secrets in URLs

HTTPS encrypts URLs while they travel between the client and server, but URLs can still appear in browser history, logs, analytics systems, proxies, monitoring systems, and referrer-related contexts.

Sensitive credentials, API keys, access tokens, and passwords should therefore not be placed in query parameters or URL paths unless a specific protocol requires it and the risks have been addressed.

Configure Security Headers Alongside HTTPS

HTTPS is stronger when combined with appropriate HTTP security headers. HSTS is directly related to HTTPS enforcement, while headers such as Content-Security-Policy, Referrer-Policy, X-Content-Type-Options, and Permissions-Policy provide additional browser-level protections.

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Each header should be configured according to the application's requirements. Security headers should not be copied blindly because restrictive policies can break legitimate functionality.

HTTPS Behind a Reverse Proxy or CDN

Many modern applications terminate TLS at a reverse proxy, load balancer, or CDN rather than directly at the application server. In that architecture, it is important to understand which component handles the certificate and where encrypted connections begin and end.

The application should correctly understand the original request scheme when necessary. Incorrect proxy configuration can cause HTTPS redirect loops, insecure-cookie issues, incorrect absolute URLs, or security checks that behave unexpectedly.

If traffic is encrypted between the browser and CDN but then travels over plaintext HTTP from the CDN to the origin, the security properties of the complete path are different from end-to-end TLS. For sensitive systems, the origin connection should also be evaluated and secured appropriately.

Test HTTPS After Deployment

HTTPS configuration should be tested from the perspective of a real client. A configuration file can look correct while the production endpoint serves a different certificate, supports an unexpected TLS version, or omits an intermediate certificate.

• Verify the certificate hostname.
• Check the certificate expiration date.
• Inspect the certificate chain.
• Check supported TLS versions.
• Verify the HTTP-to-HTTPS redirect.
• Check for mixed content.
• Verify secure cookies.
• Inspect important security headers.
• Test API endpoints over HTTPS.
• Test redirects and error pages.
• Test from representative client platforms.

Test With Command-Line Tools

Command-line tools can provide a quick view of the HTTPS connection and are useful for troubleshooting. For example, curl can show response headers and redirects.

curl -I https://example.com

curl -I http://example.com

The first request can confirm the HTTPS response, while the second can show whether HTTP is redirected to the intended HTTPS URL.

Check Certificate Expiration Regularly

Certificate expiration should be monitored continuously rather than checked only when a certificate is initially installed. The certificate currently served by the production endpoint is the one that matters to users.

A useful monitoring system can alert at multiple intervals before expiration. This gives the team time to investigate renewal failures, DNS problems, deployment errors, certificate authority issues, or unexpected changes.

Renewal Is Not the Same as Deployment

A certificate authority can issue a new certificate successfully while the production server continues using the previous certificate. Renewal automation should therefore be followed by deployment and verification steps.

This is especially important when certificates are managed by separate systems such as a CDN, load balancer, Kubernetes ingress, reverse proxy, or cloud platform.

Common HTTPS Mistakes

• Allowing obsolete TLS versions.
• Using an expired certificate.
• Using a certificate that does not cover the requested hostname.
• Serving an incomplete certificate chain.
• Sending the root certificate unnecessarily.
• Exposing the private key.
• Forgetting to renew certificates.
• Renewing a certificate but failing to deploy it.
• Serving mixed HTTP and HTTPS content.
• Redirecting HTTP incorrectly.
• Failing to configure secure cookies.
• Putting access tokens or other secrets in URLs.
• Assuming HTTPS replaces authentication and authorization.
• Ignoring TLS configuration behind a CDN or reverse proxy.
• Using outdated cryptographic configurations from old tutorials.
• Enabling HSTS before all required services support HTTPS.

A Production HTTPS Checklist

• Use HTTPS for the complete application.
• Support TLS 1.3 and, where necessary, TLS 1.2.
• Disable obsolete SSL and TLS versions.
• Use a certificate issued for the correct hostnames.
• Verify the certificate's validity period.
• Serve the required intermediate certificates.
• Protect the certificate's private key.
• Use current RSA or ECC key parameters.
• Use appropriate modern signature and cryptographic algorithms.
• Redirect HTTP requests to HTTPS.
• Enable HSTS after verifying HTTPS readiness.
• Consider HSTS preload only after meeting its operational requirements.
• Eliminate mixed content.
• Use Secure cookies for HTTPS session cookies.
• Use appropriate HttpOnly and SameSite cookie settings.
• Avoid placing secrets in URLs.
• Use forward-secret TLS configurations.
• Automate certificate renewal.
• Monitor the certificate actually served by production.
• Test TLS versions and certificate chains regularly.
• Review HTTPS configuration after infrastructure changes.

HTTPS and Web Performance

The overhead of establishing a secure connection is much smaller than it was in the early days of HTTPS. Modern TLS versions, persistent connections, HTTP/2, HTTP/3, session resumption, and connection reuse make HTTPS practical for essentially all modern web applications.

HTTPS should therefore not be disabled for performance reasons. If a website has performance problems, optimize the actual bottleneck rather than removing transport security.

HTTPS and HTTP/2 or HTTP/3

Modern HTTP versions are designed to work closely with secure transport. HTTP/2 is widely deployed with TLS, while HTTP/3 uses QUIC, which incorporates TLS 1.3 into its connection establishment.

The application does not need to choose between HTTPS and modern HTTP versions. HTTPS is the security layer, while HTTP/2 and HTTP/3 define different transport and request/response behavior above or alongside TLS.

HTTPS Is Not the Same as a Certificate

A certificate is one component of an HTTPS deployment. HTTPS also depends on the TLS protocol, cryptographic parameters, server configuration, certificate validation, private-key protection, and correct application behavior.

This distinction is useful when troubleshooting. A website can have a valid certificate and still have an outdated TLS configuration, an incomplete chain, weak redirects, mixed content, or insecure cookie settings.

Frequently Asked Questions

Helpful HTTPS Tools

A TLS Version Checker can help determine which TLS protocol versions a server supports. A Certificate Expiration Checker is useful for checking certificate validity periods, while a Certificate Chain Viewer can help inspect the trust chain and identify missing intermediate certificates. A PEM Certificate Viewer can expose certificate metadata such as the issuer, subject, validity dates, and public key. A CSR Generator can help create certificate signing requests when obtaining or replacing a TLS certificate.

Conclusion

A secure HTTPS deployment involves much more than obtaining a certificate. Use modern TLS versions, select appropriate cryptographic parameters, protect private keys, serve the correct certificate chain, redirect HTTP traffic appropriately, eliminate mixed content, configure secure cookies, and automate certificate renewal.

HSTS and other security headers can provide additional browser-level protection, while monitoring and regular testing help detect expired certificates, incomplete chains, obsolete protocol support, and configuration changes.

The most reliable approach is to treat HTTPS as part of the entire application's security and deployment process. Verify the configuration from the client's perspective, automate what can be automated, monitor what can fail, and review TLS settings whenever the infrastructure or supported clients change.