Standards & RFC support
Certeasy implements the IETF ACME family of standards. This page documents which parts of each RFC are supported today, which are partial, and which are planned. Use it when auditing Certeasy against a compliance requirement or before integrating an ACME client that depends on a specific feature.
RFC 8555 — ACME core protocol
Status: Supported with known gaps documented below.
| Feature | RFC § | Status |
|---|---|---|
| Account create / contact update / key change / deactivate | §7.3 | ✅ |
newOrder and order state machine | §7.4 | ✅ |
| Authorization + challenge dispatch (HTTP-01, DNS-01, TLS-ALPN-01) | §7.5, §8 | ✅ |
finalize + CSR validation | §7.4 | ✅ |
revoke-cert signed with account key | §7.6 | ✅ (server-side — see limitations) |
Wildcard issuance (*.zone, mixed zone + *.zone in one order) | §7.1.4, §8.4 | ✅ |
Location headers and response URLs canonicalization | §7.4 and following | ✅ |
| External Account Binding (EAB) | §7.3.4 | 🔴 not supported in V0.9 / V1.0 — planned for V2.0 |
Known limitations
Server-side revocation only (full propagation planned for V1.0)
POST /acme/revoke-cert marks the certificate revoked in Certeasy's database and emits an audit event. The underlying ADCS CRL / OCSP responder is not yet updated — a client validating chain status against ADCS will still see the certificate as valid until the CRL is published. Cabling the revocation all the way to ADCS (certreq -revoke) lands in V1.0.
External Account Binding (EAB) — planned for V2.0
EAB lets you bind a new ACME account to an out-of-band identity (HMAC key shared via your provisioning system). Useful for multi-tenant DevOps deployments where each team is given its own credentials. Not implemented in V0.9 / V1.0 — single-tenant enterprise deployments do not need it. Tracked on the roadmap for V2.0.
RFC 9773 — ACME Renewal Information (ARI)
Status: Partial — read-only ARI is supported, the replaces hint is silently accepted.
| Feature | RFC § | Status |
|---|---|---|
renewalInfo directory entry | §3 | ✅ |
GET /acme/renewal-info/<certID> with suggested window + Retry-After | §4 | ✅ |
newOrder.replaces validation + persistence + renewalInfo window collapse on the replaced cert | §5 | 🟡 field accepted silently — full semantics planned for V1.1 |
Known limitations
replaces semantics (planned for V1.1)
ARI-aware clients (recent lego, certbot) can send newOrder.replaces without seeing a 400 malformed — Certeasy accepts the field. However the server does not yet:
- Reject duplicate
replaceswith409 alreadyReplaced. - Persist the
old_cert → new_certlink. - Collapse the replaced certificate's
renewalInfowindow to force renewal of other clients holding the old cert.
In a single-instance deployment this is invisible. In multi-instance or HA deployments the full ARI benefit is reduced until the semantics ship.
RFC 5280 — X.509 certificates
Status: Supported.
- Issued certificates carry the Subject Alternative Name extension only, with DNS names from the validated authorizations.
- The Subject Common Name field is intentionally left empty. This follows the CA/Browser Forum baseline since 2019: modern TLS clients (Chrome, Firefox, Go ≥ 1.15, Java ≥ 11) validate against SAN, not CN. Legacy clients that still require a CN-based match may need adjustment.
- Extended Key Usage:
serverAuthonly.clientAuth,codeSigning,anyPurposeand other EKUs are never set, even if requested by the client's CSR. Certificates issued by Certeasy are TLS server certificates — never reusable for AD authentication, SMB signing, or other server-side roles. The strict EKU policy can be relaxed per-policy viacsr.allowed-extra-ekuif a specific client (e.g. acme.sh) declares additional EKUs in its CSR. - Signature algorithms: configurable allow-list per policy, default minimum RSA 3072-bit, ECDSA P-256 and above.
Roadmap
The remaining gaps on this page are tracked in the public roadmap and target the next minor releases. Subscribe now (Pro, Enterprise) to lock the price while features ship progressively.