Default dev certificate not working with Http3
Daniel-Genkin-MS-2 opened this issue · 13 comments
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
I tried to run the Http3Sample but found that the server rejects all the Http3 requests made to it from the browser (Edge Version 101.0.1210.47). However, a simple C# script that I wrote can reach the server over Http/3:
using System.Net;
var handler = new SocketsHttpHandler();
handler.SslOptions = new System.Net.Security.SslClientAuthenticationOptions
{
RemoteCertificateValidationCallback = (_, __, ___, ____) => true
};
HttpClient client = new HttpClient(handler);
var result = await client.SendAsync(new HttpRequestMessage(HttpMethod.Get, "https://127.0.0.1:5001")
{
Version = HttpVersion.Version30,
VersionPolicy = HttpVersionPolicy.RequestVersionExact
}, CancellationToken.None);
Console.WriteLine(await result.Content.ReadAsStringAsync());I also noticed that if I replace the existing certificate
var cert = CertificateLoader.LoadFromStoreCert("localhost", StoreName.My.ToString(), StoreLocation.CurrentUser, false);with a newly generated one (see script below), then I can connect to the server via WebTransport APIs in DevTools. The main browser still is refused though.
var now = DateTimeOffset.UtcNow;
SubjectAlternativeNameBuilder sanBuilder = new();
sanBuilder.AddDnsName("localhost");
using var ec = ECDsa.Create(ECCurve.NamedCurves.nistP256);
CertificateRequest req = new("CN=localhost", ec, HashAlgorithmName.SHA256);
req.CertificateExtensions.Add(new X509EnhancedKeyUsageExtension(new OidCollection
{
new("1.3.6.1.5.5.7.3.1") // serverAuth
}, false));
req.CertificateExtensions.Add(new X509KeyUsageExtension(X509KeyUsageFlags.DigitalSignature, false));
req.CertificateExtensions.Add(sanBuilder.Build());
using var crt = req.CreateSelfSigned(now, now.AddDays(14));
cert = new(crt.Export(X509ContentType.Pfx));The above code snippet was taken from https://github.com/wegylexy/webtransport, which seems to have a WebTransport and http/3 server working in C#.
Expected Behavior
I should be able to fetch the Hello, World! Http/3 via the browser. However, I always either get Hello, World! Http/2 or the browser connection refused message.
Steps To Reproduce
- Modify the line 43:
options.ListenAnyIP(5001, listenOptions =>To become
options.Listen(IPAddress.Any, 5001, listenOptions =>(This avoids the known bug that prevents the connection)
- Open a browser and go to
https://localhost:5001.
You can also modify the listenOptions.Protocols to only include Http/3. In those cases, it always times out instead of just always defaulting to Http/2.
Exceptions (if any)
No response
.NET Version
No response
Anything else?
Microsoft Visual Studio Enterprise 2022 (64-bit) - Preview
Version 17.3.0 Preview 1.0
(aspnetcore) PS C:\aspnetcore> dotnet --info
.NET SDK:
Version: 7.0.100-preview.5.22228.6
Commit: f59d2cfdfe
Runtime Environment:
OS Name: Windows
OS Version: 10.0.22000
OS Platform: Windows
RID: win10-x64
Base Path: C:\aspnetcore.dotnet\sdk\7.0.100-preview.5.22228.6\
global.json file:
C:\aspnetcore\global.json
Host:
Version: 7.0.0-preview.5.22254.12
Architecture: x64
Commit: 874c6a9375
.NET SDKs installed:
7.0.100-preview.5.22228.6 [C:\aspnetcore.dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.0-preview.5.22228.1 [C:\aspnetcore.dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.0-preview.5.22226.6 [C:\aspnetcore.dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0-preview.5.22254.12 [C:\aspnetcore.dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 7.0.0-preview.5.22226.7 [C:\aspnetcore.dotnet\shared\Microsoft.WindowsDesktop.App]
Triage: let's see what we can do to make the dev experience better.
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
I was in doubt if http3 needs a certificate inside the application in the container, because my certificates are in the proxy/nginx.
my application doesn't even know if it has a certificate or not.
HTTP/3 always requires a certificate, there's no un-encrypted format for it. In this case it would be encrypted between the proxy and your app.
However, does your proxy even support HTTP/3 proxying? Even if it supports HTTP/3 on the front end, it's likely downgrading on the back end. Last I heard it barely supported HTTP/2 proxying.
from what I understand, within my kestrel I have to inform a certificate, BUT
for http3 it needs https, for https it needs a certificate for kestrel, and my certificate is on the proxy.
and we're not even talking dev experience better.
Is there a specific reason you want HTTP/3 behind the proxy? HTTP/3's benefits are mainly on public networks, using HTTP/1.x or HTTP/2 between the proxy and your app is normally fine. The proxy should be able to handle HTTP/3 for you and downgrade for the backend.
@Tratcher I'm looking for network requirements, with performance latency and etc...
however, if the "proxy, nginx service mesh" delivers http3 to me, and my kestrel uses http, I believe that the kestrel using http3 could also be more harmonic
Not necessarily. A) you'll have to find out if your proxy even supports proxying it. B) HTTP/3 was designed for unstable external networks, it's not especially helpful on stable internal networks. And since it requires encryption, that adds overhead that HTTP/1.x wouldn't have for the backend.
any updates on this? it's been such a long time
@vsg24 What action are you looking for here? Based on the back and forth, it seems like there was some question as to whether the scenario was even worthwhile. Is the issue that the sample doesn't work as written? If so, have you confirmed in a more recent build of aspnetcore?
We might fix a bug in a sample app, but HTTP/3 isn't a focus in 9.0.