banshee/active-directory-collection/active-directory/https/crl

Certificate revocation list

Reads the certificate revocation list (CRL) of a certification authority at its distribution point, over HTTP or HTTPS: the hours left before it expires, when it was published, how many certificates it revokes, and its issuer. Three watches are proposed, the first two checked: the CRL expiring, the CRL expired, and an unexpected issuer.

Once the next update of a CRL has passed, a client that checks the revocation of a certificate of the authority refuses it: every certificate the authority issued fails at once. It completes active-directory/winrm/adcs and active-directory/ssh/adcs, which watch the service and the certificate of the authority but cannot read its CRL.

How it works

One GET to the address set in crl:url; nothing else is sent, no account, no secret. The body is read as a CRL, in DER as a Windows authority publishes it, or in PEM.

hours-left is the time left before the next update the CRL announces, in hours, to a tenth; it is negative once the CRL has expired.
published is the date the CRL gives as its publication (its this update), in UTC, written 2026-10-27T08:50:00Z. A Windows authority sets it 10 minutes before the actual publication, for the clocks of its clients.
entries counts the certificates the CRL revokes, 0 for none.
issuer is the authority that issued the CRL, written as the issuer of a certificate (CN=Example-CA, DC=example, DC=com).
The signature of the CRL is not checked: the collector reads what the list says of itself, which is what its expiry asks.
An address that answers 404 stops the collector as misconfigured; any other code than 200, an address that does not answer, or a body that is not a CRL (an error page, a certificate) leaves the probe unreachable. A CRL that gives no next update stops it as misconfigured: nothing then says when it expires, and a Windows authority always writes it.
https:// follows the TLS profile of the probe: an address served with the certificate of a company's authority needs that authority in the profile.

The address of a CRL

The address is the one clients use: open a certificate the authority issued, its CRL Distribution Points extension lists it. Take the http:// address, not the ldap:/// one, which is read by LDAP.

A Windows authority publishes its CRL in %windir%\System32\CertSrv\CertEnroll, served by IIS on the authority under /CertEnroll/ when the role "Certification Authority Web Enrollment" is installed (Microsoft, "Copy the CA certificate and CRL to the virtual directory"). Its default HTTP distribution point is http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl (Microsoft, "Specify CRL Distribution Points", tab Extensions of the authority).

A delta CRL

An authority that publishes delta CRLs serves two lists: the base CRL, published by default once a week, and the delta CRL, published by default once a day, which lists only the certificates revoked since the base. A client that uses the delta needs both valid: deploy this collector twice, on two probes, one per address.

To tell them apart by the address: the variable DeltaCRLAllowed of the distribution point adds a suffix to the name of the delta CRL alone, + on a Windows authority: Example-CA.crl is the base CRL, Example-CA+.crl its delta. The checkbox "Publish Delta CRLs to this location" of the distribution point says whether the delta is published there.
To tell them apart in the list itself: a delta CRL carries the extension Delta CRL Indicator (RFC 5280, section 5.2.4), and a base CRL that has a delta carries Freshest CRL, the address of its delta. The collector does not read them: certutil -dump of the file, or the CRL opened in Windows, shows them.
entries of a delta counts only the certificates revoked since its base CRL: a low number is expected.

Prerequisites

The distribution point reachable from the poller, on its port (TCP 80 for http://).
Nothing on the authority and no account: a CRL is public, served for any client to fetch.

Variables

Name	Label	Says	Default
`crl:url`	CRL address	the full address of the CRL, required	—

Outputs

Name	Label	Unit	Per instance
`hours-left`	Before the CRL expires	h	no
`published`	Published	—	no
`entries`	Revoked certificates	—	no
`issuer`	Issuer	—	no

Watches

Name	Title	Kind	Defaults	Checked by default
`expiring`	CRL expiring	low threshold, on `hours-left`	warning below 8 h, critical below 4 h	yes
`expired`	CRL expired	low threshold, on `hours-left`	critical below 0 h: the next update has passed	yes
`issuer`	Unexpected issuer	expected value, on `issuer`	no issuer given: it raises nothing until one is set on the probe	no

The defaults follow a Windows authority left at its defaults. It publishes the next CRL at the end of its period, a week for the base CRL, a day for the delta, and announces a next update later by an overlap: 10 % of the period for a base CRL, the whole period for a delta, at most 12 hours either way, plus 10 minutes for the clocks (Microsoft, "How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated"). A CRL published on time therefore never has less than about 12 hours left, base or delta: below 8 hours, the publication is late by more than 4 hours.

An authority set otherwise sets its thresholds to match: under its overlap, the publication is late. An offline root authority, whose CRL is published by hand every few months with an overlap of weeks, takes thresholds in weeks (expiring at 336 h and 168 h, for instance), to leave time to start it and publish.

Limits

The signature of the CRL is not checked: a list served by a wrong address, from another authority, reads as well. issuer, and the watch issuer once set, say which authority it comes from.
Whether the list is a base CRL or a delta CRL is not read (above, "A delta CRL").
A distribution point that answers with a redirection (301, 302) leaves the probe unreachable: no redirection is followed. Set the final address.
Not yet checked on a real certification authority: the execution.