We appreciate you taking the time to report this problem. We are currently prioritizing problems that are impacting a broad set of our customers, so we may not be able to investigate this one immediately. We know this problem is important to you, so we will continue to monitor it.

This API is actually a new overload of the SslStream.AuthenticateAsClient() methods that was introduced in .NET Framework 4.7. This particular overload was added so that you didn't need to specify an SslProtocols parameter. This new API method will use SslProtocols.None internally which will automatically use the best recommend set of TLS protocols.

See:

https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.authenticateasclient?view=netframework-4.7#System_Net_Security_SslStream_AuthenticateAsClient_System_String_System_Security_Cryptography_X509Certificates_X509CertificateCollection_System_Boolean_

As a workaround to the bug, you can use the following method overload instead which will correctly honor the checkCertificateRevocation parameter. Notice that this API call is explicitly passing in SslProtocols.None to match the behavior of the other method overload that has the bug.

AuthenticateAsClient(targetHost, clientCertificates, SslProtocols.None, checkCertificateRevocation);

Please let us know if you have any questions. Thank you for reporting this issue to us!