Is a free SSL certificate secure?

Every time someone discovers Let's Encrypt, the same suspicious question follows: "if it's free, it must be less secure, right?" The intuition is understandable — we pay for antivirus, for VPNs, for almost anything involving security — but in this case it is wrong. A free certificate from Let's Encrypt uses exactly the same cryptography as a 300-dollar-a-year certificate: the same TLS, the same RSA or ECC keys, the same SHA-256 in the fingerprint. The encrypted connection is byte-for-byte identical. What changes between free and paid is not the security of the connection — it is the type of validation the certificate authority performed before issuing it.

This article separates what a certificate actually guarantees from what it does not, explains the validation tiers (DV, OV, EV), and shows why, for the overwhelming majority of sites, paying for a certificate is a waste of money.

The cryptography is the same — always

When your browser opens an HTTPS connection, the TLS handshake happens: client and server negotiate an algorithm, exchange keys, and establish an encrypted channel. That process never checks how much you paid for the certificate. It uses the same cipher suites, the same key strength (2048-bit RSA or an elliptic curve like P-256), and the same hash function for signing.

The certificate itself is a document signed by the certificate authority that says, in essence: "the public key inside this file belongs to domain X." That signature is verified with asymmetric cryptography — if you want to understand why the CA signs with its private key and the browser validates with the public one, the piece on symmetric vs asymmetric cryptography is worth reading. The price of the certificate enters none of that math. A free certificate and a four-figure EV one produce the same level of protection on the wire.

DV, OV, EV: the difference is in the validation

If the crypto is identical, what are you buying when you pay? You are buying a more rigorous validation process from the certificate authority. There are three tiers:

• DV (Domain Validation) — the CA only confirms that you control the domain. This is what Let's Encrypt does, fully automated: it asks you to publish a token in a file on the server or in a DNS record, verifies it is there, and issues the certificate. It takes seconds.
• OV (Organization Validation) — beyond the domain, the CA verifies that the organization behind it actually exists: it checks public registries, sometimes calls the organization. It costs money and takes days.
• EV (Extended Validation) — the most expensive version, with a heavier audit of the legal entity.

The point almost nobody tells you: OV and EV add nothing to the cryptography. The key, the handshake, and the hash are identical to free DV. What you pay for is the CA's human diligence in checking your company's documents — information that, in practice, ends up in a certificate field that practically no visitor ever opens to read.

What a certificate guarantees (and what it does not)

A valid certificate guarantees two concrete things:

1. The connection is encrypted. Nobody on the path — your ISP, a public Wi-Fi network, an intermediary — can read or alter what travels through it.
2. You are talking to the owner of that domain. The CA attested that whoever presents the certificate controls example.com, so you did not land on an impostor that hijacked the route.

And here comes the most dangerous misunderstanding. A certificate does not guarantee that the site is honest. A scammer can register your-bank0.com, request a free Let's Encrypt certificate in thirty seconds, and have a perfect green padlock. Their HTTPS is technically flawless — the connection is encrypted and they really do own that phishing domain. The padlock was never a trust seal for the content; it is only proof that the channel is secure and that the domain is who it claims to be.

This is exactly why browsers abandoned the visual prominence of EV. For years, Chrome and Firefox showed the company name in green in the address bar for EV certificates. Studies showed nobody looked, nobody understood it, and the signal did not reduce phishing. Today every certificate shows the same neutral padlock. The visual differentiator companies paid for simply vanished.

Automatic renewal and the 90-day cycle

HTTPS's biggest historical friction was renewing the certificate before it expired — anyone who forgot has watched their site go down with an expired-certificate error. Let's Encrypt solved this with a deliberately short term: 90 days. Too short to do by hand, which forces automation.

The standard tool is certbot. A typical renewal is a single scheduled task:

# Renews any certificate within 30 days of expiring
certbot renew --quiet

Drop that into a cron job or a systemd timer running once a day and never think about it again. Certbot only acts when the certificate is near expiry, reloads the server on its own, and moves on. The short cycle, far from being a flaw, is a security advantage: if a key is compromised, the exposure window is smaller.

The chain of trust is what matters

What actually gives a certificate its value is not the price — it is the chain of trust. Your certificate is signed by an intermediate, which in turn is signed by a root CA whose public key already ships embedded in the operating system and the browsers. Validation walks that chain until it reaches a trusted root:

Your site's certificate (leaf)
   └─ signed by the Intermediate CA
        └─ signed by the Root CA  ← trust pre-installed in the browser

Let's Encrypt has had its roots and intermediates in every relevant trust store since 2016. That is why the free certificate is accepted everywhere, with no warning. Trust comes from that cryptographic chain, not from how much you spent.

It is worth noting that the whole chain rests on hash functions: each certificate's fingerprint is a SHA-256, and the CA's signature is computed over the certificate's hash, not over the whole file. If you want to see in practice how a hash works — and why changing a single byte changes the entire digest — generate one with a hash generator and compare. Understanding the certificate fingerprint becomes much more concrete after that.

Frequently asked questions

Is a free Let's Encrypt certificate as secure as a paid one?

Yes, as far as the connection's cryptography goes. The TLS handshake, the key strength (RSA 2048 or ECC), and SHA-256 are identical. A paid certificate only adds a more rigorous validation of the company behind the domain, not a stronger cipher. For 99% of sites, there is no practical security difference.

Why would anyone pay for an SSL certificate then?

Legitimate cases are few: a financial institution that needs OV for regulatory reasons, or a company that wants contractual support and a financial warranty from the CA. Otherwise, paying for a DV — which is exactly what Let's Encrypt gives away for free — is throwing money away. EV, in turn, has lost even the visual prominence that justified the cost in browsers.

Does the green padlock mean the site is trustworthy?

No. The padlock means only two things: the connection is encrypted and the site really owns that domain. A phishing site can have a perfect padlock, because it also controls its own fraudulent domain. Trusting a site's content is a separate decision — check the domain name, not the padlock.

Do I need to renew the certificate manually every 90 days?

No, and you should not. Let's Encrypt's short cycle exists precisely to force automation. Set up certbot renew in a daily cron job and renewal happens on its own when fewer than 30 days remain before expiry. You only touch the topic if the automation breaks.

The verdict

For 99% of sites, Let's Encrypt is the right choice, full stop. The cryptography protecting your visitors is the same as any paid certificate — TLS, RSA or ECC, SHA-256 — and trust comes from the chain of CAs, not from the size of the invoice. Paying for a DV is waste; EV has lost the only visual differentiator it had. Set up certbot, leave automatic renewal running, and spend your security budget on something that actually moves the needle, like strong authentication and logging. The padlock is the floor of security, never the ceiling.