[✨ Triage] dotnet/runtime#119573 by rzikm - OpenSSL error - unknown certificate type when using SLH-DSA-* certificates

[MihuBot]

Triage for dotnet/runtime#119573.
Repo filter: All networking issues.
MihuBot version: 706ff6.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/runtime#119573: OpenSSL error - unknown certificate type when using SLH-DSA-* certificates by rzikm
[Tool] Searching for SLH-DSA certificate, unknown certificate type, SslStream OpenSSL error, TLS-SIGALG capability, AuthenticationException OpenSSL, new certificate types SslStream, draft RFC certificate SslStream (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 84 issues, 470 comments, 40 returned results (6665 ms)

Here are the most relevant related issues, PRs, and discussions for issue #119573 ("OpenSSL error - unknown certificate type when using SLH-DSA-* certificates"):

---

1. PR #115212 (May 2025) - Support SLH-DSA keys in certs

• Summary: This PR added support for SLH-DSA keys in certificates, including X509Certificate2, PEM, and PFX loading/exporting, and tests. However, it was noted that OpenSSL's provider does not advertise SLH-DSA signature schemes for TLS-SIGALG capability, which means that even with .NET support, OpenSSL will not use these certs for TLS handshakes until upstream support is added.
• Key Discussion:
  • Multiple reviewers noted that SLH-DSA is not yet usable for TLS because OpenSSL does not advertise these signature schemes (see OpenSSL code reference).
  • The conclusion was that until OpenSSL adds support, .NET cannot use SLH-DSA certs for TLS, and tests for these scenarios should be disabled or skipped.

---

2. PR #119265 (September 2025) - Use forTls parameter to enable TLS-compatible certificate key types while maintaining platform compatibility

• Summary: This PR introduced logic to select appropriate key types for TLS tests, excluding SLH-DSA on platforms where it is not supported by OpenSSL for TLS handshakes.
• Key Discussion:
  • rzikminvestigated test failures on Alpine and CentOS, finding that OpenSSL 3.5.1 does not advertise SLH-DSA for TLS-SIGALG, causing SslStream handshakes to fail with "unknown certificate type".
  • The workaround was to disable SLH-DSA certs for TLS tests on Linux until OpenSSL adds support.
  • rzikmopened issue #119573 to track this limitation and make it discoverable for others.

---

3. PR #114060 (March 2025) - SLH-DSA implementation for OpenSSL

• Summary: Added OpenSSL implementation for SLH-DSA, following the ML-DSA pattern.
• Key Discussion:
  • The PR implemented the algorithm but did not address TLS integration, as OpenSSL itself does not yet support SLH-DSA for TLS handshakes.
  • Discussion referenced the need to wait for upstream OpenSSL support for full TLS integration.

---

4. Issue #113506 (March 2025) - Add SLH-DSA

• Summary: This is the umbrella issue for adding SLH-DSA support as part of post-quantum cryptography.
• Key Discussion:
  • The API and implementation work is tracked here, but it is noted that TLS support depends on OpenSSL advertising the signature algorithms.

---

5. Issue #116282 (June 2025) - [API Proposal]: SLH-DSA

• Summary: API proposal for SLH-DSA, including integration points for X509, SignedXml, COSE, and TLS.
• Key Discussion:
  • The proposal acknowledges that actual TLS support is contingent on OpenSSL advertising the signature algorithms.

---

6. PR #119573 (September 2025) - This issue itself

• Summary: Documents the current state: attempts to use SLH-DSA certificates with SslStream fail with "unknown certificate type" due to lack of OpenSSL support for these signature schemes in TLS.
• Key Discussion:
  • The issue is not unexpected, as the relevant RFC is still a draft and OpenSSL has not yet implemented support.

---

7. PR #119265 (September 2025) - Discussion Thread

• Key Comments:
  • rzikm "Got it, the OpenSSL provider does not advertise support for SLH-DSA-* family for TLS-SIGALG capability, only ML-DSA... I think we need to wait with testing these cert in TLS until they are advertised by the common OpenSSL provider. In the meanwhile, we can keep ML-DSA."
  • rzikm "Disabled SLH-DSA for linux for now, Opened #119573 to track that (and so that the issue is discoverable if anyone hits it)"

---

8. Related: Issue #117003 (June 2025) - Support SLH-DSA with Windows NCrypt

• Summary: Tracks future work to support SLH-DSA on Windows once the OS adds support. Not directly about OpenSSL, but relevant for the overall ecosystem readiness.

---

9. Related: Issue #117002 (June 2025) - Support SLH-DSA with Windows BCrypt

• Summary: Similar to above, tracks future work for Windows BCrypt support.

---

10. General Context:

• OpenSSL's current state: As of OpenSSL 3.5.1 (July 2025), SLH-DSA signature schemes are not advertised for TLS-SIGALG, so they cannot be used for TLS handshakes. This is an upstream limitation, not a .NET/runtime bug.
• .NET's position: .NET has implemented SLH-DSA support in X509 and cryptography APIs, but SslStream (and thus TLS) cannot use these certs until OpenSSL adds support.

---

Conclusion

• Root Cause: OpenSSL does not currently advertise SLH-DSA signature schemes for TLS, so SslStream handshakes with SLH-DSA certs fail with "unknown certificate type".
• Status: .NET support is implemented, but TLS usage is blocked by OpenSSL. The issue is tracked for future enablement.
• Workarounds: Use ML-DSA or other supported algorithms for TLS until OpenSSL adds SLH-DSA support.
• Tracking: Issue #119573 is the canonical place to track this limitation.

---

If you need to reference a single discussion for the canonical answer, use the comments from PR #119265 and this issue (#119573), as they contain the most direct diagnosis and tracking for this limitation.