.NET 10 client-certificate behavior when all explicit certificate sources are null

Question

We are evaluating a Windows x64 HTTPS client using .NET 10 LTS, HttpClient, and a newly created, exclusive SocketsHttpHandler with dedicated SslClientAuthenticationOptions. This is a proposed configuration, not a report of an installed or tested runtime.

Before the first request, the proposed options are:

ClientCertificates = null

LocalCertificateSelectionCallback = null (no custom delegate)

ClientCertificateContext = null

The handler and options would not be shared with or copied from an existing client. Application code would not load or import client certificates or query certificate stores. Normal server-certificate validation would remain unchanged.

Does this configuration guarantee that no client certificate is presented, including when the server sends a TLS CertificateRequest? If not, under what conditions could automatic selection or provider fallback supply one?

Please cite a primary, versioned contract or, alternatively, versioned implementation evidence linking these options through client-certificate selection to the Windows TLS credential. Please specify applicable .NET 10 servicing builds, Windows limitations, TLS 1.2/1.3 paths where supported, and the SocketsHttpHandler-to-SslStream relationship.

We do not assume that a null collection equals an empty collection, or that no callback equals a callback returning null. Please identify any essential behavioral distinction. Our question concerns certificate presentation, not a guarantee of zero certificate-store lookups.

The guide we reviewed, TLS/SSL best practices, lists the three input mechanisms but does not state whether their joint absence guarantees that no certificate is presented.

Answer 1

Hello @Manica Moscon Advogados and thank you for your questions.

For the first part of your question, there is no absolute guarantee in practice, even though the intended behavior is that no client certificate should be supplied under this configuration.
For example, this issue reports that SslStream could reuse a cached Windows TLS credential carrying a client certificate from another connection in the same process. This appears to be an implementation bug rather than ordinary automatic selection or certificate-store fallback. 

For the second part of your question, I regret to say that there does not appear to be a public, versioned contract addressing the exact behavior you described. 

The implementation evidence you are requesting would be extremely difficult to document, let alone trace in full. Someone would need to trace the implementation from SocketsHttpHandler through SslStream, managed client-certificate selection, and Windows Schannel credential acquisition for each relevant .NET 10 servicing build, while separately accounting for Windows versions, servicing changes, TLS paths, and known implementation defects. 

I am also afraid that tracing the versioned implementation may not establish what you need. Versioned source can show how a particular runtime build is implemented, but not necessarily whether that behavior is guaranteed and so forth. 
For the most part, some reliance on Microsoft’s published documentation is necessary when determining the supported and intended behavior. If the runtime does not behave as intended, the practical option would generally be to reproduce the issue and report it to the .NET runtime developers. Internal design decisions and servicing guarantees can ultimately only be confirmed by the product team. 

If you have any further questions, please feel free to let me know. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you. 

Answer 2

The available public contracts do not establish that these three null values guarantee that no client certificate is presented, nor do they establish that Schannel will automatically select one; a security guarantee requires version-pinned .NET 10 implementation evidence that is not present in the cited material.

What is established

• SocketsHttpHandler.SslOptions is an SslClientAuthenticationOptions instance containing the client TLS settings.^1^
• SslClientAuthenticationOptions is the property bag used by SslStream client authentication, and its documentation explicitly identifies SocketsHttpHandler as a consumer.^2^
• ClientCertificates is nullable and identifies certificates “to be considered” for client authentication. The contract does not define whether null and an empty collection produce different Windows credentials.^3^
• The documented certificate-supply mechanisms are ClientCertificates, LocalCertificateSelectionCallback, and ClientCertificateContext; the latter has been available since .NET 8.^4^
• A selection callback chooses a local certificate and has a nullable return type. Its API contract does not say that returning null prohibits subsequent runtime or provider selection.^5^

Consequently, neither of these equivalences is documented for .NET 10:

ClientCertificates == null  ≡  ClientCertificates.Count == 0
callback == null            ≡  callback present and returning null

The older .NET Framework selection documentation says that an empty associated collection results in anonymous credentials, but it is explicitly a .NET Framework selection model—not a versioned .NET 10 SocketsHttpHandler/SslStream contract—so it cannot close this question.^6^

Automatic selection and Windows fallback

HttpClientHandler.ClientCertificateOptions = Automatic is a documented store-selection mode, while its default is Manual.^7^ That mode does not directly answer the proposed case because it uses an exclusive SocketsHttpHandler, not HttpClientHandler, and no corresponding automatic-selection option is established here.

Schannel supports credentials supplied by the caller or preexisting credentials, and a client authentication certificate is optional unless requested by the server.^8^^9^ Those statements alone do not prove that .NET 10 requests automatic store selection when the three managed inputs are null. The missing evidence is:

1. The exact .NET 10 servicing tag or commit.
2. The SocketsHttpHandler HTTPS connection path into SslStream.
3. Certificate-selection handling for all three absent inputs.
4. The SCH_CREDENTIALS/SCHANNEL_CRED fields and flags passed to AcquireCredentialsHandle.
5. Whether those flags permit provider/store selection after no managed certificate was selected.
6. Separate handling, if any, for TLS 1.2 and TLS 1.3.

Without that chain, no concrete fallback condition—or suppression guarantee—can be stated safely.

Version and platform scope

No exact .NET 10 servicing build can be named from these materials. .NET servicing updates are cumulative in support terms, and only the current servicing update remains supported after the next one ships; this does not prove invariant certificate-selection behavior across all 10.0 patches.^10^

On Windows, .NET TLS behavior is mediated through OS cryptographic APIs such as Schannel.^11^ TLS 1.2 support depends on the Windows version and configuration. Schannel TLS 1.3 is supported only beginning with Windows 11 and Windows Server 2022; enabling it on earlier Windows versions is not supported.^12^

How to validate the proposed deployment

Treat this as an implementation-validation requirement rather than relying on the null settings as a contractual prohibition:

1. Record the exact runtime using dotnet --info and the Windows build.
2. Test against a server that sends CertificateRequest, separately under TLS 1.2 and—on Windows 11/Server 2022 or later—TLS 1.3.
3. Capture the handshake with Wireshark or equivalent; Microsoft recommends wire inspection for determining which certificates were exchanged.^11^
4. Verify that the client’s Certificate message contains an empty certificate list rather than a certificate chain. For TLS 1.3, decrypting the handshake may be necessary to inspect messages after ServerHello.
5. Repeat with suitable certificates installed in each store relevant to the process identity. This tests presentation behavior; it does not prove that no store lookup occurred.
6. Re-run the test for each .NET servicing update unless Microsoft publishes a contract guaranteeing this behavior.

A callback returning null may be included as defense-in-depth, but the cited .NET 10 delegate contract is insufficient to describe it as a guaranteed prohibition against all Schannel fallback.

---

References

1. SocketsHttpHandler.SslOptions Property-Definition
2. SslClientAuthenticationOptions Class-Definition
3. SslClientAuthenticationOptions.ClientCertificates Property-Definition
4. TLS/SSL best practices
5. LocalCertificateSelectionCallback Delegate-Definition
6. Certificate Selection and Validation
7. HttpClientHandler.ClientCertificateOptions Property-Definition
8. AcquireCredentialsHandle (Schannel) function
9. Obtaining Schannel Credentials
10. Releases and support for .NET
11. Troubleshoot SslStream authentication issues
12. Protocols in TLS/SSL (Schannel SSP)