Description

When authenticating an SSL Stream as client using the Online Certificate revocation check option in a Linux container we see significant unmanaged memory usage / growth often leading to OOM pod restarts.

This can most clearly be seen by monitoring the RES memory of the dotnet process via the TOP command whilst making TLS sessions and changing the CertificateRevocationCheckMode against the SslClientAuthenticationOptions passed to the AuthenticateAsClientAsync method.

Reproduction Steps

This issue is most prevalent when using a certificate issued by a public CA (in the case of the testing digicert) and only occurs when the server does not support OCSP stapling.

Attached are two test applications, one a TLS server and one a TLS client. The server expects two command line arguments, the PFX file for a server certificate and the password for that PFX, it subsequently listens on all hosts on port 54784
The TLS client application then expects three arguments, the host to connect to, the port to connect to and whether to perform revocation checks on server certificates. The client subsequently makes 100 TLS sessions to the server and outputs memory details, hitting enter will make it send another batch of 100 requests.

When the client is run on Linux with the revocation argument set to false, the reported memory for the application remains around 65MB and this is consistent if numerous sets of requests are made. When setting the check revocation argument to true at the end of the first set of requests the memory usage is around 400MB and often continues to increase through subsequent sets of requests.

CertificateRevocationMemoryUsageTestApps.zip

Expected behavior

Memory remains relatively stable and is cleared when TLS connections are terminated

Actual behavior

Memory is higher and increases

Regression?

Behaviour appears very similar if the test application is converted to .NET 6.0 using the runtime/6.0 container

Known Workarounds

Disable Certificate revocation checks when authenticating SslStream objects

Configuration

.NET 8.0 (tested with both 8.0.4 and the 8.0.5 preview)
runtime/8.0 and runtime/8.0-jammy containers
The certificate used appears quite important, as the issue does not occur with a self-signed certificate

Other information

No response