Skip to content

SslStream not working with ephemeral keys #114640

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rmannibucau opened this issue Apr 14, 2025 · 4 comments
Open

SslStream not working with ephemeral keys #114640

rmannibucau opened this issue Apr 14, 2025 · 4 comments
Assignees
Labels
area-System.Net.Security untriaged New issue has not been triaged by the area owner

Comments

@rmannibucau
Copy link

Description

Same issue than #103101

Reproduction Steps

See #103101

Expected behavior

It just works since code is there (new X509Certificate2(current.Export(X509ContentType.Pkcs12)) makes it working)

Actual behavior

It fails as in Same issue than #103101

Regression?

I do not know

Known Workarounds

Using new X509Certificate2(current.Export(X509ContentType.Pkcs12)) but it relies on obsolete code which is undesired

Configuration

No response

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Apr 14, 2025
Copy link
Contributor

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

@vcsjones
Copy link
Member

As discussed in the linked issue #103101, this ephemeral key restriction comes from Windows, not .NET.

Using new X509Certificate2(current.Export(X509ContentType.Pkcs12)) but it relies on obsolete code which is undesired

The obsoletion message should direct you towards using the non-obsolete API. It should look something like this:

X509CertificateLoader.LoadPkcs12(current.Export(X509ContentType.Pkcs12), null);

@rmannibucau
Copy link
Author

@vcsjones

The obsoletion message should direct you towards ...

Thanks, will check that!

As discussed in the linked issue #103101, this ephemeral key restriction comes from Windows, not .NET.

I get it but there are two issues in .NET there:

  • if it can work it should be tried to cover more - for example when this exeption is thrown from a ssl handshake the conversion is worth a try as a fallback if you do not want to parse the cert upfront to try to do it upfront (which can be justified)
  • it is unlikely the X509Certificate2.CreateFromPem* doesn't throw any exception but it fails at handshake time (http client) if it is really not supported

Indeed I'd prefer to fix it with the fallback mode since it would make it more widely adopted. For example this case happens with minikube.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Net.Security untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

4 participants