QUIC: Support hosting self-signed certificates

[JamesNK]

QUIC should support the same certificates that SslStream+Kestrel does. For example, a server hosting a website using an untrusted, self-signed certificate.

The server certificate is specified using SslServerAuthenticationOptions

I believe today that QUIC will fail when using an untrusted certificate. In this situation, the error reported by QUIC is not helpful about what the problem is. I don't have it on hand, but it was something like "Error: invalid state".

• Test System.Net.Quic server with invalid certificates
  • Self-signed
  • Outdated algorithms
  • Host name mismatch
• Where possible, match SslStream behavior
• If an unusable certificate is configured, provide a clear error with enough information to help the dev fix the problem

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

Issue Details

---

QUIC should support the same certificates that SslStream+Kestrel does. For example, a server hosting a website using an untrusted, self-signed certificates.

The server certificate is specified using SslServerAuthenticationOptions

I believe today that QUIC will fail when using an untrusted certificate. In this situation, the error reported by QUIC is not helpful about what the problem is. I don't have it on hand, but it was something like "Error: invalid state".

• Test System.Net.Quic server with invalid certificates
• Where possible, match SslStream behavior
• If an invalid certificate is configured, provide a clear error with enough information to help the dev fix the problem

Author:	JamesNK
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	-

[wfurt]

We need to plumb "normal" remote certificate validation callback. That has right now some platform challenges but it should work eventually.

[JamesNK]

I searched msquic to see what content they have about certs. Maybe relevent:

A certificate needs to be available for the server to function.
On Windows, the following PowerShell command can be used to generate a self
signed certificate with the correct settings. This works for both Schannel
and OpenSSL TLS providers, assuming the KeyExportPolicy parameter is set to
Exportable. The Thumbprint received from the command is then passed to this
sample with -cert_hash:PASTE_THE_THUMBPRINT_HERE

New-SelfSignedCertificate -DnsName $env:computername,localhost -FriendlyName MsQuic-Test -KeyUsageProperty Sign -KeyUsage DigitalSignature -CertStoreLocation cert:\CurrentUser\My -HashAlgorithm SHA256 -Provider "Microsoft Software Key Storage Provider" -KeyExportPolicy Exportable

On Linux, the following command can be used to generate a self signed
certificate that works with the OpenSSL TLS Provider. This can also be used
for Windows OpenSSL, however we recommend the certificate store method above
for ease of use. Currently key files with password protections are not
supported. With these files, they can be passed to the sample with
-cert_file:path/to/server.cert -key_file path/to/server.key
openssl req  -nodes -new -x509  -keyout server.key -out server.cert

https://github.com/microsoft/msquic/pull/1151/files

[JamesNK]

msquic issue about remote certificate validation: microsoft/msquic#1063

Closed with a PR so I presume it is supported.

[wfurt]

While that is interesting for msquic itself, it needs to work with any certificate provided by .NET (Windows, Linux & macOS (FreeBSD)) The validation callback gives you native pointer at the moment. We will need some mechanics to turn it into C# X509Certificate object. May be available in week or two. For now (and testing) we may simply accept any certificate.

(note that ServerCertificateContext is in pipeline after that - it should work as well but it will need more msquic changes)

[karelz]

Triage: Needed for testing (ours and early adopters).