Add an in-memory cache for CRLs on Linux #123562

bartonjs · 2026-01-23T20:14:50Z

Introduce an extra layer of caching for CRLs.

The cache has a fixed size of 30 elements. When full, it evicts the least-recently-used entry.
Using the same finalizable object sentinel approach as ArrayPool, the cache will purge entries every time the GC finalizes.
- During a finalize, the current MRU node is marked as what to purge next time.
  - Using that node moves the purge target to the next-older entry before the node is promoted back to MRU.
- On the subsequent finalize, the marked node (and everything after it) are purged.
To avoid finalizing the CRL SafeHandles, the cache does an AddReference on every item that is returned (so the caller must Release it), and it calls Dispose on anything it evicts.

This implementation ignores any finalizations that happen in the first minute of the sentinel object's life, to allow the object a chance to get into Gen2 before hyper-eagerly evicting things.

dotnet-policy-service · 2026-01-23T20:15:47Z

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

bartonjs · 2026-01-23T20:16:56Z

Testing with a cert that has a large CRL, revocation-enabled chain building is significantly reduced. This is from building a chain 5 times in a row, the last build:

Before:

2026-01-23T19:52:47.746Z: ChainStart - Starting X.509 chain build.
2026-01-23T19:52:47.748Z: FindFirstChainFinished - First build finished with status 0.
2026-01-23T19:52:47.748Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2026-01-23T19:52:47.748Z: CrlIdentifiersDetermined - Certificate 'CN=*.redis.cache.windows.net, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20RSA%20TLS%20Issuing%20CA%2004.crl', will use '093932f7.a38db5b0.crl' as the cache file.
2026-01-23T19:52:47.748Z: CrlCacheCheckStart - Checking for a cached CRL.
2026-01-23T19:52:48.123Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2026-01-28T14:33:08.0000000-08:00) is acceptable, using the cached file.
2026-01-23T19:52:48.123Z: CrlCacheCheckStop - Duration 374.733ms
2026-01-23T19:52:48.123Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2026-01-23T19:52:48.123Z: CrlCacheCheckStart - Checking for a cached CRL.
2026-01-23T19:52:48.123Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2026-02-09T09:43:56.0000000-08:00) is acceptable, using the cached file.
2026-01-23T19:52:48.123Z: CrlCacheCheckStop - Duration 0.225ms
2026-01-23T19:52:48.224Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2026-01-23T19:52:48.224Z: RevocationCheckStop - Duration 476.439ms
2026-01-23T19:52:48.358Z: ChainStop - Duration 611.607ms

After:

2026-01-23T19:53:24.099Z: ChainStart - Starting X.509 chain build.
2026-01-23T19:53:24.101Z: FindFirstChainFinished - First build finished with status 0.
2026-01-23T19:53:24.101Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2026-01-23T19:53:24.101Z: CrlIdentifiersDetermined - Certificate 'CN=*.redis.cache.windows.net, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20RSA%20TLS%20Issuing%20CA%2004.crl', will use '093932f7.a38db5b0.crl' as the cache file.
2026-01-23T19:53:24.101Z: CrlCacheInMemoryHit - The in-memory CRL cache has a valid entry for the requested CRL, expiration at 2026-01-28T14:33:08.0000000-08:00.
2026-01-23T19:53:24.101Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2026-01-23T19:53:24.101Z: CrlCacheInMemoryHit - The in-memory CRL cache has a valid entry for the requested CRL, expiration at 2026-02-09T09:43:56.0000000-08:00.
2026-01-23T19:53:24.122Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2026-01-23T19:53:24.122Z: RevocationCheckStop - Duration 21.174ms
2026-01-23T19:53:24.122Z: ChainStop - Duration 22.639ms

Copilot

Pull request overview

This PR introduces an in-memory LRU cache layer for Certificate Revocation Lists (CRLs) on Linux to improve performance by reducing disk I/O. The cache sits between the caller and the existing disk cache, with a fixed capacity of 30 entries that evicts least-recently-used items when full. The implementation uses a GC-based pruning mechanism similar to ArrayPool, where a finalizable sentinel object triggers periodic cache cleanup to manage memory pressure.

Changes:

Added 5 new event source events for tracking in-memory cache hits, misses, expiration, pruning, and capacity events
Updated existing event messages to clarify they refer to disk cache operations
Implemented MruCrlCache class with thread-safe LRU eviction, reference counting via DangerousAddRef/DangerousRelease, and GC-triggered pruning
Refactored CRL loading to check in-memory cache first, then disk cache, then download
Added proper SafeHandle management to prevent premature finalization during cache operations

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 12 comments.

File	Description
OpenSslX509ChainEventSource.cs	Added 5 new event IDs and methods for in-memory cache telemetry; updated existing event messages to distinguish disk cache operations
OpenSslCrlCache.cs	Added MruCrlCache class implementing thread-safe LRU cache with GC-based pruning; refactored CRL loading logic to check memory cache before disk; added proper SafeHandle reference management

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

...ryptography/src/System/Security/Cryptography/X509Certificates/OpenSslX509ChainEventSource.cs

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

...ryptography/src/System/Security/Cryptography/X509Certificates/OpenSslX509ChainEventSource.cs

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

grbell-ms · 2026-01-23T20:37:22Z

This implementation ignores any finalizations that happen in the first minute of the sentinel object's life, to allow the object a chance to get into Gen2 before hyper-eagerly evicting things.

Might be simpler to check directly with GC.GetGeneration

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

vcsjones · 2026-01-29T16:16:19Z

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

+
+                using (SafeBioHandle bio = Interop.Crypto.BioNewFile(crlFile, "wb"))
+                {
+                    if (bio.IsInvalid || Interop.Crypto.PemWriteBioX509Crl(bio, crl) == 0)


In general what is to stop concurrent writes on these CRL files? I don't believe the file mode here will have any kind of exclusivity on the file. Can two processes race and corrupt each other's CRL cache?

Should we instead do some kind of atomic writing pattern?

Yeah, they can stomp, which just causes the next load to fail and and fall back to fetching from the web again. We can certainly improve the resilience, but that feels a bit unrelated (again, mostly because I expect this to get a backport request)

Yeah I understand, I just wonder now that we see the ecosystem shifting to relying on CRLs now if this is going to be a "problem" that is hit more frequently. If it's corrupt, is it self-correcting? (Does the web fetch overwrite the bad one at least?)

@manuelpuyol this is the PR I was mentioning.

vcsjones · 2026-01-29T16:21:01Z

...m.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCrlCache.cs

+
+            private void PruneForGC()
+            {
+                if (DateTime.Now < _firstPurge)


Should we using Stopwatch.GetTimestamp or something monotonic? What happens when the system moves its clock around for DST changes?

That's a really good point. One I hope I would have made had I not written the code.

I'll probably take the suggestion of switching to GC.GetGeneration to just filter out G0/G1 finalizations of this detector.

bartonjs added 3 commits January 20, 2026 16:54

Insert in-memory CRL cache ahead of disk cache

4d30f19

Change cache to MRU with GC Jacquard

91afbb8

Give the MRU a limit of 30

641444f

bartonjs added this to the 11.0.0 milestone Jan 23, 2026

bartonjs self-assigned this Jan 23, 2026

Copilot AI review requested due to automatic review settings January 23, 2026 20:14

bartonjs added area-System.Security tenet-performance Performance related issue labels Jan 23, 2026

Copilot started reviewing on behalf of bartonjs January 23, 2026 20:15 View session

Copilot AI reviewed Jan 23, 2026

View reviewed changes

build-analysis bot mentioned this pull request Jan 24, 2026

Cannot find 'arm64-v8a' device dotnet/dnceng#2284

Open

3 tasks

bartonjs added 2 commits January 23, 2026 17:14

Address feedback

b9b8f54

Make in-memory expiration message use same structure as disk

ad8d50e

Merge branch 'main' into crl_cache

c168b0a

build-analysis bot mentioned this pull request Jan 28, 2026

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

3 tasks

vcsjones reviewed Jan 29, 2026

View reviewed changes

Add an in-memory cache for CRLs on Linux #123562

Are you sure you want to change the base?

Add an in-memory cache for CRLs on Linux #123562

Conversation

bartonjs commented Jan 23, 2026

Uh oh!

dotnet-policy-service bot commented Jan 23, 2026

Uh oh!

bartonjs commented Jan 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

grbell-ms commented Jan 23, 2026

Uh oh!

Uh oh!

Uh oh!

vcsjones Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

bartonjs Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

vcsjones Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

vcsjones Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

vcsjones Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

bartonjs Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants