Share via

Applocker rules

EuroEager2008 171 Reputation points
Feb 5, 2025, 12:29 PM

Using Applocker rules with Publisher conditions.

These conditions are based on digitally signed files (exe files).
The signatures are timestamped (countersigned) within the codesigning certificates validity time.

When this is done correctly, all works fine, however I have a question about the dependency of root certificates referred to directly or indirectly (via intermediate certificates) from the signature.
Does Applocker depend on a valid trusted root certificate to allow or deny a certain signed file to start or will the timestamp guarantee the intended rule's outcome forever?

To be more specific: Does it matter for Applocker if trusted root certificate expires (or for that matter is revoked) as long as the signature is timestamped as mentioned?

This is so important for me/us that I would very much like an "authoritative" answer.

Windows 10 Security
Windows 10 Security
Windows 10: A Microsoft operating system that runs on personal computers and tablets.Security: The precautions taken to guard against crime, attack, sabotage, espionage, or another threat.
3,003 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Marcin Policht 35,360 Reputation points MVP
    Feb 5, 2025, 12:33 PM

    Applocker's behavior depends on the way Windows enforces code signing validation. In particular:

    1. Timestamping and Signature Validity
      • If a file is signed with a code signing certificate that was valid at the time of signing and the signature is countersigned with a trusted timestamp, Windows considers the signature valid indefinitely, even if the code signing certificate expires later.
      • This is because the timestamp acts as proof that the file was signed while the code signing certificate was still valid.
    2. Dependency on Root Certificate
      • Expiration of the Root CA Certificate:
        If a root certificate expires, this generally does not impact Applocker enforcement, as long as the certificate was valid at the time of signing and the timestamp was properly applied. Windows continues to trust signatures that were valid at the time of signing.
      • Revocation of the Root CA Certificate:
        If the root certificate is revoked, this could be different. In some cases, Windows might treat it as untrusted, which could affect Applocker rules that rely on publisher conditions. However, if the signed file has a timestamp and was signed before the root was revoked, it may still be trusted depending on how revocation checking is enforced on your system.
    3. Certificate Revocation Checking and Applocker
      • By default, Windows does check revocation status of certificates (intermediate and root) when verifying signatures, unless explicitly disabled.
      • If a root CA is revoked, and revocation checking is enforced, Applocker might block files signed under that CA, even if they were timestamped.
      • However, Windows' Authenticode signature verification often allows timestamped signatures to remain valid if the signing certificate was valid at the time of signing, even if the CA is later revoked.

    Effectively:

    • A properly timestamped signature ensures that a signed file remains valid even if the signing certificate or root certificate expires.
    • If the root certificate is revoked, Applocker might block execution depending on revocation checking settings.
    • If strict revocation checking is required in your environment, you should test whether revoked root/intermediate certificates affect Applocker rules.

    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.