A malleable operating system

Windows often gets a bad rap for pulling in other Microsoft technologies and services for providing functionality—think Edge defaulting to Bing. Yet the underlying design of the operating system has been historically modular to a fault, containing an abundance of extensibility hooks. These are interfaces where third-party software can augment or even entirely replace built-in operating system functionality. Common examples from the security realm include:

• Anti-malware scan interface for leveraging third-party antivirus solutions
• Credential providers, to allow logging into the OS using a protocol anchored in any identity provider, such as a cloud service.
• Key Store Providers for adding new implementations of cryptographic algorithms, such as post-quantum signatures that did not ship out-of-the-box
• Password filters for enforcing password policy and synchronization with external identity systems.

One of the lesser-known extensibility mechanisms is the ability to extend certificate verification logic by providing custom revocation providers. Windows has historically shipped a robust certificate management engine starting in the early 2000s, featuring support for the two standardized ways of revocation checking:

1. Certificate revocation lists (“CRL”)
2. Online Certificate Status Protocol (“OCSP.”)

But the platform also exposes a generic hook for anyone to bring their own revocation provider. At a high-level, revocation is structured as a cascade of providers in predetermined priority order. Each provider is structured as a DLL that gets loaded in process for the application invoking the X509 validation process. When CertVerifyRevocation API is called, it queries the available providers in order about the status of the given certificate. Every provider can respond in one of three ways:

• State that the certificate is still valid. In this case the revocation check is considered complete and no other providers are queried.
• State that it is revoked and should no longer be trusted. This also terminates the process and returns control to the caller.
• Throw up its hands and proclaim ignorance about the state of this certificate. In that case, the process continues by querying the next provider in the sequence.

Caveats

Before discussing some applications of a custom revocation provider, it is important to cover some limitations. The most significant one is that some applications are not using the Windows cryptography API for certificate validation. Chrome and Firefox are notorious offenders in this regard, bypassing the platform capabilities in favor of their own home-brew (but at least cross-platform consistent) trust management logic for validating server TLS certificates.

The second limitation applies even when applications are “well-behaved” and invoke the platform API for trust management. Revocation checks only happen after chain building has succeeded. If a leaf certificate does not chain up to a known trust anchor, has expired or any number of other chain validity criteria fails— intermediate CA does not have the right EKU for this leaf— the process stops early. At that point, revocation checks become moot because that certificate will never be considered valid.

Finally there is the possibility that an application specifically opts out of revocation checking in the way it calls the platform API. (Note this is different from requesting offline revocation checking to avoid network latency. In that case, the system will still execute the same steps of querying providers in sequence while passing along the request to limit checks to offline sources. Of course there is no way of enforcing this— a provider can disregard the offline flag and still perform blocking network I/O.)

Use-cases

1. Supplying missing revocation status

While the above caveats seem to imply that a custom revocation provider can only reduce trust in a certificate, this is not necessarily the case. If the provider is registered to execute first, it can preempt the answer that would have been returned from the built-in Windows engine. That means in particular that it can return “not revoked” for a certificate that has in fact been revoked. It’s difficult to imagine a realistic scenario where that would actually be useful or improve security. But there is a different use-case where preempting the built-in provider makes sense: when the standard revocation checking mechanisms are not available.

Examples include:

• The certificate has no CRL Distribution Point (CDP) or OCSP responder field present
• That field exists but is now outdated. For example PKI administrators can change the locations where CRLs are published, but existing certificates will continue to point to the deprecated version.
• Even if the information is accurate, revocation checks could be taking place on a system that does not have access to the designated locations. For example ADCS allows publishing CRLs to a local SMB file-share or Active Directory for clients to fetch from. While that works fine for machines located inside the corporate perimeter, those locations may not be accessible directly from external locations.

In these cases the standard CRL/OCSP path would result in an inconclusive answer to the effect that revocation information is not available. A well-designed system fails safe in that scenario: it must treat this failure mode as being equivalent to a positive revocation outcome. (Otherwise an adversary has the incentive to DDoS the revocation servers or block network traffic in hopes of trying to use a revoked credential without the destination realizing it is no longer trusted.) Absent some way of supplying a definitive “not revoked” answer, these certificates would fail validation.

A variant of this exact scenario was encountered in a high-security deployment of Active Directory Federation Services (ADFS) configured to authenticate users with client certificates. When revocation checking is enforced, ADFS would insist on revocation checks on the entire chain— not just the leaf certificate associated with the client. While those leaf certificates had perfectly functioning CRLs, the intermediate CA issuing them had no revocation mechanism. (This is not entirely uncommon, since the introduction or deprecation of an intermediate CA is an infrequent operation best handled out-of-band, instead of by publishing CRLs.) The problem is solved by a simple revocation provider that returns a predetermined result for a set of certificates identified by their thumbprint, based on registry configuration. In particular, the provider was configured to always report a clean bill of health on the intermediate CA to avoid the ADFS validation failure.

2. Post-facto name constraints

It is no secret that the infrastructure for public TLS certificates is a house-of-cards: there are over a hundred CAs distributed around the world, capable of issuing a TLS server certificate for any website— whether or not the actual owner of the website asked for it. Some of those CAs are probably well-run, with reasonable policies and procedures in place. Others may be incompetent, YOLOing their way through managing a PKI with rudimentary controls. But the worst case scenario are a handful of CAs that are known to be affiliated with or under the control of a nation state. At that point, the CA becomes a natural extension of the surveillance capabilities of that nation, able to mint certificates to intercept traffic. The main defense against such incompetence/malice is detection: Google Chrome has leveraged its monopoly position to foist certificate transparency requirements on CAs, much to their chagrin.

Interestingly the X509 standard historically had a mechanism for constraining the power of certificate authorities. Called name constraints, these are specific fields embedded in the issuer certificate that limit issuance scope. Examples of useful constraints include:

• DNS name: Only issue for “*.mil” domains. Makes sense for a CA operated by the US Department of Defense.
• Email address: Only issue for users with “@acme.com” email address. Applicable to an S/MIME CA operated by the Acme company.

On its face, this is a promising feature for confining potentially rogue CAs. For example a CA affiliated with the government of China should naturally be restricted to only issue for “*.cn” hostnames, corresponding to the top-level country domain for China. The restriction would prevent it from issuing a valid “google.com” certificate even if the CA wanted to. The problem is most TLS certificate authorities are completely unconstrained; historically the root programs have shied away from taking a stance on confining nation-state affiliated CAs. From the perspective of existing roots, that ship has sailed.

Luckily custom revocation providers are not bound by the diplomatic stance taken by the CA/B Forum and they need not bestow every CA under the sun with privileges to issue certificates globally. As long as the provider gets a look at the certificate, it can enforce regional boundaries. If the CA is operating within its natural TLD, the provider stays silent and allows the revocation check to fall through to the standard CRL/OCSP path. But if the CA steps out of line, it can react by reporting the certificate as revoked.

3. Generalized revocation for code-signing

Another use-case comes out of the recent malware campaign involving ScreenConnect. To recap: threat actors were leveraging ScreenConnect installers (groundhog day) signed with their own Authenticode certificate, issued by the Microsoft Entra ID CA, to get remote control over unsuspecting consumer Windows PCs.

This particular certificate authority operated by Microsoft has a pathological design pattern that renders revocation ineffective for combatting malware: it issues a series of short-lived certificates on-demand based on code-signing events, each valid for a couple of days. Imagine a defender coming across a malware sample signed by an Entra ID certificate issued to John Smith. That could be a certificate provisioned by Mr. Smith operating as the mastermind of the malware campaign or it could be a different threat actor using stolen identity documents to impersonate Mr. Smith. Either way there is good reason to believe all other code signed by this person is suspect. In these situations, the CA has an affirmative obligation to revoke those certificates. (Whether it makes sense to enlist certificate authorities in this manner to police the software ecosystem is a separate question, meriting a future post.)

That is exactly what happened to ScreenConnect in 2025. Revocation was more sporadic in the more recent campaign involving repurposed ScreenConnect installers: Microsoft appeared to act on some, but not all Entra ID certificates reported for signing malware. Not that it mattered: given the pattern of issuing multiple short-lived certificates, the John Smith character may well have dozens of other valid Authenticode certificates. Defenders can only observe some subset from the malware samples in our possession; they cannot rule out the possibility that more exist or even that John Smith still has a valid Entra ID account for obtaining future certificates.

What this calls for is a way to blacklist the entire identity instead of some particular expression of that identity embodied in a specific X509 certificate—the narrow capability CRLs and OCSP are tailored for. Custom revocation logic allows going beyond playing a whack-a-mole with serial numbers of known-bad certificates: learning the perpetrator’s identity from the distinguished name field of one certificate, we can remove trust from all certificates issued to that threat actor. That covers past, present and future issuance:

• Past: expired certificates where signatures made during the validity period will still validate due to time-stamping
• Present: outstanding valid certificates that have not been revoked by the issuer yet
• Future: certificates that do not exist, but have the potential to be issued based on existing business relationship between the CA and threat actor

In fact such generalized revocation logic can even operate across certificate authorities. If Entra ID permanently blacklists this person and they have to seek Authenticode certificates from another CA, those certificates can also be reported as “revoked” by the custom provider as long as the same legal name appears in the credential.

CP