CA health and hardening
What the CA connector reports about the certificate authority it fronts - CRL freshness, CDP reachability, key strength, ESC6 - and the hardening checklist beside it.
On every check-in the connector gathers a best-effort snapshot of the CA it is paired with. The connector page in the dashboard turns that into two things: automated findings, which are re-checked continuously, and a hardening checklist, which is review work you mark done.
Both are informational. aethercert never modifies the CA - every remediation, on either list, is something you do on the CA server yourself.
Why this exists
An undetected stale delta CRL caused an outage: clients failed validation with
CRYPT_E_REVOCATION_OFFLINE because the CRL they were told to fetch had expired and
nobody was watching. That is the failure mode the automated half of this page is built
around, which is why "already expired" here is treated as at least as severe as an expired
certificate.
The CRL & CA tab
The connector reads every Base and Delta CRL location configured in AD CS - both the direct publication targets and the URLs advertised to certificate clients. A normal IIS deployment deliberately uses a local publish target and a separate HTTP client URL, so the two lists differ. HTTP(S), local and UNC paths, and LDAP locations are each tested independently.
For every location it could read, the tab shows the CRL number, ThisUpdate,
NextUpdate, issuer, signature algorithm and revoked-entry count. The status combines
transport, parsing and freshness, so a reachable endpoint serving an invalid or expired
CRL is not shown as healthy.
| Finding | Severity |
|---|---|
| The base CRL has expired | Critical |
| The base CRL is expiring soon | Warning |
| The delta CRL has expired | Critical |
| The delta CRL is expiring soon | Warning |
| A specific location's CRL has expired or is expiring soon | Critical / warning |
| A CDP returned an unexpected HTTP status | Warning |
| A CDP responded but not with a parsable CRL | Warning |
| A CDP could not be reached | Warning |
| The CA certificate has expired | Critical |
| The CA certificate is expiring soon | Warning |
Each of these also becomes an event-log entry and is pushed to any monitoring integration you have configured, including the matching resolved event when the condition clears.
The Hardening tab
Two automated findings sit here rather than on the CRL tab, because they are fixed properties of the CA rather than time-varying state:
| Finding | Why it matters |
|---|---|
| The CA certificate's key or signature algorithm is weak | Reported with the actual algorithm and key size. A CA key is the root of everything it has ever issued. |
EDITF_ATTRIBUTESUBJECTALTNAME2 is enabled | The AD CS "ESC6" SAN-injection primitive: any enrollee can put an arbitrary SAN - including another identity's UPN - into a request. Disable it with certutil -config <CA> -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2, then restart CertSvc, unless a specific, understood workflow requires it. |
ESC6 is checked CA-side rather than only being defended against on the connector's own attribute surface, and it is classified critical.
The hardening checklist
Ten items the connector cannot check remotely - mostly template ACLs and CA-level configuration. Review each one on the CA and mark it done; aethercert tracks completion per CA and nothing else.
Templates
| Item | What to look at |
|---|---|
| Review template ACLs for over-broad Enroll, WriteOwner and WriteDACL grants | Enroll granted to a broad group such as Domain Users or Authenticated Users, combined with WriteOwner, WriteDACL or GenericAll on the template object, is the ESC1-ESC4 escalation primitive. Review every issuable template's Security tab, not only the ones this connector uses. |
| Restrict "supply subject in request" templates (ESC1) | A template with ENROLLEE_SUPPLIES_SUBJECT that also grants broad client-auth-capable Enroll rights lets any enrollee request a certificate for an arbitrary identity. |
| Require manager approval on sensitive templates | Subordinate CA issuance, code signing and domain-controller-authentication templates should require CA manager approval rather than auto-issuing. |
| Mitigate NTLM relay against web enrollment (ESC8) | If AD CS Web Enrollment, CES or CEP is installed anywhere in the environment, require HTTPS and Extended Protection for Authentication - or disable web enrollment entirely if it is unused. |
CA permissions
| Item | What to look at |
|---|---|
| Restrict "Manage CA" and "Manage Certificates" group membership | In certsrv.msc under CA properties, Security tab. These allow changing CA configuration and approving pending requests respectively. Membership should be a short, reviewed list. |
CA configuration
| Item | What to look at |
|---|---|
| Enable CA audit logging | certutil -setreg CA\AuditFilter 127, or CA properties > Auditing, plus the matching Windows audit policy category. That gives a trail of every issue, revoke, deny and configuration change. |
| Review private key protection | HSM, or the DPAPI/software CSP posture. A compromised CA signing key compromises every certificate it has issued or will issue. |
| Review certificate and key archival policy | If key archival is enabled for any template, the Key Recovery Agent certificates need protecting at least as strongly as the CA's own key. |
Revocation
| Item | What to look at |
|---|---|
| Review the CRL and delta CRL publication interval | A validity window long enough that a missed or failed publish job goes unnoticed for days is itself a finding. The automated CRL checks above are the ongoing watch; this is the one-time question of whether the interval is sane. |
Connector
| Item | What to look at |
|---|---|
| Confirm the connector runs under a dedicated, least-privilege service account | Not LocalSystem, not a human admin login. A dedicated account or gMSA holding only Enroll on its templates and Issue and Manage Certificates on the CA. See The CA connector. |
What is required for the checks to work
Nothing new to configure. The connector reuses the CDP URLs already published on the CA's
own certificate, so the only requirement is that the connector host can reach whatever
publishes them - see
Network requirements. An ldap:// CDP is
read through Windows' own directory access rather than fetched over HTTP.
Every check is best-effort and read-only. A location the connector cannot reach is reported as unreachable, not as broken.