Bridge SSL
How to choose a certificate authority: the criteria
Choosing a certificate authority comes down to three questions: how issuance fits your process, which validation levels you can obtain, and what you can rely on when something fails. Encryption is not on the list: the client and the server negotiate it in the handshake, and the certificate authenticates the server [2]. Trust is not on it either, because Mozilla and Google each decide for their own root store [4]. Any publicly trusted authority can be read against the six criteria below.
| Criterion | What to check | Where it is defined |
|---|---|---|
| Automation | Whether the authority runs an ACME server your client can use | RFC 8555 [1] |
| Validation level | The policy identifier a certificate carries: domain or organisation validated | Baseline Requirements §7.1.2.7 [3] |
| Challenge type | Whether you can answer it; wildcards at Let's Encrypt need DNS-01 | Let's Encrypt FAQ [6] |
| CAA | The name to list in CAA records, if you publish them | RFC 8555 §7.1.1, RFC 8659 [1][5] |
| Revocation | The revokeCert route and which key may sign the request | RFC 8555 §7.6 [1] |
| Support and terms | Documented support, and the terms an account agrees to | Provider documentation [6][8] |
What does not differ, and what to ignore
The handshake settles the encryption: the client lists the cipher options it supports, and the server proves its identity with a certificate [2]. We checked two live certificates, one domain validated and one organisation validated:
$ openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -brief </dev/null 2>&1 | grep '^Protocol version'
Protocol version: TLSv1.3
$ openssl s_client -connect www.microsoft.com:443 -servername www.microsoft.com -brief </dev/null 2>&1 | grep '^Protocol version'
Protocol version: TLSv1.3Both connections negotiated TLS 1.3. The certificates differ in what they say about the owner. The domain-validated one has only a common name in its subject and the policy identifier 2.23.140.1.2.1. The organisation-validated one adds country, state, locality and organisation, and carries 2.23.140.1.2.2 [3][12].
Two kinds of claim are not worth weighing:
That one certificate authority encrypts better. Cipher options come from the client and the choice is made in the handshake [2]; the certificate authenticates the server [2].
A browser-support percentage. Mozilla and Google each decide inclusion for their own root store [4]. Ask which stores your visitors use, not for a single figure.
Automation: the criterion to settle first
ACME certificate issuance is the part of the process you repeat, and it is getting more frequent: the maximum validity of publicly trusted certificates is scheduled to fall in steps from 398 days to 47 days between March 2026 and March 2029 [10]. RFC 8555 describes a protocol that a CA and an applicant can use to automate verification and certificate issuance [1]. A certificate authority without an ACME server leaves you with a manual task at every renewal, and renewals come sooner as the maximum validity shortens [10].
Three things to confirm:
The authority publishes an ACME directory. Clients need only that URL to find the rest of the server [1].
Your setup can answer the challenge. Domain validation runs through a challenge, and Let's Encrypt issues wildcard certificates only through DNS-01, which means a client that can change your DNS records [6].
The account step fits your process. Some servers require external account binding before an account exists; that is a property of the server, visible in its directory [1].
Validation levels
Which validation levels a certificate authority offers is part of the choice. Domain validation covers the name. Organisation validation adds checked organisation details to the subject, and the Baseline Requirements give each type its own policy identifier [3]. The requirement that decides it comes from outside the technical setup: a contract or a compliance regime that names organisation validation. Where none does, a domain-validated certificate answers the question. Let's Encrypt says it offers domain-validated certificates and has no plans to issue OV or EV [6]. The certificate types page covers what each type contains. If your requirement names OV, that criterion narrows the list before any other does, and the list of situations that justify an alternative to Let's Encrypt is covered below.
Support, terms, revocation and paying
Support differs in kind. Let's Encrypt states that it cannot offer direct support to subscribers and points to documentation and community forums [6]. ZeroSSL's pricing page marks one plan Self Service Only and lists Basic Support on others [8]. An ACME directory can also carry a termsOfService URL, the terms a new account agrees to [1]; read them before the first request.
Settle revocation before you need it. A revocation request can be signed with the account key pair or with the key pair in the certificate [1], so decide which key you would have at hand during an incident.
In this comparison, price changes the picture in two cases: a requirement names organisation validation, or you need a party under contract to answer. Otherwise the criteria above do not move with the price. What money does and does not buy is on a page of its own.
What changes when you switch
The steps are those of a renewal with different settings.
The chain. It comes from the new authority; install it with the new certificate. Certificate chains explains the mismatch to avoid.
CAA. If your domain publishes CAA records, an authority must not issue unless the request fits them or an exception in its policy applies [5]. Add the name from the new directory's caaIdentities list [1].
Organisation validation. The subject fields of an OV certificate are verified by the issuing authority [3], so expect a new authority to verify them again.
How to evaluate one before committing
Read the directory.
curl -s <directory-url>returns the metadata: terms of service, CAA names, and whether external account binding is required [1].Look at a certificate the authority already issued.
openssl x509 -noout -subject -ext certificatePolicieson the certificate file shows the subject fields and the policy identifier [3].Check your own CAA records, if you publish any:
dig +short CAA example.com[5].Find the written revocation route and the support channel in the provider's documentation [6][8].
Read how it publishes its limits. Let's Encrypt keeps a rate limits page [7]. Ask other providers where theirs is.
Confirm you can leave. Switching follows the steps above, so test it on one name before you depend on it.
Where authorities are compared here
Here we compare certificate authorities by stating strengths first; the facts stay on the child pages.
ZeroSSL vs Let's Encrypt covers the account, the web interface and the plans: Let's Encrypt is a nonprofit and does not charge a fee for its certificates [6], while ZeroSSL's ACME server requires external account binding credentials from its dashboard [9].
The Let's Encrypt alternative page lists the situations that justify looking elsewhere.
Beyond these two authorities the field is commercial SSL certificate providers, and what they charge for is set out under the cost of SSL certificates.
Who writes these pages and how they are checked is described in About Bridge SSL: who writes this, and how it is checked.
Bridge SSL and the choice of authority
Bridge SSL is the certificate layer of Bridge CDN. Domain-validated certificates, and the *.example.com wildcard when the domain's DNS is on Bridge DNS, are issued and renewed automatically where your site is served [11]. The issuing authority is the platform's decision, not a setting, and there is no certificate upload [11]. If your compliance regime names a specific authority, that requirement and this layer do not fit together [11]. Current terms live where signup does, on Bridge CDN.
FAQ
Does the certificate authority affect security?
No. The client and server negotiate the encryption in the handshake, and the certificate authenticates the server. What the authority changes is how you obtain, renew and revoke the certificate. [2]
Does the price of a certificate change browser trust?
Not by price. Mozilla and Google each decide for their own root store, so what matters is whether the authority is in the stores your visitors use. [4]
Sources
RFC 8555, Automatic Certificate Management Environment (ACME): abstract, §7.1.1 directory metadata, §7.3.4 external account binding, §7.6 revocation.
RFC 8446, TLS 1.3: §1 authentication, §4.1.2 cipher_suites.
CA/Browser Forum, Baseline Requirements: §7.1.2.7 subscriber certificate types and policy identifiers.
Mozilla Root Store Policy: §7.3 removals. Chrome Root Program Policy: Google includes or removes certificates in the Chrome Root Store at its sole discretion.
RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record: §3.
Let's Encrypt, FAQ: no fee, nonprofit, support, OV and EV, wildcard issuance.
Let's Encrypt, Rate Limits.
ZeroSSL, Pricing: plans and support.
ZeroSSL, ACME documentation: external account binding credentials.
CA/Browser Forum, Ballot SC-081v3: schedule of reducing validity periods.
Bridge SSL, home page: introduction, "You cannot bring your own certificate", "You cannot choose the authority".
Our run: two TLS handshakes read with openssl, no certificate issued (lab/run1.txt).