SSL certificates and HTTPS explained: what your website needs and what it costs

An SSL certificate is a digital credential used in the TLS connection behind HTTPS. Every public business website should use HTTPS, including a simple brochure site. A suitable certificate often comes at no extra charge with hosting, though setup and monitoring may cost extra. The real question is whether the whole setup works and who keeps it working.

What is an SSL certificate?

A certificate lets a browser check it's talking to the right server before any data moves.

A certificate authority (CA) issues the certificate after checking the request. Browsers trust a set of these authorities. When the names match and the certificate is valid, the connection goes ahead.

SSL is the familiar commercial name. Modern HTTPS actually uses TLS, its successor. You'll still see "SSL certificate" on hosting pages. It means the same product.

For the wider build, see website foundations for a small business.

HTTP versus HTTPS

HTTP carries web requests and responses between a browser and a server. HTTPS protects that exchange using TLS. A correctly configured TLS connection does three jobs:

Authentication here means the certificate matches the name you asked for. It isn't a guarantee that the business is honest or that the page tells the truth.

A brochure site still needs HTTPS. Google's web.dev guide explains that unprotected traffic can be tampered with in transit. It can also reveal what people read. Many browser features, like camera access and service workers, also need HTTPS.

HTTPS has limits too. It doesn't make visitors anonymous or hide every detail of their connection. It protects data on the way, not after it arrives. Once a form reaches your site, other systems may handle it. For that side, see handling information after a form submission.

What does HTTPS prove?

HTTPS proves the connection is protected and the certificate is valid for that address. That's all. A phishing site can have a perfectly valid certificate. So can a hacked legitimate one.

Visitors still need to judge the actual domain, the business, the offer and any request for information.

What happened to the padlock?

Chrome dropped the familiar lock in 2023. The Chromium team said Chrome 117 would replace it with a settings style icon. The team said the lock doesn't indicate a trustworthy website.

The new icon opens the site controls. Browsers and versions differ. Don't rely on one fixed icon or menu path.

What changes with Chrome's HTTPS first setting?

Google's Chrome Enterprise release notes say Chrome 154 will turn on "Always use secure connections" for public sites by default. Chrome will then ask permission before the first visit to a public site without HTTPS. The notes say the change rolls out gradually. Admin policies can override it. Recheck the current notes before you rely on the timing.

Different warnings point to different problems:

The chain is the set of linked certificates from your site up to a trusted authority.

Never click past a certificate warning or turn off certificate checks. Never move a form to HTTP either. Instead, record these details for whoever looks after the site:

• the error and the address

• the device, browser and time

• any recent change to the site or network

A warning on only one device needs checking on that device and its network too. A wrong system clock can trigger certificate errors.

Do you need a free or paid certificate?

A free, publicly trusted certificate can give you strong TLS. Price doesn't set encryption strength. Paid products differ in validation, support, management or contract terms.

None is stronger encryption. None stops phishing either. EV used to show a company name in the address bar. Chrome moved that information into the page info panel from Chrome 77. So don't expect a green bar or a conversion lift from buying EV.

If a contract or integration asks for particular validation, get the exact requirement in writing. Don't assume an online store needs EV. A certificate warranty is subject to its terms, not a promise to cover every customer loss.

Validation and name coverage are separate questions. The validation type describes the checks. The coverage type describes which addresses the certificate works for.

For most business sites, the plain answer works. A supported, automatically renewed certificate that covers the names you need is usually enough. Pay for something else when a specific requirement or support need justifies it. For hosting choices, see comparing hosting and support.

Which names must the certificate cover?

The certificate has to cover the exact hostname the browser asks for. A certificate for one name doesn't cover every other name that reaches the same server.

Providers often bundle the root name with a wildcard. Check the actual certificate rather than assuming. Cloudflare's Universal SSL, for example, covers the root domain and first level subdomains only. Deeper names like dev.www.example.com need a different arrangement.

Redirects need coverage too. If www.example.com redirects to example.com, the browser still needs a valid HTTPS connection to www first. Only then can it receive the redirect. The same goes for old domains and campaign subdomains.

List every name the business actually uses, including:

• booking and customer portal addresses

• checkout addresses

• download addresses

A name on your provider's own domain is the provider's job. A custom domain needs an agreed certificate and renewal plan. A common mistake is checking the homepage and missing the booking subdomain.

Why do certificates expire?

Short lifetimes keep validation fresh. They also limit how long a stolen or wrongly issued certificate stays usable. The expiry date isn't the same thing as your annual hosting or management invoice.

Two schedules matter, and they're different. The first is the industry maximum set by the CA/Browser Forum:

Those limits come from the CA/Browser Forum's baseline requirements. Its members approved the schedule in April 2025. They apply to newly issued certificates. They don't cancel older certificates on the transition date.

The second schedule is your certificate provider's own. Let's Encrypt is a common example. A profile is its preset set of issuing options:

That timeline comes from Let's Encrypt's announcement. Its October 2026 update, posted on 7 October, scheduled staging to switch to 64 days on 14 October. Staging is for testing. The default production change still lands in February 2027.

In practice, confirm your renewal client, deployment and monitoring can handle shorter certificates. Renewal clients use ACME, the standard protocol for issuing certificates automatically. Let's Encrypt recommends ACME Renewal Information (ARI), a feature that tells your client when to renew. It says a fixed 60 day renewal job won't be enough. A common mistake is leaving a renewal job tuned for 90 day certificates.

If you're on shared hosting, ask your provider to confirm this rather than editing server jobs yourself.

Don't set one universal alarm, like "fewer than 14 days left". Profiles and renewal windows differ. The real question is whether renewal and deployment succeeded with time to spare.

Installing the certificate is only part of the job

A working HTTPS setup has several parts. The certificate is just one of them:

Use a supported, current TLS configuration that suits the service. MDN's TLS guide recommends sending every request over HTTPS with safe settings. The server should also send the full certificate chain. Then update everything that still points at HTTP:

• internal links and canonical tags

• XML sitemaps

• forms and their submission addresses

• scripts, stylesheets, images and fonts

• embedded services like maps or booking tools

Fix them at the source. A browser that quietly upgrades a resource hasn't fixed the underlying reference.

What is mixed content?

Mixed content is a secure page that loads some resources over HTTP. MDN's mixed content guide explains that browsers treat resource types differently. Some, like plain images, audio and video, get upgraded to HTTPS. Others get blocked, like scripts and stylesheets. Fonts and iframes get blocked too.

Find the actual request using the browser's developer tools. Check the Console and Network panels. Then fix or replace the source. Don't tell anyone to allow insecure content.

Redirects and browser upgrades

Typing an HTTP address and seeing HTTPS afterwards doesn't prove your server redirects properly. The browser may have upgraded the request itself, because of HSTS or its own HTTPS first setting. Ask your developer to check the actual network request and response.

Pick one preferred address, such as the www version. Permanently redirect the other variants to it.

Keep both hostname variants valid through the first HTTPS connection. Keep redirects simple and avoid loops. MDN also advises redirecting HTTP to HTTPS on the same host before redirecting to another host. Avoid copying a generic server snippet that could clash with a managed host or proxy.

Test complete enquiries and bookings after any change. Then test checkout and logins. A secure looking page doesn't prove the form reaches the business. A common mistake is fixing the redirect while a form still posts to an HTTP address. See testing the complete enquiry form, and run the website launch checklist after big changes.

What changes when a CDN sits in front of the site?

A content delivery network (CDN) adds a second connection. Visitors connect to the CDN. The CDN then connects to your server, called the origin. The certificate your browser shows usually belongs to the first connection only.

Here, agency means your host or developer. Shared means you and the CDN provider. The map shows the arrangement to aim for, not what every existing setup already has.

Cloudflare is one example, not a universal instruction. Its Full (strict) mode encrypts the origin connection and validates the origin certificate. That certificate must be unexpired, trusted and match the hostname. Prepare and test the origin first, or visitors may see an error after the switch.

Cloudflare's Origin CA certificates only encrypt the connection between Cloudflare and the origin. Visitors may see untrusted certificate errors if Cloudflare is paused or proxying is turned off.

Should you enable HSTS?

HSTS is a response header that tells browsers to use HTTPS for a site for a set period. MDN's HSTS guide explains that browsers ignore it if it's sent over HTTP. It also stops visitors clicking past certificate errors on that site.

Two settings decide its reach. The max-age setting is how long browsers remember the rule. The includeSubDomains setting extends it to every subdomain. A long policy can break a forgotten service that can't do HTTPS.

Before going broad, list every public, nested and internal name. Confirm each one supports HTTPS, then stage the rollout with your technical owner. Don't paste a long includeSubDomains and preload header into every small business site.

Preloading is a separate decision. The HSTS preload service recommends HSTS. It doesn't recommend preloading.

Preloading applies to every subdomain, including internal ones. Removal can take months to reach users. Leave it out of your checklist unless a specialist has a specific reason.

HSTS, browser upgrades and server redirects work together but behave differently. None replaces a working certificate or testing the services the policy covers.

Does HTTPS affect SEO and speed?

HTTPS matters for search and speed. It just doesn't work the way sales pitches suggest.

Search

Google announced HTTPS as a ranking signal in August 2014. That post doesn't tell you its weight today. A certificate isn't a search growth strategy. Paying more for one doesn't establish a ranking advantage either.

The practical search work is plainer. Make the intended HTTPS URLs accessible, with consistent redirects and canonical tags. Update internal links and sitemaps. Then check the right Search Console property.

Google's canonical guidance says it prefers HTTPS pages as canonical, with exceptions. Those include an invalid certificate, insecure dependencies, redirects through HTTP or a canonical pointing to HTTP. It still doesn't promise every URL gets indexed.

Switching to HTTPS is a URL migration. Follow the steps for moving a website to HTTPS. For the property, see setting up Search Console. Check campaign links and important external links too.

Speed

TLS adds some connection work. It's counted in the time to first byte, along with DNS and server time. Diagnose the actual DNS, connection, TLS, server and resource timings before blaming or clearing TLS.

A slow site usually has more than one cause. Start with diagnosing website speed and understanding Core Web Vitals. Never turn off HTTPS to speed things up.

Seven checks for your website

These checks are a first review. They aren't a full security audit. Run them on important pages and every public hostname:

1. Open the intended HTTPS address and confirm it loads without a certificate error.

2. Check the server's actual HTTP to HTTPS response in the network request.

3. Test the root and www names plus relevant subdomains. Confirm where each one ends up.

4. Open the connection details for the loaded address.

5. Inspect the certificate's names, issuer and validity, then confirm how it renews.

6. Test contact, booking, checkout, login and campaign pages through to the destination.

7. Check the developer tools' Console and Network panels for mixed content, beyond the homepage too.

Unknown is a legitimate finding. Don't record an untested item as a pass.

For online stores, add checking the whole ecommerce journey. Then ask two follow up questions. Does a CDN connection to the origin need separate checking? Who gets the alert if renewal or deployment fails?

These checks can sit inside a broader website audit. Renewal monitoring is different, though. It needs to run continuously and automatically. A manual check once or twice a year can't keep up with short certificates.

Why does the website still show a warning?

Investigate the warning you actually see. Each symptom points somewhere different:

Renewal isn't finished when the certificate is issued

A new certificate only helps once every endpoint serves it:

Check the certificate visitors receive after issuance, not just the provider's status. Confirm the full chain and the right hostname at each endpoint. A new file on one server doesn't prove every edge uses it.

When renewal fails, have your technical owner check the validation route and recent changes. Let's Encrypt's challenge types show what can break.

The HTTP check needs port 80, the standard unencrypted web port. It also needs the right file on every server. The DNS check needs working DNS access. Changed nameservers, expired credentials or a failed deployment can all matter.

CAA records limit which authorities may issue certificates for your domain. One that leaves out your provider can block renewal. Don't delete security records at random to make an error go away.

If a private key is exposed

Treat an exposed private key or an unauthorised certificate as a security incident. Routine renewal isn't enough. Your technical owner needs to:

• contain the access problem

• replace the affected keys and credentials

• arrange revocation with the issuer

Let's Encrypt's revocation guide says revoking certificates for compromised keys is important practice. Follow the issuer's authorised process, then confirm the repaired service works. Don't wait for the certificate to expire.

Who keeps HTTPS working?

Renewal can fail quietly when nobody owns it. Write down who does what:

One person can hold several roles. No role should be assumed. A common mistake is renewal alerts going to a former developer's inbox.

Protect provider accounts with multi factor authentication (MFA) and a recovery plan. Never send private keys or passwords in ordinary email. Store secrets in a proper secure system instead.

When a developer or provider changes, check the new renewal route and alerts first. Only then remove the old dependency. For the full process, see handing over hosting and website access.

HTTPS is one layer of security. The rest still needs attention:

• supported, updated software

• tight access control

• secure hosting and monitoring

• backups with tested recovery

For those, see security beyond HTTPS and backups and tested recovery.

What should SSL cost in Australia?

The certificate itself can cost nothing extra. Let's Encrypt calls itself a free, automated and open certificate authority in its getting started guide. If your host manages them, they're issued automatically or once you turn on a setting.

When comparing quotes, separate these items:

• the certificate charge, if any

• initial installation, redirect and mixed content work

• renewal management and monitoring

• independent checks and support

Ask whether each price includes GST, the billing period, renewal terms and exclusions. An annual management invoice doesn't mean the certificate itself lasts a year.

Those figures are examples, in AUD excluding GST. They aren't provider prices, market rates or an Elev8d quote. In the example, the $120 covers renewal monitoring, alert response and a yearly check of names and redirects. CDN or DNS changes, new subdomains and incident work sit outside it. If the scope and rates stay the same, the next year is $120.

There's no single price that marks a bad deal. The red flag is scope. Be wary of a material recurring charge with no clear certificate, management work or support behind it. Ask for itemisation. For the wider budget, see planning the full website cost and ongoing maintenance responsibilities and cost.

Small business HTTPS checklist

Use this checklist after setup and after any hosting, DNS or developer change:

A few myths are worth retiring at the same time:

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the situation that fits.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.