[.NET Core/Linux] X509 chain revocation check uses only first CDP URL, does not fall back to others

[myaryn]

Description

On Linux, .NET’s certificate validation (OpenSSL-based) appears to use only the first CRL Distribution Point (CDP) in the certificate. If that URL is unreachable/down, the entire revocation check fails, even when additional CDP endpoints are present on the certificate. This causes unnecessary hard failures and reduces resiliency.

Reproduction Steps

Use a certificate that has multiple CRL Distribution Points (CDP A – primary, CDP B – secondary).

Make CDP A unreachable (simulate network block or HTTP 5xx).

Build an X509Chain in .NET on Linux with revocation enabled:

var chain = new X509Chain
{
    ChainPolicy =
    {
        RevocationMode = X509RevocationMode.Online,
        RevocationFlag = X509RevocationFlag.EntireChain
    }
};
var ok = chain.Build(cert);

Observe that the chain build fails due to CRL download failure, even though CDP B is present.

Expected behavior

Iterate over all CDP URLs in the order provided on the certificate.

Stop at the first successful fetch/valid CRL.

Maintain a short-lived cache of failed CDP endpoints (e.g. static dictionary with TTL) to avoid repeatedly calling an endpoint that is currently down.

Actual behavior

Only the first CDP endpoint is called.

If it fails, revocation check fails even though alternative CDPs are available.

Regression?

No

Known Workarounds

None

Configuration

.NET (Core) on Linux
Using default OpenSSL-backed chain engine

Other information

Why this matters:
In environments where a primary CRL endpoint is fronted by a CDN or may be temporarily unavailable, the current behavior turns a transient CDP issue into a hard revocation failure for all .NET Core/Linux workloads.

[dotnet-policy-service]

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

[bartonjs]

To avoid time-bank starvation for hanging endpoints, we should add a static ConcurrentDictionary recording a failed URL and an expiration time for that URL (though that means we need to determine the backoff period... which we might only want if there's another URL to try?); and, of course, figure out a way to put an iterative flow into the revocation data fetch.

Longer term, we probably want it to be multi-phasic: Look for a cached value from any URI, then do a live refresh for any URI... but in the longer term we also should have a memory cache keep around a hydrated interpretation of the result (though one that plays nice with low memory) and shared Tasks to eliminate redundant parallel downloads.