ACME CA Comparison – A Technical Overview

As the ACME protocol matures, a growing number of public certificate authorities (CAs) have joined the ecosystem, each offering free TLS certificates with slightly different capabilities. For operators who automate certificate issuance—whether for web services, internal APIs, or experimental projects—understanding these nuances is essential to avoid surprises in production.

---

1. Core Data Sheet

Feature	Let’s Encrypt	Google	ZeroSSL	SSL.com	Actalis
Free SAN limit	100 names	100+ names	100+ names	1 name + www	1 name + www
Wildcard support	✅ Free	✅ Free	✅ Free	❌ (paid only)	❌
Certificate lifetime	90 days (default)	1–90 days (default 90)	90 days	90 days	90 days
IDN support	✅	✅	✅	✅	✅
Chain type	RSA Iss/Root, ECC Iss/Root	RSA Iss/Root, ECC Iss/Root	RSA Iss/Root, ECC Iss/Root	RSA Iss/Root	RSA Iss/Root
Rate‑limit policy	Published limits (e.g., 50 certs per domain per week)	Published limits, similar to Let’s Encrypt	Published limits, but undocumented for some endpoints	Limited documentation, some undocumented errors	Limited documentation
Staging environment	Yes (dedicated endpoint)	Yes (dedicated endpoint)	Yes (dedicated endpoint)	Yes (dedicated endpoint)	Yes (dedicated endpoint)
External Account Binding (EAB)	Not required	Required*	Required	Required	Required (EAB)
Multi‑perspective validation	✖	✖	✖	✖	✖
SXG (Signed HTTP Exchanges) support	✖	✅ (separate directory)	✖	✖	✖
Account key rollover	✅	✅	✖	✖	✖
Account deactivation	✅	✅	✖	✖	✅ (cosmetic only)
Pre‑authorization	✅	✅	✖	✖	✖
Authorization deactivation	✅	✅	✖	✖	✅ (cosmetic)
Certificate revocation	✅	✅	✅	✅	✅
Challenge retrying	✅ (client‑initiated)	✅ (client‑initiated)	✖ (no retry)	✖ (no retry)	✖ (no retry)
Variable certificate lifetime	✖	✅ (down to 1 day)	✖	✖	✖
ACME Renewal Information (ARI)	✅	✅	✖	✖	✖

*Google’s EAB credentials are single‑use and expire after seven days if not consumed.

---

2. Interpreting the Numbers

2.1 SAN Limits and Wildcards

A "Subject Alternative Name" (SAN) limit determines how many distinct hostnames can be covered by a single certificate. Let’s Encrypt caps this at 100, which is sufficient for most multi‑tenant SaaS platforms. ZeroSSL and Google push the limit beyond 100, but the practical effect is minimal because wildcards count as a single SAN entry. When a CA advertises "1 name + www," it implicitly allows the apex domain and its www sub‑domain, simplifying configuration for small sites.

2.2 Certificate Lifetime

The 90‑day default remains the industry norm because it reduces the impact of a compromised key. Google’s ability to issue certificates as short as one day is useful for automated testing pipelines that need to validate short‑lived identities without waiting for renewal. However, the recommended minimum of three days prevents excessive churn on the CA’s backend.

2.3 Chain Composition

All listed CAs provide both RSA and ECC chains, giving administrators the freedom to select a key algorithm that matches their performance and security requirements. ECC chains are especially valuable for constrained environments (e.g., IoT devices) where smaller signatures reduce bandwidth.

---

3. Optional ACME Features and Their Operational Impact

3.1 External Account Binding (EAB)

EAB is a mechanism that ties an ACME account to an external identity, typically used by CAs that want to enforce additional vetting (e.g., Google). While Let’s Encrypt skips this step, Google, ZeroSSL, SSL.com, and Actalis require it. The practical consequence is that automation scripts must be provisioned with the appropriate EAB credentials before they can create an ACME account. For Google, the credentials are single‑use and must be regenerated after a week, which adds a small operational overhead.

3.2 Account Key Rollover and Deactivation

Key rollover allows a CA to replace the account private key without losing existing authorizations. Let’s Encrypt and Google support this, which is useful when a key is suspected of compromise. SSL.com and ZeroSSL lack this capability, meaning a compromised account key forces the operator to create a fresh account and re‑authorize all domains—a non‑trivial task at scale.

3.3 Pre‑Authorization and Authorization Deactivation

Pre‑authorization lets a client request validation for a domain before actually ordering a certificate, enabling parallel workflows. Let’s Encrypt and Google expose this, while the other CAs do not. Deactivation of an authorization is a safety net that prevents accidental reuse of stale challenges; only Actalis implements this in a cosmetic fashion, which may mislead users into thinking a failed challenge will be retried automatically.

3.4 Challenge Retrying

When a validation attempt fails, the client can request a retry. Let’s Encrypt and Google allow this, but ZeroSSL, SSL.com, and Actalis do not—failed challenges remain in a terminal state. This difference matters for environments with flaky DNS or HTTP servers; the ability to programmatically retry reduces manual intervention.

---

4. Special Cases: IP‑Address Certificates and SXG

4.1 IP‑Address Identifiers

Most public CAs forbid certificates that contain raw IP addresses, but Google and ZeroSSL provide limited support. Google only issues them under a short‑lived profile and after a business justification, while ZeroSSL supports them outside the ACME flow. If your infrastructure uses IP‑based endpoints (e.g., internal load balancers), you will need to evaluate whether the extra administrative steps are justified.

4.2 Signed HTTP Exchanges (SXG)

SXG enables browsers to serve signed versions of web pages from a CDN, improving performance and privacy. Google is the only CA in this comparison that offers SXG certificates, and it requires a dedicated directory endpoint (https://dv-sxg.acme-v02.api.pki.goog/directory). For projects that aim to leverage SXG, the choice of CA is forced, and the implementation must handle the separate endpoint.

---

5. Practical Recommendations

1. General‑purpose automation – Let’s Encrypt remains the most straightforward choice: no EAB, mature client ecosystem, clear rate‑limit documentation, and full support for key rollover.
2. Wildcard‑heavy deployments – ZeroSSL matches Let’s Encrypt on wildcard support while offering a higher SAN ceiling; however, be prepared for occasional undocumented API quirks.
3. Short‑lived testing certificates – Google’s variable lifetime feature is ideal for CI pipelines that need certificates lasting only a few days.
4. Enterprise environments needing EAB – If your organization already has a relationship with Google or SSL.com, the extra EAB step can be integrated into your provisioning pipeline, but remember the single‑use nature of Google’s credentials.
5. SXG projects – Google is the sole provider; adopt its dedicated directory and be aware of the additional validation requirements.

---

6. Caveats and Open Questions

• Rate‑limit opacity – SSL.com and Actalis publish only limited information about request throttling, which can cause unexpected failures during bulk issuance.
• Retry behavior – The lack of explicit retry mechanisms in ZeroSSL, SSL.com, and Actalis means operators must implement their own back‑off logic, increasing client complexity.
• Future deprecation – The removal of Buypass from the list (October 2025) illustrates how quickly the free‑ACME landscape can change; regular audits of the comparison table are advisable.

---

7. Conclusion

While the core promise of ACME—automated, free TLS certificates—remains consistent across providers, the secondary features, limits, and operational requirements differ enough to influence architectural decisions. By aligning the specific needs of a deployment (wildcards, short lifetimes, EAB, SXG, or IP‑address support) with the capabilities outlined above, engineers can select the CA that minimizes friction and maximizes security.