ZeroSSL vs Let's Encrypt: what actually differs
ZeroSSL and Let's Encrypt both run ACME servers that issue certificates at no charge, wildcards included, so an ACME client that supports external account binding works with either [2][7]. The difference sits in front of the endpoint. ZeroSSL accepts an ACME account only with external account binding credentials from a ZeroSSL account, keeps each certificate in that account and sells paid plans next to the free service; Let's Encrypt is a nonprofit, and its account is normally created by your ACME client [2][4][7][9]. For the criteria that apply to any authority, see the criteria for choosing a certificate authority.
| Item | Let's Encrypt | ZeroSSL |
|---|---|---|
| ACME account | usually created automatically by the ACME client [4] | needs external account binding credentials from the ZeroSSL dashboard [7] |
| Certificates through ACME | no fee; wildcards through the DNS-01 challenge [2] | no charge; multi-domain and wildcard certificates [7] |
| Other routes | none, an ACME client only [3] | web interface and REST API [8][11] |
| Certificate profiles | selectable in ACME, listed in the directory [5] | none listed in the directory [16] |
| Support | documentation and community forums, no direct support [2] | free plan self-service only; paid plans list support [9] |
| OV and EV | not offered, no plans [2] | in the enterprise offering, as certificates by HID Global [9] |
What the two ACME directories show
An ACME directory is the JSON document a client reads first, and RFC 8555 gives it a meta object with metadata about the service [1]. We read both directories and compared the fields:
$ curl -s https://acme-v02.api.letsencrypt.org/directory | jq -c '.meta | keys'
["caaIdentities","profiles","termsOfService","website"]
$ curl -s https://acme.zerossl.com/v2/DV90 | jq -c '.meta | keys'
["caaIdentities","externalAccountRequired","termsOfService","website"]externalAccountRequired set to true means every new account request must carry an externalAccountBinding field [1]. ZeroSSL's directory sets it; Let's Encrypt's directory does not have the field [16]. We then sent each server one account request with neither the binding nor agreement to the terms. ZeroSSL refused it with the error type externalAccountRequired; the Let's Encrypt staging server refused it with must agree to terms of service [16]. Neither created an account.
caaIdentities lists the names a server recognizes as its own in CAA records [1]. Let's Encrypt lists letsencrypt.org. ZeroSSL lists seven names, starting with sectigo.com, and its directory links a Sectigo certificate subscriber agreement as its terms of service [16]. Both directories carry renewalInfo, the endpoint through which an ACME server suggests when to renew, defined in RFC 9773 [14][16].
Where Let's Encrypt is stronger
No account step outside ACME. The ACME client normally creates the account, and the account ID is a URL you can find in its logs [4]. Nothing has to be generated in a dashboard first.
No fee and no paid tier. Let's Encrypt is a nonprofit and does not charge for its certificates [2].
Profiles. A client can ask for a certificate profile, and the profiles differ in validity period and other properties;
classicapplies when the order names none [5]. Not every ACME client can select a profile yet [5].Published rate limits. They exist to ensure fair usage and are designed so that renewing a certificate almost never hits one; a large hosting provider can request higher limits through a form [6].
Where ZeroSSL is stronger
A place to see certificates. Each certificate created through ZeroSSL's ACME service is stored in the ZeroSSL account, and its partner ACME clients let you track automatically created certificates from the dashboard [7].
Issuance without an ACME client. The web interface validates a domain by email, a file uploaded to the server or a CNAME record [11], and the REST API automates the actions the interface supports [8].
Paid options from the same vendor. On ZeroSSL's pricing page the free plan is self-service only, while the paid plans add support and certificates beyond the ACME ones [9]. OV and EV certificates sit in its enterprise offering [9]; Let's Encrypt has no plans to issue them [2].
Where a policy names OV or EV, or a contract has to name someone obliged to answer, those are the cases that warrant an alternative to Let's Encrypt in the first place.
Moving an ACME client between them
Both servers speak RFC 8555, and a client needs only the directory URL to find the rest [1]. Moving between them is a matter of settings, and ACME clients expose them as options:
Point the client at the other directory. Certbot takes
--serverand uses the Let's Encrypt directory when none is given [13]. acme.sh takes--server letsencryptor--server zerossl[12].For ZeroSSL, supply EAB credentials. Generate them in the Developer section of the ZeroSSL dashboard or through its API. ZeroSSL does not store them in the account, so note them [7]. Certbot passes them as
--eab-kidand--eab-hmac-key[13]. acme.sh can also register with ZeroSSL by email address [12].Allow the new authority in CAA. If your domain publishes CAA records, an authority must not issue unless the request is consistent with them or its CP or CPS names an exception [15]. Add a record with a name from the new directory's
caaIdentities, such asletsencrypt.orgorsectigo.com[1][16].Install the chain that came with the new certificate. By default ACME returns the certificate followed by its issuer certificates [1]. An intermediate kept from the old authority no longer matches, the case described under certificate chains.
Rate limits and terms
Let's Encrypt publishes its rate limits on a page of their own and names a form for raising them [6]. ZeroSSL's ACME feature page says "No Rate Limits" [10]; its ACME documentation asks clients to use the API "in a meaningful way", says malicious users can be limited or blocked, and caps how many EAB credentials a user can generate per day [7]. The figures are left out here because they change; read them where each authority publishes them.
Each directory also links the terms of service a new account agrees to: Let's Encrypt's own, and for ZeroSSL a Sectigo certificate subscriber agreement [1][16].
What decides it
Each of these points to one of the two:
No person should touch the account. Let's Encrypt needs nothing outside ACME; with ZeroSSL someone generates a reusable set of EAB credentials, or acme.sh registers by email [4][7][12].
Someone needs a web interface, or a device cannot run a client. ZeroSSL has both routes; at Let's Encrypt every certificate goes through an ACME client [3][8][11].
You may need OV, EV or support from the same vendor later. ZeroSSL sells them; Let's Encrypt does not offer them [2][9]. Beyond these two, the field is commercial SSL certificate providers.
You want to choose a certificate profile. Let's Encrypt offers profiles through ACME [5].
You already run acme.sh. From acme.sh v3.0 its default CA is ZeroSSL, where earlier versions used Let's Encrypt [12], and ZeroSSL says it owns acme.sh [10]. Check which server your installation uses before you compare.
If none of these separates them, keep the authority your client already uses. A renewal that stopped running, a configuration that was never reloaded and an incomplete chain fail the same way under either authority. What SSL certificate pricing pays for in the first place is a separate question.
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 [17]. The issuing authority is the platform's decision, not a setting, and there is no certificate upload [17]. If your compliance regime names a specific authority, that requirement and this layer do not fit together [17]. Current terms live where signup does, on Bridge CDN.
FAQ
What is the difference between ZeroSSL and Let's Encrypt?
ZeroSSL needs external account binding credentials from a ZeroSSL account, keeps certificates in a dashboard, also issues through a web interface and a REST API, and sells paid plans with support. Let's Encrypt is a nonprofit with no fee, an account created by the ACME client and selectable certificate profiles. Both issue through ACME at no charge, wildcards included. [7][11][8][9][2][4][5]
Do I need a ZeroSSL account to use its ACME server?
Can I use Certbot with ZeroSSL?
Yes. Give Certbot ZeroSSL's directory URL with --server and the EAB credentials with --eab-kid and --eab-hmac-key. Without --server, Certbot uses Let's Encrypt. [13]
Does acme.sh use ZeroSSL by default?
Yes, from acme.sh v3.0; earlier versions defaulted to Let's Encrypt. Choose explicitly with --server letsencrypt or --server zerossl. [12]
Sources
RFC 8555, Automatic Certificate Management Environment (ACME): §7.1.1 directory metadata, §7.3.4 external account binding, §7.4.2 and §9.1 certificate format.
Let's Encrypt, FAQ: cost, nonprofit, support, OV and EV, wildcards.
Let's Encrypt, Getting Started: issuance through an automated API based on ACME, an ACME client required.
Let's Encrypt, Finding Account IDs.
Let's Encrypt, Profiles.
Let's Encrypt, Rate Limits.
ZeroSSL, ACME documentation: no charge, wildcards, storage, partner clients, EAB credentials.
ZeroSSL, REST API documentation.
ZeroSSL, Pricing: plans, support, ACME on all plans, enterprise certificates.
ZeroSSL, ACME Automation feature page.
ZeroSSL, home page: validation by email, server upload or CNAME.
acme.sh wiki: Change default CA to ZeroSSL; Server; ZeroSSL.com CA.
Certbot, command-line options:
--server,--eab-kid,--eab-hmac-key.RFC 9773, ACME Renewal Information (ARI) Extension.
RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record: §3.
Our run: both ACME directories read with curl and jq; one account request without binding or terms agreement sent to ZeroSSL and to the Let's Encrypt staging server. No account, order or certificate was created.
Bridge SSL, home page: introduction and Covers; Zero for the certificate; Four things this deliberately does not do; Where Bridge SSL sits.