Skip to main content

ADCS hardening & shared responsibility

Certeasy bridges ACME to your existing PKI; it does not replace your AD CS hardening. Several well-known AD CS misconfiguration classes (the "ESCx" escalation paths) live in the CA and template configuration you operate, not in Certeasy. This page maps those boundaries so you can review them with your PKI/AD team during deployment — what Certeasy handles, what stays on your side, and where an optional Certeasy-side check could be added for defense-in-depth.

None of the items below are Certeasy defects; they are properties of the surrounding environment worth confirming together.

Certificate validity periods​

Where it's handled: for ADCS authorities, certificate validity comes entirely from the ADCS template. Certeasy honors it as-is (the 90-day limit only applies to the built-in fake test PKI).

To confirm together: that your templates issue appropriately short-lived certificates for the use case.

Optional Certeasy-side check (on request): a max-validity limit on the authority / issuance-policy that refuses a certificate whose NotAfter exceeds it.

Extended Key Usage on the issued certificate (incl. ESC3)​

Where it's handled: the EKUs on the issued certificate are defined by the ADCS template, not by Certeasy. Certeasy constrains what an ACME client may request in its CSR (Server Authentication only; extra EKUs are rejected unless you allow them via csr.allowed-extra-eku) — but the template has the final say. If the template itself grants additional EKUs, the issued certificate carries them and Certeasy passes it through. A template that hands out an Enrollment Agent EKU (1.3.6.1.4.1.311.20.2.1) or Any Purpose is the classic ESC3 case.

To confirm together: that the template grants only the EKUs the certificate actually needs. This is owned by whoever creates the template.

Optional Certeasy-side check (on request): warn or refuse if the issued certificate carries EKUs beyond an allow-list (e.g. Enrollment Agent).

Service-account enrollment permissions (ESC4/ESC5)​

Where it's handled: architectural on the Certeasy side — Certeasy enrolls under its own service account (in-process with the native connector, or via certreq.exe with adcs-cli), so ACME clients never authenticate to ADCS directly. The permissions that account holds on the template are set in AD, which Certeasy cannot change or fully verify.

To confirm together: that the service account has only what it needs (Enroll, plus the Certificate Manager role only if you want CA-side revocation) — not Write / Manage on the template.

Optional Certeasy-side check (on request): a startup check that inspects the template with certutil -v -template and warns on excess rights.

Audit logging​

Where it's handled: Certeasy ships a dedicated, tamper-evident audit log (JSONL with an HMAC chain, verifiable via certeasy audit verify) covering account, order, challenge, issuance and revocation events — independent of the application log. See Audit log.

To confirm together: retention, off-host shipping and access control for that log file, which remain on your operational side.

Enforced entirely by Certeasy (for reference)​

Handled in Certeasy code, no operator action needed:

  • Subject validation: only empty or CN=<dns> accepted (common/x509v/certificate_context.go)
  • SAN validation: DNS names only — no otherName/UPN/email/IP/URI
  • Client CSR EKU: constrained to Server Authentication; extra EKUs rejected unless explicitly allowed via csr.allowed-extra-eku
  • Template selection: never exposed to ACME clients
  • CSR structural validation: no ASN.1 smuggling or duplicate extensions