Do I Need an SSL Certificate for My Website?

What an SSL certificate actually does

An SSL certificate is a small data file that sits on the server behind your website. When someone visits, their browser checks the certificate first. If it is valid, the browser and the server set up an encrypted connection before a single page is sent. That connection is what turns the http at the start of your address into https.

For a small business, the certificate does three jobs:

• It keeps information private on the way. Whatever travels between your site and a visitor, such as a contact form, a booking request, a login or a card number, is scrambled so that nobody in between can read it.
• It stops tampering. Mozilla’s developer documentation describes the technology behind it as preventing tampering with and eavesdropping on web browsing, email and messaging. Nobody between you and your visitor can quietly change the page on its way to them.
• It proves the address. A certificate is issued for your domain name by a certificate authority, an organization that browsers trust. Even the most basic kind only gets issued after the authority confirms that the person asking for it controls the domain.

Think of it as a sealed courier envelope with your domain printed on the front. The seal keeps the contents private and shows nobody opened them, and the printed name tells the recipient where it came from. What the envelope cannot tell anyone is whether the sender is honest. That limit matters, and a later section comes back to it.

As an owner, you never need to touch keys or ciphers. You need three things: a valid certificate on every version of your address, every visitor sent to the https version, and renewal that happens without anyone having to remember it. The rest of this guide covers each of them, in plain words.

SSL, TLS, HTTPS and the padlock, untangled

The names are confusing because the industry changed its technology and kept its old vocabulary. Here is what each term means.

• SSL, short for Secure Sockets Layer, is the name of the original technology. It was replaced long ago, but the name stuck.
• TLS, short for Transport Layer Security, is what actually protects websites now. Mozilla’s glossary defines TLS as the protocol formerly known as Secure Sockets Layer. It also notes that all major browsers began removing support for TLS 1.0 and 1.1 in early 2020, so your server should support TLS 1.2 or 1.3. Your host looks after that part.
• An SSL certificate and a TLS certificate are the same thing under two names. Hosts, registrars and most people searching still say SSL, so this guide does too.
• HTTPS is the web’s normal language, HTTP, carried over an encrypted TLS connection. The s stands for secure.
• The padlock is the icon browsers have long shown beside an https address to say the connection is encrypted.

If you use Chrome and cannot find a padlock at all, you are not imagining it. In a May 2023 post, the Chromium team announced it would replace the lock icon in Chrome’s address bar with a new “tune” icon, scheduled for Chrome 117 in early September 2023. Its reason is worth knowing: research found that “only 11% of study participants correctly understood the precise meaning of the lock icon.”

So when this guide says padlock, read it as “the browser says the connection is secure”, whichever icon your browser uses to say it.

Why your browser says Not secure

If your site shows Not secure in the address bar, the cause is almost always one of four things:

• The site has no certificate, so it only loads over plain http.
• It has a certificate, but visitors are not sent to the https version, so anyone who types your address or follows an old link still lands on http.
• The page loads over https but pulls in an image, script or font over plain http. That is mixed content, covered in its own section below.
• The certificate has expired, or it does not cover the exact address the visitor used, such as the version with www. Then the browser usually shows a full warning rather than a small label.

Browsers have been heading in one direction for years. In July 2018, Google wrote that starting in Chrome 68, you’ll see a new “not secure” notification when visiting HTTP pages. That label appears whether or not the page asks for anything, which is why a simple brochure site can look suspicious to a first-time visitor.

Google has also announced the next step. In October 2025 it said that with the release of Chrome 154 in October 2026 it would turn on a setting called Always Use Secure Connections by default, which means Chrome will ask for the user’s permission before the first access to any public site without HTTPS. A site on plain http no longer just looks a little untidy. It can trigger a question before the visitor sees anything at all.

Put yourself in the visitor’s seat. They searched for a plumber, tapped your result and got a security question from their browser before your homepage loaded. Some will carry on. Others will tap back and choose the next business on the list, and you will never know they came.

The good news is that every one of these causes can be fixed, usually in an afternoon and usually at no cost.

Does every website need one, even without a shop?

Yes, every website. It is tempting to think certificates only matter for online stores, because that is where card numbers change hands. If you do sell online, every page of the checkout must be on https, and our guide to ecommerce basics for small business covers the rest of selling online. But Google’s 2018 announcement was about marking all sites that are not encrypted with HTTPS as not secure, shop or no shop, and most business sites collect more than their owners realize:

• a contact or quote form with names, email addresses, phone numbers and details of a job
• a booking tool with dates, times and sometimes personal circumstances
• a newsletter sign-up with email addresses
• your own admin login, sent every time you or your staff update the site

That last one is easy to forget. Without https, the username and password for your own website travel unencrypted whenever someone logs in, so on a cafe or hotel network others may be able to see them.

Canada’s privacy rules point the same way. The Office of the Privacy Commissioner’s guidance on the PIPEDA safeguards principle tells businesses to protect personal information in a way that is appropriate to how sensitive it is, and lists up-to-date technological tools such as passwords, encryption, firewalls and security patches. A contact form sent over plain http is hard to square with that. Your privacy policy should explain how you protect what people send you, and our guide to website privacy policies in Canada walks through what to include.

And Google? Its page experience documentation asks site owners a direct question: “Are your pages served in a secure fashion?” The same page says that beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. So treat https as the entry ticket, not a ranking trick. The real payoff is visitors who are not warned away before they meet you.

Free or paid: what the price actually buys

Some certificates are free and some cost money every year, and it is not always obvious what the money buys. The difference is not the encryption. As security company SecureW2 puts it in a May 2026 explainer, “DV, OV, and EV certificates all provide identical encryption strength.” What changes is how much checking the certificate authority does before it issues one. Certificate authority Sectigo sets out the three validation levels, and here is how they compare for a small business:

So which do you need? For a typical small business site, a free domain validated certificate is enough, as long as it renews automatically. A paid certificate makes sense when a bank, a partner or a contract asks for checks on your organization, or when your platform cannot issue free ones. If a host is billing you every year for a basic certificate, ask why, and ask whether a free one is available on your plan.

One caution about the word free. A free certificate is only free while something keeps renewing it. A free certificate that lapses costs you more than a paid one that renews, in lost inquiries and in trust, so judge any option on how renewal works rather than on the price tag.

Also be wary of anyone who says a paid certificate will make your site more secure in general, or rank better. Every level encrypts the connection the same way, and none of them stops the problems covered later in this guide, such as weak passwords and outdated plugins.

How to get a certificate on your site

For most owners, getting a certificate is a setting to check, not a project to run. Where you start depends on how your site is hosted.

• A website builder or hosted store platform. Look in the domain or security settings for an SSL or HTTPS option, and switch it on if it is off. If you connected your own domain, check that the certificate covers it and not just the platform’s own address.
• Shared hosting with cPanel. cPanel, a hosting control panel, has a feature called AutoSSL that automatically installs domain validated certificates for the domains on your account. By default it uses Let’s Encrypt, and cPanel says its licence includes this free provider.
• A managed website service. If someone runs your site for you, the certificate should be part of the service. Ask them to confirm it covers every version of your address and renews automatically.
• Your own server or a developer’s setup. Your developer will normally use an automated client that requests and renews certificates on a schedule. Ask how failures are reported, not just whether renewal is set up.

Whichever route you are on, ask your host or developer four questions, and get the answers in writing:

• Is the certificate included in my plan, or billed separately?
• Does it cover my address both with and without www?
• Does it renew automatically, and who is told if a renewal fails?
• Are visitors sent from http to https automatically?

Our guide to website hosting for small business covers what else a good host should handle for you. If the answers to those four questions are vague, treat that as a finding in itself, because the next section explains why renewal is about to matter much more.

Certificates now expire faster, and soon faster again

Until recently, a certificate could last more than a year. That is changing in steps, and every step makes renewing by hand harder to keep up with.

In April 2025, the members of the CA/Browser Forum, where certificate authorities and browser makers agree the rules for public certificates, voted for a reduction of the maximum validity period from 398 days to 47 days, in steps starting in March 2026 and concluding in March 2029. Sectigo and the domain company DNSimple both set out the schedule:

• Since 15 March 2026: a new certificate can be valid for at most 200 days, according to Sectigo.
• From 15 March 2027: at most 100 days.
• From 15 March 2029: at most 47 days, as DNSimple’s timeline shows.

The same ballot also shortens how long an authority can rely on its earlier check that you control your domain, eventually to just 10 days. In practice, that check has to be repeated almost every time a certificate is issued.

Free certificates are getting shorter too. Let’s Encrypt, the free authority that cPanel’s AutoSSL uses by default, says it currently issues certificates valid for 90 days, which will be cut in half to 45 days by 2028, with a 64-day step in February 2027.

“The certificate is rarely the problem. The renewal is.”

Here is what that means for you. At 47 days, a certificate renewed by hand would need replacing about eight times a year, every year. Sectigo’s own verdict is that manual, calendar-driven certificate management wasn’t built for this pace, and Let’s Encrypt says manually renewing certificates is not recommended, as it will need to be done more frequently.

So the question is no longer whether you have a certificate. It is whether its renewal runs without a person. If it does, these changes pass you by. If it does not, fix that now, while the limit is still 200 days and a missed renewal is a twice-a-year risk rather than an eight-times-a-year one.

What happens when a certificate expires

When a certificate expires, browsers stop trusting it. DNSimple’s troubleshooting guide puts it plainly: the old certificate stays active until its expiration date, but browsers will reject it once it expires. Sectigo describes what happens next: once your certificate expires, site visitors will encounter the “Your connection is not private” message.

For a small business, that warning costs more than it looks:

• Visitors see a warning instead of your homepage, and in Sectigo’s words, they “may hesitate to proceed.”
• Contact forms, bookings and checkouts stop working for everyone who turns back.
• Any ads you run keep paying for clicks that land on a warning.
• Staff end up explaining to customers on the phone that the site really is yours.

The fix itself is usually quick: renew or reissue the certificate, or fix whatever stopped the automatic renewal, then check the site from a phone on mobile data. The lasting fix is monitoring. Ask your host or website manager who is alerted when a renewal fails, and how fast they act. When Let’s Encrypt ended its emails, it pointed people who still want expiry notices to third-party monitoring services.

One trap when you investigate: if a single visitor reports a warning but your site loads fine everywhere else, check their device. Google’s Chrome help pages note that you can get this kind of error if your computer or mobile device’s date and time are inaccurate.

Still Not secure after installing it? Mixed content

You installed the certificate, the address starts with https, and the browser still says the page is not fully secure. The usual cause is mixed content. Google’s web.dev guide on what mixed content is explains it: the page itself arrives over a secure https connection, but some of what it loads, such as images, scripts, stylesheets or videos, still comes over plain http. DNSimple adds that even one HTTP resource on an HTTPS page triggers a mixed content warning.

Browsers handle it in different ways. web.dev says most browsers now block mixed content for security reasons, so an insecure script can simply stop running, which can break a slider, a form or a chat window without an obvious error. For images, Chrome may load the https version of a file that was written as http, if one exists. Either way, the page can lose its secure status.

Mixed content usually comes from one of these places:

• images inserted years ago with a full http:// address written into the page
• theme or design settings, such as a logo or background image saved before the switch
• embedded videos, maps, booking widgets or fonts copied from a provider’s old code
• links hard-coded into footers, sidebars and plugins

To find it, open the page in a desktop browser and open the developer tools. web.dev notes that Chromium-based browsers list blocked content in the Issues tab, while Firefox and Safari log messages in the console. Then change each http:// address to https://. If a file is not available over https, host it on your own site or replace it. Finally, make sure your platform’s own site address setting starts with https, so new uploads get the right address from the start.

Make every visitor land on https

Installing a certificate does not move anyone to https on its own. Old links, printed flyers, bookmarks and people typing your address by hand can all still arrive at the http version. A redirect fixes that: it sends every request for an http page to the same page on https, automatically.

Google’s guide to moving a site treats a switch from http to https as a site move. It recommends server-side permanent redirects, such as 301 and 308, and says that 301 and other permanent redirects don’t cause a loss in PageRank, so the search value your pages have built carries over. It also says you don’t need the Change of Address tool in Search Console for an http to https move.

Then test the four versions of your address, because each one is a separate way in:

• http:// with your domain on its own
• http:// with www in front
• https:// with your domain on its own
• https:// with www in front

All four should end up at the same https address, ideally in a single hop. Pick one main version, with or without www, and send the other three there.

If you are moving an older site to https for the first time, there is more to do: internal links, canonical tags, sitemaps and analytics settings should all switch to the new address. Our website migration checklist covers moving to https step by step, alongside the other checks that keep a move from costing you traffic.

How to check your certificate in two minutes

You do not need technical tools to see whether your certificate is healthy. Grab a laptop and a phone switched to mobile data, and work through this:

If anything fails, write down what you saw, the page and the date, and send it to whoever looks after your site. A certificate problem you find on a quiet Tuesday is far cheaper than one a customer finds for you.

If you use Google Search Console, Google’s page experience documentation also points to a report that checks whether you are serving secure HTTPS pages and what to fix if you are not.

This check belongs in a wider routine. Our website audit checklist for small business puts it alongside forms, speed, backups and the other things that quietly break while a site still looks fine.

What SSL does not protect you from

A certificate protects information while it travels. It does nothing for the website itself once someone gets in, and it says nothing about whether the business behind a site is honest.

The Chromium team was blunt about this when it retired Chrome’s lock: “we know that the lock icon does not indicate website trustworthiness.” A scam site can get a certificate too, because the basic kind only confirms control of a domain, not who runs it or what they intend.

“A padlock tells you the line is private. It does not tell you who is on the other end.”

For your own site, these still need attention with or without https:

• weak, reused or shared passwords on your website, hosting, domain and email accounts
• outdated software: the platform, theme and plugins behind the site
• missing backups, so a hack or a bad update cannot be undone
• old user accounts for staff and contractors who have moved on
• phishing emails that trick someone into handing over a login

Our guide to small business website security covers each of these, and why layering several protections matters more than any single tool. The certificate is one lock on one door. It still needs the rest of the house.

Pass the same lesson on to your staff. An https address on a login page does not prove the page is genuine. Check the domain name itself before typing a password, especially when you arrived from a link in an email.

Subdomains, www and email: what else needs covering

A certificate covers the exact names written into it, and nothing else. DNSimple’s troubleshooting guide gives a classic example of a name mismatch: a certificate issued for www.example.com while the site is reached at example.com, or the other way round. It also notes that a single-name certificate only covers one hostname.

• www and the bare domain. Make sure the certificate covers both, even if one only redirects to the other. When someone types https:// with a name the certificate does not cover, the browser checks the certificate before any redirect can happen, so they see a warning first.
• Subdomains. Every subdomain people visit, such as shop, book or portal in front of your domain, needs covering. One certificate can cover several names, and DNSimple suggests a wildcard certificate if you need to cover multiple subdomains. cPanel’s AutoSSL installs certificates for the domains on your hosting account, which can take care of this for you.
• Extra domains that redirect. If you own other domains that forward to your main site, each one needs a certificate too, or https visits to them will hit a warning before the redirect.
• Email. Your website certificate does not protect your email. Mozilla’s glossary lists email alongside web browsing as something TLS protects, but that encryption is set up on your mail servers, not your website. If your email runs through a separate provider, ask that provider.

The safest habit is to list every name that points at your site or your email, then test each one. Our guide to domain names and business email explains how domains, websites and email fit together, which makes that list much easier to write.

Keep the list somewhere the whole business can find it. When you add a booking subdomain or buy a new domain for a campaign, it goes on the list and gets tested the same day.

SSL mistakes that cost small businesses

• Paying for a certificate you already have. Many plans include a free one. Check before you buy, and before you renew a paid one.
• Renewing by calendar reminder. It works until the person with the reminder leaves, gets busy or changes email. With lifetimes heading to 47 days, it stops working altogether.
• Assuming automatic means watched. Automatic renewal can fail quietly, for example after a domain or hosting change. Someone should be alerted when it does.
• Installing the certificate but skipping the redirect. Visitors who type your address or follow an old link still land on http and see Not secure.
• Covering example.ca but not www.example.ca. Or the other way round. Test both, every time anything changes.
• Ignoring mixed content. One old image or script address can keep a page from showing as secure.
• Treating the certificate as a security plan. It protects the connection, not your logins, plugins or backups.

There is one more, and it is the hardest to spot from the outside: the account that holds the certificate, the hosting or the domain sits in the name of a former employee or supplier. Renewals then fail with nobody to notice, and fixing anything means proving the business owns its own website first.

None of these takes long to fix. They are easy to miss because most of them hide when you only ever look at your site from your own laptop, logged in, on the office Wi-Fi. Test like a stranger: a private browser window, a phone on mobile data, and the address typed by hand.

Your SSL checklist

Work through this once, then repeat the quick checks every few months and after any change to your hosting, domain or platform.

1. Confirm you have a certificate. Load your site over https and open the connection details in your browser.
2. Check every name. Test your domain with and without www, plus every subdomain and extra domain that points at the site.
3. Force https. Make sure every http address redirects to the same page on https, in one hop.
4. Clear mixed content. Load your key pages and fix any image, script, font or embed still loaded over http.
5. Note the expiry date. Write down when the current certificate expires, and confirm it has renewed on its own at least once.
6. Confirm renewal is automatic. Ask your host or website manager in writing, and ask who is alerted if a renewal fails.
7. Check who owns the accounts. Hosting, domain and certificate accounts should belong to the business, with current contact details.
8. Stop paying twice. If you pay for a certificate separately, check whether your plan already includes a free one.
9. Update your privacy policy. Explain how information people send through your site is protected.
10. Put it on the calendar. Repeat the two-minute check every few months and after any website change.

If you only have ten minutes, do steps 3, 5 and 6. A redirect, a known expiry date and a renewal that runs on its own cover most of the ways small business sites end up behind a browser warning.

Frequently asked questions