Document or Allow Environment Variable for CRL cache path

[jimmyca15]

We have an application that runs as a set of containers. We would like to use .NETs CRL Revocation Checking, but we want to make sure that we are using the built-in CRL caching mechanisms. The problem with the current CRL cache is that it is persisted on the container's file system, which is ephemeral. We can fix this problem by mapping the CRL cache directory to the container host to be used for all containers on that host. The problem with this is that the CRL cache path is undocumented.

To be able to mount the CRL cache path to the container host, I'd like to request that the CRL cache path be documented or be settable through environment variable.

Support for CRL caching on Linux was added in this PR. The CRLs are currently cached in ~/.dotnet/corefx/cryptography/crls/, but this is considered an implementation detail as mentioned in the PR conversation.

Addendum

The ask above is an improvement, but I also want to mention our optimal solution. In the applications we develop we rely on distributed persisted storage for caching (redis cache, cosmos db) instead of the hard-disk. To enable this for CRL caching I'd like to ask for an interface that we can implement to choose where/how the CRL data is stored.

interface ICRLCache
{
    // Writes CRL cache data
    ValueTask Write(CrlData);

    // Read cached CRL data
    ValueTask<CrlData> Read();
}

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchForks See info in area-owners.md if you want to be subscribed.

Issue Details

---

We have an application that runs as a set of containers. We would like to use .NETs CRL Revocation Checking, but we want to make sure that we are using the built-in CRL caching mechanisms. The problem with the current CRL cache is that it is persisted on the container's file system, which is ephemeral. We can fix this problem by mapping the CRL cache directory to the container host to be used for all containers on that host. The problem with this is that the CRL cache path is undocumented. To be able to mount the CRL cache path to the container host, I'd like to request that the CRL cache path be documented or be settable through environment variable. Support for CRL caching on Linux was added in [this PR](https://github.com/dotnet/corefx/pull/3047). The CRLs are currently cached in `~/.dotnet/corefx/cryptography/crls/`, but this is considered an implementation detail as mentioned in the PR conversation.

Author:	jimmyca15
Assignees:	-
Labels:	`area-System.Security`, `feature request`, `untriaged`
Milestone:	-

[bartonjs]

There's not a good way to really do an interface (or class) here, since the CRL caches are a black box on macOS and Windows .. we only have control over them on Linux.

If OpenSSL3 has inbuilt CRL caching (I don't think it does, but if it did...) then we'd relinquish our notion of the cache and just use theirs... which would make this stop working on Linux, too.

We can certainly write down the path, but it only applies to Linux and is subject to change at any time; but API is probably a "not going to happen".

[siewers]

I think the this issue could have been avoided if the caching logic was documented. I understand the implementation differs across platforms, but given the fact that running .NET on Linux is quite common, I would expect such an important fact was mentioned somewhere besides in a code comment.