Skip to content

AD-ADCS-016: CA configuration could not be read

low   Certificate services   MITRE ATT&CK T1649   Reads: CA registry probe

An enterprise CA's own configuration could not be read, so the CA-side checks (ESC6, ESC7, ESC11, ESC16, audit filter) say nothing about it.

Why it matters

The CA-side checks (ESC6, ESC7, ESC11, ESC16, audit filter) read settings that live only in the CA's registry, not in LDAP. When ad-doctor cannot read them, their results are silent for that CA, which could hide a real misconfiguration. This finding makes that blind spot explicit so a clean report is not mistaken for a safe CA.

Common causes: the CA host is not reachable on TCP 445, the scanning account has no credentials or no access to the winreg pipe, the RemoteRegistry service is disabled, a GPO has removed CertSvc from the remotely accessible registry paths, or the CA runs a non-Microsoft policy module whose EditFlags/DisableExtensionList have a different meaning.

How ad-doctor detects it

During collection ad-doctor opens \pipe\winreg on each enterprise CA host and reads under SYSTEM\CurrentControlSet\Services\CertSvc. Every CA whose read failed (with the error) or that runs a third-party policy module (with a note that ESC6 and ESC16 were not judged) is listed, as is a CA where InterfaceFlags (ESC11), the Security descriptor (ESC7), EditFlags (ESC6) or DisableExtensionList (ESC16) was missing or unusable: an absent value is unknown, never clean. AuditFilter is listed only when reading it failed: when it does not exist, AD-ADCS-018 reports the CA instead. A security descriptor that cannot be parsed counts as a read error. --no-ca-registry and --no-probes skip the read entirely; a run made that way does not raise this finding, but also produces no CA-side findings.

Attributes and probes read
  • SYSTEM\CurrentControlSet\Services\CertSvc (over \pipe\winreg)
  • PolicyModules\Active

Severity

Always low: this is a coverage gap, not a misconfiguration. It means ad-doctor could not reach or parse the CA's registry, so the CA-side findings are neither present nor ruled out for that CA. A third-party policy module is reported here too, because the Microsoft-specific EditFlags and DisableExtensionList cannot be interpreted, and so is a CA where one of the values was absent or empty (each object names the checks it affects).

False positives and limits

  • Intentionally skipped. If you run with --no-ca-registry because the probe is too intrusive for your environment, this finding will not appear, and the absence of ESC6/7/11/16 and audit filter findings simply means they were not checked. Note that in your report.
  • Not a CA problem. The cause is almost always on the network or the scanning side, not a weakness of the CA itself.

Fix

  1. Run the scan from a host that can reach TCP 445 on each CA, with credentials (-u or -k), so the winreg pipe can be opened.

  2. Check the CA host: RemoteRegistry must not be disabled (it is trigger-started on demand), and SYSTEM\CurrentControlSet\Services\CertSvc must stay in the winreg AllowedPaths list. A GPO that sets Network access: Remotely accessible registry paths and subpaths replaces the whole list, so re-add CertSvc there if it is missing.

  3. Third-party policy module: audit ESC6 and ESC16 for that CA by hand, since their registry values do not follow the Microsoft default module's meaning.

Verify

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ADCS-016

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ADCS-016"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References

Microsoft and vendors

Specifications

MITRE ATT&CK

New in the next release.