SSL best practices: how to configure HTTPS the right way

Most teams treat SSL as a solved problem. You buy a certificate, install it and move on. Then a certificate expires on a Saturday, every visitor hits a full-page browser warning and your signup form sits untouched until someone notices on Monday. Or a security scanner flags a weak protocol you didn’t know was still enabled and a procurement review stalls a deal you were about to close.

Having a certificate and configuring SSL correctly are two different things. A valid certificate proves nothing on its own. The connection can still accept a broken protocol. Half your pages can still load over plain HTTP. A redirect in the path can still drop the encryption.

This guide covers what keeps HTTPS reliable: the right certificate, a solid connection config, HTTPS on every path, a managed certificate lifecycle and clean redirects.

A quick note on SSL vs TLS

SSL is the term everyone still searches for, but the protocol behind it is TLS. SSL 2.0 and SSL 3.0 are both dead and insecure. The live protocol is TLS, currently TLS 1.2 and TLS 1.3. Throughout this guide, "SSL" refers to the certificate and the encrypted connection in the everyday sense and "TLS" refers to the specific protocol version you configure.

Choose the right certificate for the job

Before you configure anything, pick a certificate that matches how your site is structured.

Validation level. Domain Validation (DV) confirms you control the domain and issues in minutes. Organization Validation (OV) and Extended Validation (EV) add vetting of the business behind the site. For most sites, DV is enough, since modern browsers no longer give EV certificates a visible trust cue in the address bar. Reach for OV or EV only when a compliance requirement or a specific customer expectation calls for it.

Coverage. A single-domain certificate covers one hostname. A wildcard certificate (*.example.com) covers every single-label subdomain, but not the apex domain itself and not deeper names such as a.b.example.com, so most wildcard deployments still list the apex as an explicit SAN. It is convenient, but concentrates risk in one key. A multi-domain (SAN) certificate covers a specific list of hostnames. Match the coverage to what you actually serve rather than defaulting to a wildcard for everything.

Key type and strength. Use RSA 2048-bit or larger or an ECDSA P-256 key. ECDSA keys are smaller and faster and are a good default for new setups.

Lock down who can issue. Add a CAA record to your DNS so only the certificate authorities you approve can issue certificates for your domain. It is a small DNS entry that closes off a whole category of misissuance.

Configure the connection properly

A valid certificate on a badly configured server still fails a security review. This is where most weak SSL grades come from.

Enable modern protocols only. Serve TLS 1.3 as your primary protocol and keep TLS 1.2 as a fallback for older clients. Disable SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1. TLS 1.0 and 1.1 were formally deprecated by the IETF in RFC 8996 in March 2021 and every major browser had already disabled them by default during 2020, with the enterprise policies that allowed re-enabling them removed the following year.

A server that still accepts them keeps the TLS 1.0 CBC weaknesses that BEAST exploits reachable for any client willing to negotiate down to it and it fails PCI DSS and most security reviews on sight. Modern browsers no longer perform insecure version fallback, so the practical exposure is older clients, API consumers and embedded software rather than a current Chrome or Firefox. POODLE itself is an SSL 3.0 flaw, which is another reason SSL 3.0 has to stay off.

Use strong cipher suites only. Stick to authenticated encryption (AEAD) cipher suites: AES-128-GCM, AES-256-GCM and ChaCha20-Poly1305. AES-128-GCM is not the weak option here and it is what most clients negotiate when hardware AES support is available. Use ECDHE key exchange so every session gets forward secrecy, which means an attacker who later steals your server's private key still cannot decrypt traffic captured before the theft. Remove RC4, 3DES, CBC-mode and any export-grade or NULL ciphers.

Enable OCSP stapling only if your CA still supports it. Stapling lets your server present a fresh proof that the certificate has not been revoked instead of sending each visitor's browser off to check separately, which speeds up the handshake and avoids a privacy leak. The ecosystem is moving away from it: the CA/Browser Forum has made OCSP optional and CRLs mandatory and Let's Encrypt dropped OCSP URLs from its certificates in May 2025 and shut down its responders in August 2025. If your certificates carry no OCSP URL, turn the directive off rather than leaving it to log warnings on every reload.

Enforce HTTPS everywhere

Serving HTTPS is not the same as requiring it. If a page still answers on plain HTTP, an attacker on the same network can intercept that first request before any redirect fires.

Redirect all HTTP traffic to HTTPS.

Send every HTTP request to its HTTPS equivalent with a 301 redirect. A 301 is permanent, so browsers and search engines cache it and stop requesting the insecure version.

Handle your apex and www versions consistently.

Pick one canonical host, either the apex (example.com) or www (www.example.com) and redirect the other to it. Do this in addition to the HTTP to HTTPS redirect, not instead of it. The common failure is fixing the protocol but leaving two live hostnames competing, which splits SEO signals and leaves an HSTS hole. Browsers cache HSTS policy per host, so a header served only from www.example.com does nothing for a first request to example.com and includeSubDomains on the www host does not reach the apex above it. Serve the header from both hostnames or set it on the apex with includeSubDomains.

Every hostname in the path needs its own valid certificate.

The destination has to present a certificate covering the exact hostname you send visitors to and the redirecting host needs one too for any request that arrives over HTTPS, which is every request once HSTS is in effect. Redirecting to a host whose certificate does not match moves the browser warning one hop down the line and a redirecting host with no certificate of its own throws the warning before the redirect is even sent.

Add HSTS once enforcement is solid.

The HTTP Strict Transport Security header tells browsers to refuse plain HTTP for your domain for a set period, closing the gap on that very first request. Start with a short max-age, confirm nothing breaks, then raise it. Only submit your domain to the HSTS preload list once you are certain every subdomain can serve HTTPS, because preloading is hard to reverse.

Across a large or migrating site, applying these rules by hand gets unreliable fast. urllo keeps HTTPS enforcement and canonical host rules consistent across every path, including through a migration.

"We needed to securely redirect our domain apex to our www subdomain. urllo's team was great to deal with and their automatic SSL certificate provisioning and renewal is awesome! We can set it and forget it!"

- Alyssa Jeffers, Marketing Manager, Pure Power Engineering

Manage the certificate lifecycle

An expired certificate is the single most common cause of an SSL outage and it is entirely preventable.

Automate renewal. Use the ACME protocol, through Let's Encrypt or another provider that supports it, so certificates renew and deploy without anyone touching them. Manual renewal is a calendar reminder waiting to be missed.

Automation is no longer optional, because certificate lifetimes are already shrinking. In April 2025, the CA/Browser Forum approved Ballot SC-081v3, which cuts the maximum validity of a publicly trusted TLS certificate from 398 days to 47 days on a phased schedule:

• 200 days, in force since March 15, 2026.
• 100 days, from March 15, 2027.
• 47 days, from March 15, 2029.

The period during which domain validation can be reused shrinks alongside it, down to 10 days by 2029, so most renewals will need to revalidate domain control each time. A 47-day lifetime is under seven weeks and since you renew ahead of expiry rather than at it, the real cadence lands closer to every four or five weeks, which no team can sustain by hand.

Track expiry and set alerts. Even with automation, monitor the actual certificates your domains are serving and alert well before expiry. Automation fails quietly sometimes and the alert is what saves you.

Plan for rotation and revocation. Know how you would rotate a key or revoke a certificate if one is compromised, before you need to.

Watch for redirect chains and mixed content

This is where a technically valid certificate still produces a broken or insecure experience and it is the easiest problem to miss because the final page looks fine.

Broken links in a redirect chain.

When a request passes through several redirects before reaching its destination, every hop has to stay on HTTPS with a valid certificate. If one link in the chain drops to HTTP or serves a certificate that does not match, the whole path is exposed at that point, even though the page the visitor lands on is perfectly secure. Long chains also slow the page down, since each hop is another round trip before the browser sees any content and they cost crawl efficiency. Since Google's documentation says Googlebot follows up to 10 hops in a chain and advises keeping chains to no more than three , ideally fewer than five. Past the 10-hop ceiling, the crawl does not resolve, so the page is not indexed on that pass. Redirects themselves do not drain PageRank, though, so the case for auditing chains is latency and crawlability rather than lost link equity.

Mixed content.

A page served over HTTPS that pulls an image, script or stylesheet over HTTP is "mixed content." What browsers do depends on the resource type. Scripts, stylesheets and iframes are blocked outright. Images, audio and video are auto-upgraded to HTTPS and dropped entirely if they are not available there. Because the upgrade happens silently, you usually get no address bar warning at all, so the symptom is a missing asset or broken layout and the evidence sits in the DevTools Issues and Console tabs. This often creeps in after a migration, when old HTTP asset links survive in templates or a database. Audit for it whenever you move to HTTPS or change domains.

Both problems are really redirect-hygiene problems. Short chains, every hop on HTTPS, clean source links. That is redirect hygiene, and it is hard to keep right without visibility into your redirect paths.

Test and monitor your setup

A browser only shows you the single connection it happened to negotiate, not the full set of protocols and cipher suites your server still accepts, so test the configuration directly.

Run your domain through a public SSL testing tool that grades the full configuration, protocols, cipher order, certificate chain, HSTS and OCSP stapling and aim for an A or A+ result. Retest after every configuration change, since a routine server update can silently re-enable something you disabled. Use your browser's developer tools to catch mixed content on individual pages and keep certificate and uptime monitoring running so an expiry or a bad deploy pages you before it pages your customers.

Common SSL mistakes to avoid

• Letting a certificate expire because renewal was manual.
• Leaving TLS 1.0 or 1.1 enabled for "compatibility".
• Serving pages over both HTTP and HTTPS instead of redirecting one to the other.
• Forgetting a subdomain when planning coverage or HSTS preload.
• Adding includeSubDomains to your HSTS policy before every subdomain can serve HTTPS, which breaks legacy HTTP-only subdomains like an old intranet.example.com for anyone whose browser has already seen the header.
• Redirect chains where one hop drops to HTTP or a mismatched certificate.
• Mixed content left behind after a migration.
• Using a wildcard certificate everywhere and concentrating all your risk in one key.
• Skipping the CAA record that limits who can issue for your domain.

Getting it right and keeping it right

Good SSL is not a one-time install. It is a modern protocol config, HTTPS on every path, certificates that renew before they lapse and redirect paths that stay encrypted the whole way. The first four are configurations you set once and monitor. The last one, the redirects, is the piece that quietly drifts as your site grows and changes.

If your HTTPS enforcement and redirect paths are scattered across servers, CDNs and config files, consolidating them into one place makes the whole picture easier to keep correct. urllo puts your redirects and HTTPS enforcement in one place, so the part most likely to drift is the part you can stop watching.

Frequently asked questions about SSL best practices

What is the difference between SSL and TLS?

SSL is the older protocol everyone still names, but the one actually running today is TLS. SSL 2.0 and 3.0 are both insecure and disabled. Modern connections use TLS 1.2 or TLS 1.3. In everyday use "SSL" refers to the certificate and encrypted connection, while "TLS" names the specific protocol version you configure.

Is TLS 1.2 still secure or should I move to TLS 1.3?

TLS 1.2 is still secure when configured with modern AEAD cipher suites and forward secrecy. TLS 1.3 is faster and removes the weak options entirely, so serve it as your primary protocol and keep TLS 1.2 as a fallback for older clients. Disable TLS 1.0 and 1.1, which the IETF formally deprecated in 2021.

How long are SSL certificates valid now?

The maximum validity for a publicly trusted TLS certificate issued on or after March 15, 2026 is 200 days. Certificates issued before that date stay valid for their original term. It drops to 100 days in March 2027 and 47 days in March 2029 under a CA/Browser Forum schedule. At those lengths, manual renewal is not workable, so automating with the ACME protocol is the practical answer.

Do I still need OCSP stapling?

Only if your certificate authority still supports it. The ecosystem is moving away from OCSP toward mandatory CRLs and Let's Encrypt stopped including OCSP URLs in its certificates in 2025. If your certificates carry no OCSP URL, turn the stapling directive off rather than leaving it to log warnings on every reload.

Should I use a 301 or 302 to redirect HTTP to HTTPS?

Use a 301. It is a permanent redirect, so browsers and search engines cache it and stop requesting the insecure HTTP version. A 302 is temporary and tells them to keep checking the original URL, which is not what you want once HTTPS is the permanent home for a page.

Does moving from HTTP to HTTPS affect SEO?

Yes, though not in the way most guides imply. Google confirmed HTTPS as a ranking signal in 2014 and described it at the time as very lightweight, affecting fewer than 1% of global queries and carrying less weight than content quality. Google said it might strengthen the signal later but has never published an update, so treat it as a tiebreaker rather than a lever.

The larger gains are indirect: no "not secure" warnings driving visitors away, and access to HTTP/2 and HTTP/3. Redirect every HTTP URL to its HTTPS version with a 301. According to Google, redirects themselves do not cost you PageRank, so a clean migration protects your rankings.

What is mixed content and how do I fix it?

Mixed content is when a page loads over HTTPS but pulls an image, script or stylesheet over plain HTTP. Browsers block scripts, stylesheets and iframes outright and quietly upgrade or drop images and media, so the symptom is often a broken layout. Fix it by pointing every resource link at HTTPS. Your browser DevTools console lists each one.

Do I still need an EV certificate?

For most sites, no. Modern browsers no longer show a visible trust cue for Extended Validation certificates in the address bar, so the main reason to pay for one is gone. Domain Validation is enough for the majority of sites. Reach for OV or EV only when a compliance rule or a specific customer expectation requires it.

By Shannon Young

Customer Success Manager

Shannon is a seasoned professional in the customer success space. She has years of experience in a wide variety of customer-facing roles in various sectors.

Always ready to take on the next challenge, whether it be a new offensive cross stitch pattern or making her dogs sit still for another themed photo, she is prepared for anything.