TLS 1.3 session resumption breaks IsMutuallyAuthenticated and LocalCertificate on Linux

[multiarc]

Description

On Linux with OpenSSL, when using TLS 1.3 with client certificate authentication (mutual auth), resumed sessions incorrectly report IsMutuallyAuthenticated=false and LocalCertificate=null on the client side, even though the server correctly recognizes mutual authentication.

Reproduction Steps

Unit test presenting the issue.
Failing in .NET 10 but works in .NET 8 target.
https://github.com/multiarc/NET10.mTLS.Repro

Expected behavior

All connections (initial and resumed) should report IsMutuallyAuthenticated=true and LocalCertificate should return the client certificate when mutual authentication was established.

Actual behavior

• First connection: IsMutuallyAuthenticated=true, LocalCertificate is set correctly
• Resumed connections: IsMutuallyAuthenticated=false, LocalCertificate=null

Regression?

This is a regression from .NET 8 introduced in commit 4a8a95f8841 Support TLS Resume with client certificates on Linux (#102656)

Known Workarounds

Set AllowTlsResume=false in SslClientAuthenticationOptions to disable session resumption (at the cost of performance).

Configuration

• OS: Ubuntu 24.04.3 LTS, 6.14.0-28-generic
• OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
• .NET versions:
  • 8.0.122-0ubuntu1~24.04.1 amd64
  • 10.0.100-0ubuntu1~24.04.1 amd64
• Architecture: x64

Other information

Root Cause (based on fix PR)

In NewSessionCallback (Interop.OpenSsl.cs), when TLS 1.3 issues new session tickets on resumed connections, SSL_get_certificate() returns null because no certificate was set on the SSL object for the resumed connection (certificate exchange is skipped during resumption). This null value overwrites the correct certificate tracking data in the session cache.

[dotnet-policy-service]

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

[multiarc]

How can I create fix for 10.0 branch if merged into main?

[karelz]

@multiarc first we need to merge change into 11. Then we need to assess impact on scenarios to make a case for servicing 10.

You can help us by providing details about what kind of app/service you have and how much does it hurt you. If you considered workarounds.
Given that it is a regression (at least from user perspective), it might have a chance.

[multiarc]

@karelz
The impacted area is mTLS scenarios with TLS 1.3, in my particular case it is not critical but prevents me to perform clean upgrade to .NET 10 without workarounds that I need to remember and follow-up for .NET 11+.
This is a regression in behavior with exactly the same parameters and configuration. General impact is re-connection performance under mTLS and some maintenance burden (conditional targeting), outside of mTLS scenarios with TLS 1.3 there is nothing else broken due to this.

[karelz]

In general, we wait for multiple reports, or a report with significant impact before we start backporting fixes.
That way we can manage risk of introducing other unintended regressions in servicing branches.