SSL certificate — is a free one enough, and when is it worth paying?

The short answer to whether you need an SSL certificate: yes — and a free one will almost certainly do.

The longer answer is worth having, because the question "which certificate should we choose?" is usually put to someone who earns money selling certificates. What follows is the same answer without that conflict of interest — with three facts you can check at the source, and one deadline that falls next month.

What is SSL — in two paragraphs

SSL and TLS are the same mechanism under two names. SSL came first and was retired years ago; TLS is its successor, and it is TLS that protects every connection today. The name "SSL" stayed in the industry's vocabulary and in product names, so when you buy an "SSL certificate" you are buying a TLS certificate. The distinction has no practical consequence, and we mention it only so that two names in one quote do not look like two different products.

HTTPS is the ordinary connection to a website, wrapped in that encryption. Without it, everything someone types into a form — their name, phone number, the content of their enquiry — travels across the network in a form that can be read along the way. The certificate plays two roles at once: it supplies the keys for the encryption, and it confirms that the server at the other end is who it claims to be. That second role is the reason certificates are issued by anyone at all, rather than everybody generating their own.

What changes in 2026 — and why it cannot wait

Two changes are happening in parallel. The first is visible to the person visiting your site, the second to whoever maintains it — and it is the second that catches people out more often.

October 2026 — Chrome stops opening HTTP sites without asking

Chrome is ending the era in which a missing HTTPS was a minor detail. Google described this on its blog, and the schedule has two stages:

• April 2026, Chrome 147 — the "Always Use Secure Connections" setting switched on for Enhanced Safe Browsing users, which Google puts at over a billion people. That has already happened.
• October 2026, Chrome 154 — switched on by default for everyone. The browser will ask the user for permission before the first visit to any public site without HTTPS.

In practice this means one thing: a site without a certificate will simply stop opening. Instead of the page, the visitor sees a question asking whether they really want to go there — a question people are asked once, and answer "no".

It is worth noting what the change does not cover: local networks and private addresses, which have no way of obtaining a certificate. The variant Google is switching on applies to public sites.

Certificate lifetimes have already been shortened

This is the part most guides miss, because it happens quietly.

In April 2025 the CA/Browser Forum adopted Ballot SC-081v3 — unanimously, with the support of Apple, Google, Mozilla and Microsoft. The maximum lifetime of a publicly trusted certificate falls in three steps:

The first step is already in force. That means the model "we buy a certificate for a year and install it by hand" stopped working in March — not in three years' time, but six months ago.

The conclusion is practical and applies to anyone with a website: automatic renewal is no longer a convenience; it is a condition of staying online. A certificate renewed by hand every 200 days gives somebody two chances a year to forget — and a site with an expired certificate does not display at all, it shows a full-screen warning instead.

Free certificates from Let's Encrypt have renewed automatically through the ACME protocol from the very beginning. With paid ones it depends on the vendor — and today that is a more important question than the price.

Which certificate to choose — and what the padlock does not tell you

The three types of certificate differ only in what the issuer checks before issuing it — not in the strength of the encryption. That is the first thing worth knowing, because it is sometimes sold the other way round:

• DV (Domain Validation) — checks that you control the domain. Issued automatically, in minutes, free of charge.
• OV (Organization Validation) — additionally checks that the company exists. Paid, issued in days.
• EV (Extended Validation) — extended verification of the organisation. The most expensive.

The encryption is identical in all three. The difference lies in what is written into the certificate, not in how well it protects the data.

Wildcard SSL certificate — when you actually need one

This question comes up more often than the question about EV, so it deserves its own answer.

A wildcard certificate covers every subdomain of one level at once — shop.company.pl, portal.company.pl, app.company.pl — instead of a separate certificate for each. It does not, however, cover the level below: a certificate for *.company.pl will not protect test.shop.company.pl.

When it makes sense: when there are several subdomains and new ones appear unpredictably — because then each new one works immediately, without anybody having to remember to issue a certificate. Typically this applies to companies that run separate addresses for a shop, a customer portal or a test environment. The same logic holds for a site published in several languages: if the languages live on subdomains (en.company.pl, pl.company.pl), a wildcard saves work; if they live in folders (company.pl/en/), an ordinary certificate is enough.

When it does not: for a single site with www. That case is handled by an ordinary certificate issued for two names — company.pl and www.company.pl — which is exactly how Let's Encrypt issues it automatically. Buying a wildcard for that is money spent for no effect whatsoever.

It is also worth knowing that a wildcard can be free: Let's Encrypt has issued them since 2018, except that verification then goes through a DNS record rather than a file on the server. Not every host supports this from its control panel — and that is the only real reason anyone ever buys a paid wildcard.

The myth people still pay for

EV certificates were sold on the strength of a green bar with the company's name in the browser. That bar has not existed since 2019. Chrome removed the company name from the address bar in version 77, Firefox in version 70, and Google gave its reason plainly: its security team had concluded that the EV interface did not protect users in the way intended, because research showed people did not understand what the different colours of the bar meant.

The company name can still be seen — after clicking the icon to the left of the address, which is a place nobody but specialists ever looks.

Buying an EV certificate "for prestige" or "to build trust" therefore means paying for something your customer will not see. One real difference remains: the warranty amount in the issuer's insurance policy — an argument that either matters to you or does not, but should be called by its name.

The padlock does not mean a site can be trusted

This is the second myth from the same family, and it is the more dangerous of the two — because it concerns not what you buy, but what you teach your customers.

The padlock in the address bar says one thing: the connection to this server is encrypted. It does not say who is at the other end, whether the company exists, or whether the shop will send the goods you ordered. A DV certificate confirms only control of the domain — and control of the domain is something any fraudster has who registered that domain ten minutes earlier.

Google explained this directly in a note about changing the padlock icon, citing its own research:

• In a study from 2021, only 11% of participants correctly understood what the padlock precisely means.
• Nearly all phishing sites use HTTPS, so they show the padlock too — that is the point of the same text.
• The misunderstanding is common enough that many institutions, the FBI among them, publish separate warnings about it.

The upshot was that in September 2023, in Chrome 117, the padlock disappeared and was replaced by a neutral settings icon. Google justified it in a sentence: the new icon does not imply "trustworthy". HTTP is still marked as not secure — the only thing that changed is that encryption stopped being rewarded with a badge.

For a business the conclusion runs two ways. First, HTTPS is now a condition of entry, not a distinction — there is no point advertising it on your site. Second, if your communication to customers contains the sentence "check for the padlock to know the site is safe", that sentence is untrue, and it is worth replacing with something that actually protects people: checking the domain in the address.

How much does an SSL certificate cost — and when is a free SSL certificate enough

Usually nothing. Let's Encrypt issues DV certificates free of charge, automatically and with no subscription; most hosts and every sensible control panel support them. That zero is the issuer's price, the same everywhere, and there is nothing to convert.

A paid certificate costs an amount that varies widely by vendor and validation level, and EV versions cost several times more. We have not surveyed the Polish market ourselves, but the range is easy to state: a paid certificate costs from a few dozen to a few hundred złoty a year, and EV versions several times more. What does not vary is what the money buys: verification of the organisation and an insurance policy, not better security.

For completeness on our own numbers: our maintenance calculator has a "Domain + SSL" line at PLN 100 a year. That is a bundle covering the domain name and its certificate, not the price of a certificate on its own — and the certificate inside it is precisely the free, automatically renewed kind described here. It is our price, not a market benchmark.

The trap worth checking at your host

A free certificate is sometimes free in name only. Practices worth watching for in cheap hosting packages:

• A fee for "installation service" on a free certificate, charged every year.
• Automatic renewal switched off in the cheaper packages, with an option to pay extra to switch it on.
• No way to upload your own certificate, which forces you to buy the host's in-house product.

None of these is illegal, and none of them necessarily applies to you — but they are common enough to justify one question to your host before you extend the contract: is Let's Encrypt available, does it renew by itself, and is there no extra charge for it?

With certificate lifetimes getting shorter, the question of automatic renewal stops being a technical curiosity. In 2029, renewing by hand would mean doing it eight times a year.

So what are you paying for, if not the certificate

Since the certificate is often free, it is worth saying plainly what you pay us and companies like us for — because it is not the same thing.

You are not paying for the letters in the certificate. You are paying for nobody ever seeing a warning. A free certificate renews automatically — as long as the renewal script runs, the server responds and the domain points where it should. When any of those conditions stops being true, the certificate expires quietly, and the first signal is often a phone call from a customer who cannot get onto the site.

With lifetimes cut to 200 days, those occasions come twice a year, and from 2027 almost four times. The service worth paying for is monitoring of the expiry date, a check after every renewal, and a response before anyone outside notices. The certificate is free; somebody's attention is not.

Encryption and your customers' data — what the law says, and what it does not

A contact form collects personal data — a name, an email address, a phone number, sometimes a message that is in itself information about the customer. It is worth separating two things that sales conversations tend to glue together.

First: protecting the transmission. Article 32 of the GDPR requires controllers and processors to implement technical and organisational measures that ensure a level of security appropriate to the risk, and among its examples it names, in so many words, "the pseudonymisation and encryption of personal data". The provision does not prescribe a particular technology and does not say "HTTPS" — it sets a level, not a technique. But sending personal data over an unencrypted connection is hard to defend today as appropriate, when encryption is free and universal. The argument "we couldn't afford it" ceased to exist the moment certificates became free. What else the GDPR expects of a website's contact form — the information notice, the legal basis, cookies — is covered in a separate article.

Second: the type of certificate. And this is the heart of it: no provision requires you to buy a commercial certificate. A free certificate encrypts the transmission in exactly the same way — the same protocol, the same algorithms, bit for bit. Compliance comes from the data being encrypted, not from what the certificate cost.

The practical conclusion for a business: if there is any form on the site, HTTPS stops being a matter of convenience and becomes something every compliance audit and every larger customer vetting a supplier will ask about. But the question will be "is the transmission encrypted?", not "did you pay for your certificate?".

How to install an SSL certificate — from scratch, and on a live site

Two different situations, two different procedures. The first is short; the second needs care, because it changes every address on the site at once.

You have no certificate — four steps

Four steps, in this order. With a typical host the whole thing takes a quarter of an hour.

1. Check whether your host offers Let's Encrypt. Most have it in the control panel as a switch. If so, turn it on and go to step 3.
2. If it does not — that is a signal in itself, and worth treating as a reason to talk about changing host rather than a reason to buy a certificate.
3. Redirect all traffic from HTTP to HTTPS. Without this, both versions run side by side, and the search engine sees two sites instead of one.
4. Check for mixed content — open a few pages and see whether the icon in the address bar looks the same everywhere. If it does not, addresses beginning with http:// have been left hard-coded in the content.

Step four is the one most often forgotten, because the first three produce an immediate effect and it all looks finished.

Your site runs on HTTP — an HTTP to HTTPS migration without losing your addresses

This is a different situation from a new site. For a site that already has any traffic and any rankings, moving to HTTPS is a change of every address on the site at once — because http://company.pl/services and https://company.pl/services are two different addresses to a search engine. The change itself is safe, provided it is done completely. A half-finished migration can split your visibility between two versions of the site, neither of which is whole.

For a typical company website, the whole operation is an hour or two of work. The risk lies not in difficulty but in how easy it is to stop after step two — the certificate is there, the site works, and half the resources still load over the old channel. A multilingual site does not complicate the procedure, it multiplies it: every language version has its own addresses to redirect one by one, and an omission stays invisible longest in the language nobody at the company reads day to day.

Who in the company is responsible for renewal

The question sounds trivial until the certificate expires on a Saturday.

With lifetimes cut to 200 days, renewal falls twice a year, and from 2027 almost four times. None of those dates will coincide with the moment someone happens to think about it. That is why the only sensible answer to "who renews it?" is: nobody, because an automated process does. If that is not the case for you, three things are worth establishing and writing down in one place:

• Where the certificate is issued — the hosting panel, an external vendor, a CDN. It happens that nobody in the company knows, because the site was set up by someone who has since left.
• Which email address receives the expiry notices. Very often it is the mailbox of a former employee or the address of a contractor from years ago.
• Who has access to the panel. Not "the web agency", but a named person with a password.

Those three answers take five minutes if you check them now, and a whole day if you look for them at the moment the site stops working.

Does SSL improve your Google ranking

It pays to be precise here, because two extremes circulate.

HTTPS is a ranking signal, and Google has confirmed that publicly — but a light one, working more as a tie-breaker between two equivalent results than as a lever. Adding a certificate to a site with no traffic will not bring it any.

The real damage from not having HTTPS is indirect and larger than any ranking effect: people leave when they see a warning. From October everyone will see that warning, so the indirect cost has just gone up. That is the reason to have a certificate — not the promise of higher positions.

When something does not work — a diagnosis in a few minutes

The three faults we find most often, three causes of a warning despite a valid certificate, and a four-minute test to run yourself.

Three SSL faults we find most often in audits

A certificate can be installed and still not work as it should. Three cases we see regularly:

A certificate on only one version of the address. The site has HTTPS on company.pl but not on www.company.pl — or the other way round. Some visitors land on a warning, and the search engine sees two versions of the same site, one of them unsecured.

Mixed content after migration. The site loads over HTTPS, but pulls images, fonts or scripts over HTTP — most often leftovers from the old address hard-coded into the content. The browser blocks some of them or shows a warning, while the owner thinks "the icon is there, so it's fine".

An expired certificate with no alert. Nobody set up a notification, so the first signal is a phone call from a customer who cannot get onto the site. With lifetimes cut to 200 days, that risk has exactly doubled.

We check all three in the technical layer of a website audit — and all three can be spotted on your own in a few minutes.

A warning despite a valid certificate — three causes

Sometimes the certificate is paid for, installed and in date, and the browser still shows a warning. Three causes account for most of these cases, and none of them requires buying anything.

A name mismatch. The certificate was issued for company.pl, but the site runs on shop.company.pl or on www. The browser compares the address with the list of names in the certificate and, if nothing matches, treats the connection as untrusted — however good the certificate itself is.

A missing intermediate certificate. The server certificate is signed by an intermediate one, which is signed by a root. If only the first was installed on the server, some browsers cope on their own and some do not — and then the site works on one device and shows a warning on another. It is the most misleading of the three, because it looks like a problem on the visitor's side.

A wrong clock on the visitor's device. A certificate has a start date and an end date. A computer set to the wrong date will judge a valid certificate invalid. If one person sees the warning and the rest of the world does not, this is what to check before changing anything on the server.

What the three have in common: the problem sits in the configuration, or outside your server, not in the product. Swapping the certificate for a more expensive one fixes none of them.

How to check your own certificate in a minute

Four checks, no tools needed:

1. Click the icon to the left of the address and check the certificate's expiry date. If there are fewer than thirty days left and you do not know who renews it — that is today's task.
2. Open the site without `www` and with `www`. Both versions should work over HTTPS, and one should redirect to the other.
3. Type the address beginning with `http://`. You should be redirected to HTTPS automatically.
4. Open a page with images and check that the security indicator looks the same as on the home page. A difference means mixed content.

If any of these four fails, the problem is in the configuration, not in the certificate itself — and it can usually be fixed without buying anything.