Aller au contenu principal

Security TODO

This page tracks security mitigations that are claimed in the documentation but not currently enforced by Certeasy code. These are either operator responsibilities or planned enforcement features.

ESC12 — Short Validity Periods​

Claim in docs: "Short validity periods" is listed as a Certeasy mitigation.

Reality: For ADCS authorities, certificate validity is controlled entirely by the ADCS template configuration. Certeasy does not inspect or enforce validity periods on ADCS-issued certificates. The 90-day limit only exists in the fake (test) PKI backend.

Gap: An ADCS template could issue 10-year certificates and Certeasy would accept and serve them without complaint.

Proposed fix: Add an optional max-validity field to authority or issuance-policy config. If the issued certificate's NotAfter exceeds the configured maximum, Certeasy refuses to store and return it.

ESC3 — No Enrollment Agent Templates​

Claim in docs: "No Enrollment Agent templates used."

Reality: This is purely an operator configuration responsibility. Certeasy does not inspect or validate the ADCS template it is configured to use. Nothing prevents an operator from pointing certificate-template at an Enrollment Agent template.

Gap: No validation that the configured template is safe.

Proposed fix: Document clearly as operator responsibility (not a Certeasy enforcement). Optionally: warn or refuse if the issued certificate contains Enrollment Agent EKU (1.3.6.1.4.1.311.20.2.1).

ESC4/ESC5 — Enrollment Permissions Restricted to Service Account​

Claim in docs: "Enrollment permissions restricted to service account."

Reality: Architectural — Certeasy calls certreq.exe under its own service account, so clients never authenticate to ADCS directly. However, Certeasy cannot verify or enforce what permissions the service account has on the ADCS template. A misconfigured service account with Write/Manage permissions on the template would be a risk Certeasy cannot detect.

Gap: No validation of service account permissions.

Proposed fix: Document as operator responsibility. Consider adding a startup check that verifies the service account only has Enroll (not Manage/Write) on the ADCS template, using certutil -v -template.

ESC12 — Full Audit Logging​

Claim in docs: "Full audit logging."

Reality: Certeasy logs certificate operations (submission, issuance, revocation) via its structured logger. However, there is no dedicated, tamper-evident audit log file separate from the application log. Log integrity depends entirely on the operator's log aggregation and storage setup.

Gap: No dedicated audit log with guaranteed durability/integrity.

Proposed fix: Already tracked separately — the acme_audit_logs database table stores all actions. Consider exposing a dedicated audit log export endpoint or file.

Notes​

Mitigations fully enforced in Certeasy code (not listed here):

  • Subject validation: only empty or CN=<dns> allowed (common/x509v/certificate_context.go)
  • SAN validation: DNS names only, no otherName/UPN/email/IP/URI (common/x509v/certificate_context.go)
  • EKU: forced to Server Authentication, not configurable by clients
  • Template selection: not exposed to ACME clients
  • CSR structural validation: no ASN.1 smuggling, duplicate extensions, etc.