ZeroSSL vs Let's Encrypt: what actually differs

The differences are in the surrounding arrangement rather than in the certificate, and there are fewer of them than comparison pages imply.

Specific values (limits, certificate lifetimes, and what each tier includes) change over time and are read best from each authority's current documentation. Below are the classes of difference, which do not depend on those values.

What is the same

• The protocol

  Both support automated issuance through the same standard, so the same clients work with either, as covered on ACME clients. Switching between them is a configuration change rather than a change of process.

• The validation

  Domain validation, with the same challenge types and the same constraint that wildcards require the DNS method.

• Browser trust

  Both are in the trust stores. Trust is binary, and there is no gradation among authorities that are present.

• The certificate itself

  Same standards, same contents, same behaviour in every client.

So a comparison cannot be about certificate quality, and any that is described that way is describing something else.

Where the difference genuinely lies

Three areas, and they are matters of preference rather than of correctness.

• Account model

  One is designed to be used entirely by software, with no account concept a person interacts with. The other offers an account with a web interface where certificates can be seen and managed. Which is better depends on whether anyone wants to look: for a fully automated installation, the interface is unused; for a small team that occasionally needs to check something without command-line access, it is the deciding feature.

• Non-automated routes

  Where certificates are obtained through a web form rather than a client, that route exists in one and not the other. This matters for the same population that struggles with automation generally: devices, appliances, and setups where nothing can run a client.

• Commercial tiers alongside the free offering

  One is a non-commercial service with a single free offering; the other has paid tiers with additional features and support. That difference cuts both ways, as described below.

What the commercial tier changes

• In favour:

  a paid relationship provides someone obliged to respond, and paid tiers can include longer certificate lifetimes and organisation validation, which the free automated route cannot offer. Where a requirement names those, having them from the same provider is convenient.

• Against:

  a free offering that sits alongside paid tiers is subject to commercial decisions in a way that a service without them is not. Free tiers get restructured, and the incentive to move users towards paid plans exists by construction. This is the same consideration described on free certificates, and it applies here rather than to the non-commercial alternative.

Neither point is decisive. The first matters if you might need what the paid tiers provide; the second matters if you want the arrangement to be stable for reasons outside anyone's business model.

How to choose between them

Four questions, and most people can answer all four in a minute.

• Will a person ever need to see the certificates?

  If yes, an interface helps. If everything is automated and nobody logs in, it is irrelevant.

• Do you need a route that is not a client?

  Devices that cannot run one, or people who cannot use a command line, are served by a web-based issuance route where it exists.

• Might you need organisation validation or longer lifetimes later?

  Obtaining them from the same provider is simpler than adding a second one, though it is not difficult either way.

• Do you prefer a non-commercial arrangement?

  A legitimate preference, and the honest reason is stability of terms rather than any technical property.

If none of those distinguishes them for you, they are interchangeable, and the correct action is to use whichever your tooling already supports.

The comparison that matters more

Neither choice affects the failures you will have.

Certificate incidents come from incomplete chains, configurations never reloaded, automation that stopped silently, and names not covered. None of those depends on the authority, and all of them are covered elsewhere in this material. A setup with well-monitored automation on either authority is in a better position than a carefully chosen authority with unmonitored automation.

That is the argument for spending decision-making effort on renewal automation rather than on this page. The authority is a preference; the automation is the risk.

Switching between them

Cheap, and worth knowing because it removes the weight from the decision entirely.

Both speak the same protocol, so switching means pointing your client at a different issuance service and letting it obtain a certificate. The names stay the same, the client stays the same, and the server configuration does not change at all.

The one thing that differs is the chain, since it comes from whichever authority issued the certificate. Serving the previous authority's chain with the new certificate is the mistake to avoid, and it is the same mistake described on certificate chains. A client that installs the chain alongside the certificate handles this without anyone thinking about it.

There is no migration, no coordination, and nothing to plan. Whichever you choose, the choice is reversible at the next renewal, which is a good reason not to spend long on it.

Limits

Both apply rate limits, and both publish them. The classes are the same as described on rate limits: duplicates, per-domain caps, and a stricter allowance for failed validations.

Specific values differ and change, which is why they are not reproduced here. Where limits are a real constraint for you, read the current figures from the authority rather than from any comparison page, including this one.

Certificates as part of the stack with Bridge SSL

Bridge SSL obtains and renews certificates as part of serving your site, which makes this comparison an implementation detail rather than a decision you maintain. Where you need organisation validation or a contractual support relationship, that is a different requirement and the criteria on choosing an authority apply instead. See what Bridge offers at Bridge CDN.

FAQ