How to choose a certificate authority: the criteria

What it is about instead: how issuance fits your process, which validation levels you can obtain, and what you are owed when something goes wrong. Those three, in that order, decide almost every case.

What does not differ

• The encryption

  Determined by the protocol and the server configuration, not by who signed the certificate.

• Browser trust

  Any authority in the trust stores produces no warnings. Trust is binary: an authority is either present or it is not, and there is no gradation among those present.

• The certificate contents

  The names, the validity period, and the signature all follow the same standards. A domain-validated certificate from one authority contains what a domain-validated certificate from another contains.

If a comparison leans on any of these, it is comparing things that are identical and describing the difference as a feature.

The criteria that decide

• Automation

  Whether issuance and renewal happen through a protocol your tooling already speaks, described on ACME. This is the criterion with the largest practical effect, because it determines whether certificates are a recurring task or a solved problem. An authority without automated issuance imposes a manual process several times a year, at current certificate lifetimes.

• Validation levels available

  Whether you can obtain organisation validation where a requirement names it, covered on certificate types. Automated issuance handles domain validation; organisation validation involves human checks and not every authority offers it.

• Support and accountability

  Whether someone is obliged to respond when issuance fails or a certificate must be revoked urgently. Free automated issuance provides documentation and community; a commercial relationship provides an obligation. Which you need depends on what a failure costs you.

• Terms and warranties

  Contractual commitments that exist in paid arrangements and not in free ones. Their practical value is debatable and their absence is a real difference in what you hold.

• Operational limits

  Rate limits apply everywhere and differ in shape. They matter only at scale or when something misbehaves, and the mechanics are on rate limits.

What to ignore

Three criteria that appear in comparisons and answer nothing.

• Encryption strength claims

  No authority provides stronger encryption than another. Such claims describe the protocol, which is your server's configuration rather than theirs.

• Browser compatibility percentages

  An authority is in the trust stores or it is not. A percentage expresses that binary fact in a form designed to look like a difference.

• Warranty amounts

  A headline number, structured so that claiming is rare. If one matters to you, the terms decide it, not the figure.

Free versus paid, framed honestly

The question underneath most comparisons, and it has a short answer for most cases.

Free automated issuance from a publicly trusted authority is the correct default. It runs most of the encrypted web, produces certificates identical in every way a visitor experiences, and carries the automation that current lifetimes require. The full argument is on free certificates.

Paying is correct in three situations: a requirement names organisation validation, you need someone contractually obliged to respond, or a device cannot be automated and needs a longer-lived certificate. Outside those, the case for paying rests on things that do not differ.

The criterion nobody lists: how long the authority has been trusted

Trust stores are conservative, and that conservatism is a property worth understanding when an unfamiliar authority appears.

Entering browser and operating system trust stores takes years of audits and operational history; removal takes considerably less once serious problems are found. A long-present authority has survived that scrutiny, while a very new one has cleared the initial bar and not yet been tested by time.

This matters in one specific way, and not because of the certificates themselves. Where an authority is distrusted, every certificate it issued stops being accepted and every site holding one must replace it, on a vendor's timeline rather than anyone's convenience. That has happened before, to authorities large and well established at the time.

The response is not to avoid newer authorities, which would be unfair and unnecessary. It is to keep replacement cheap: with automated issuance an emergency reissue is a routine operation rather than a project, which turns an authority-level incident from a crisis into an afternoon. Automation is not primarily about convenience; it is what makes every certificate decision reversible.

What changes when you switch

Less than people expect, and knowing this removes most of the weight from the choice.

A certificate from a different authority installs exactly like a renewal from the current one: same names, the key old or new as you prefer, and a server configuration that does not care who signed it. Only the chain differs, since it comes from the new authority, and serving the old chain with the new certificate is the mistake to avoid, as described on certificate chains.

Where automation exists, switching is a configuration change in the client. Where it does not, it is the same manual work as any renewal, which argues for automating before choosing rather than after.

Two things do not travel. Any organisation validation must be performed again by the new authority, which takes time and documentation. And anything you configured to restrict which authorities may issue for your domain has to be updated, or the new authority will be refused by its own compliance check.

How to evaluate one

Four checks, answerable before committing anything.

• Does it automate the challenge you need?

  Wildcards require a client able to change your DNS, which narrows both the authority and the tooling.

• How long does issuance take at worst?

  Domain validation takes seconds; organisation validation involves human steps and a timeline worth knowing before you depend on it.

• How do you revoke urgently?

  The route and its speed matter more than any feature, and both are worth establishing before an incident.

• Can you leave?

  Certificates are short-lived and replaceable by definition, so switching is cheaper here than in most infrastructure decisions, and reversible at the next renewal.

Where authorities are compared here

Provider by provider, with what each does differently rather than a score: Let's Encrypt and ZeroSSL.

Both follow the same rule as this page: strengths stated first, differences presented as properties and never as verdicts, and nothing resting on claims that cannot be checked.

Certificates as part of the stack with Bridge SSL

Bridge SSL issues and renews certificates as part of serving your site, so the choice of authority becomes an implementation detail rather than a decision you operate. The criteria on this page still apply to the arrangement: automation is the point, validation levels are what they are, and what happens when something fails is worth asking about before it does. See what the platform offers at Bridge CDN.

FAQ