2024567 - Add mTLS support for HTTP3

Status: UNCONFIRMED

(Core :: Networking, enhancement, P5)

Description

[portbackward]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

1. Imported a mTLS certificate to Firefox
2. Opened a selfhosted HTTPS website with mTLS and HTTP3 enabled on the server which requests the mTLS certificate imported to Firefox
3. Firefox prompts for the certificate and the first connect works, all following connections fail

Actual results:

The issue was troubleshooted on the server side:
https://github.com/nginx/nginx/issues/817

Based on above results, Firefox sends the mTLS certificate on the first request via HTTP2 which works, afterwards Firefox switches to HTTP3 and stops sending the mTLS certificate. All following connections attempts fail.

Expected results:

Firefox should be able to send the mTLS certificate via HTTP3, this would fully fix the issue discovered.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[portbackward]

Attached server side log files (NGINX error.log):

cat error.log 
2026/03/07 18:16:09 [notice] 837#837: using the "epoll" event method
2026/03/07 18:16:09 [notice] 837#837: nginx/1.28.2
2026/03/07 18:16:09 [notice] 837#837: OS: Linux 6.12.54-Unraid
2026/03/07 18:16:09 [notice] 837#837: getrlimit(RLIMIT_NOFILE): 40960:40960
2026/03/07 18:16:09 [notice] 837#837: start worker processes
2026/03/07 18:16:09 [notice] 837#837: start worker process 894
2026/03/07 18:16:09 [notice] 837#837: start worker process 895
2026/03/07 18:16:09 [notice] 837#837: start worker process 896
2026/03/07 18:16:09 [notice] 837#837: start worker process 897
2026/03/07 18:16:09 [notice] 837#837: start cache manager process 898
2026/03/07 18:16:09 [notice] 837#837: start cache loader process 899
2026/03/07 18:16:13 [info] 895#895: *7 quic fixed bit is not set while parsing quic packet, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *7 quic unknown transport param id:0x11, skipped while handling frames, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *7 quic reserved transport param id:0xff02de1a, skipped while handling frames, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *7 quic unknown transport param id:0x20, skipped while handling frames, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *7 quic fixed bit is not set while parsing quic packet, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *7 quic fixed bit is not set while parsing quic packet, client: 192.168.1.153, server: 0.0.0.0:443
2026/03/07 18:16:13 [info] 895#895: *13 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/stylesheets/theme-light.css HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *14 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/stylesheets/theme-next.css HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *15 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/stylesheets/style.css HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *16 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/src/runtime.js HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *17 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/src/login.js HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *18 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/images/icon-color.svg HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *19 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /assets/v0.102.0/images/app-icons/ios/apple-touch-icon.png HTTP/3.0"
2026/03/07 18:16:13 [info] 895#895: *20 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /favicon.ico HTTP/3.0"
2026/03/07 18:16:14 [info] 895#895: *21 client sent no required SSL certificate while reading client request, client: 192.168.1.153, server: tn.*, request: "GET /login HTTP/3.0"

Comment 3

[Max Inden]

Yes, Firefox does not support mTLS on HTTP/3, nor will it any time soon. You can track this work on https://github.com/mozilla/neqo/issues/112.

Still, I would expect Firefox to fallback to HTTP/2 once the HTTP/3 connection fails.

Would you mind providing us with more logs, see documentation below. Please select the networking and http/3 preset. Also note, given that the logs potentially contain personal data, please share them to [e-mail].

https://firefox-source-docs.mozilla.org/networking/http/logging.html#using-about-logging

In case the fallback currently doesn't work, Bug 1953459 will potentially fix it.

Comment 4

[portbackward]

Hi Max, thanks for your reply and interest.
I share your opninion, that upon a failed HTTP/3 connection a fallback to HTTP/2 should be used by Firefox, as long HTTP/3 mTLS is not supported.
Per my testing the fallback is not working and I just sent the requested logs to [e-mail].

Would be great if the fallback could be provided with an upcoming release and full HTTP/3 mTLS support would be added to your roadmap.

Let me know if more data can be provided.

Comment 5

[Max Inden]

In case the fallback currently doesn't work, Bug 1953459 will potentially fix it.

@portbackward does the fallback properly work with a recent Firefox Nightly and network.http.happy_eyeballs_enabled set to true in about:config?

Comment 6

[gummiangler]

@Max Inden
For me this is not working with the latest nightly and HTTP3 mTLS. Still not asking for certificate. Is there any way to help fixing this issue?

Comment 7

[portbackward]

Hi @Max Inden

tested with the latest nightly firefox-151.0a1:

• With network.http.happy_eyeballs_enabled set to false (default value in nightly release), the fallback to HTTP2 is not working
• With network.http.happy_eyeballs_enabled set to true (changed as you requested), the fallback to HTTP is indeed working
• With both settings mTLS is still not working with HTTP3

Best regards

Comment 8

[Max Inden]

For me this is not working with the latest nightly and HTTP3 mTLS. Still not asking for certificate. Is there any way to help fixing this issue?

@gummiangler not working as in the fallback to HTTP/2 is not working, or HTTP/3 mTLS is not working. The former should work with network.http.happy_eyeballs_enabled true, thus worth investigating why it doesn't on your machine. The latter I don't think we will get to. (Not to say that you can't contribute it, if you really want it.)

With network.http.happy_eyeballs_enabled set to true (changed as you requested), the fallback to HTTP is indeed working

Thanks @portbackward for testing.

With both settings mTLS is still not working with HTTP3

Yes, as mentioned above this is expected.

We don't have any plans today to support HTTP/3 mTLS, thus setting P5 here. Note that P5 does not mean we won't accept contributions.

Comment 9

[gummiangler]

@Max Inden
I am using firefox nightly 151.0a1 on linux. network.http.happy_eyeballs_enabled is enabled but i still cannot access websites with HTTP/3 requiring mTLS because there is no fallback to HTTP/2. I reimported the certificate and restartet the browser but it is still not prompting me to accept the certificate.

Comment 10

[Max Inden]

but i still cannot access websites with HTTP/3 requiring mTLS because there is no fallback to HTTP/2.

Yes, that is expected. Firefox does not support mTLS on HTTP/3 today.

Comment 11

[gummiangler]

@Max Inden

I think we are talking past each other. I fully understand that HTTP/3 mTLS is not supported and won't be implemented anytime soon.

My issue is specifically about the HTTP/2 fallback, which is apparently still broken for me on Linux, even with network.http.happy_eyeballs_enabled set to true.

If the fallback were working correctly on my machine, Firefox should silently drop down to HTTP/2 upon the HTTP/3 failure and prompt me for my client certificate. Instead, the connection just fails completely and I never get the certificate prompt.

It seems the fallback mechanism itself has a bug under certain conditions (like on Linux). What logs or specific info do you need from my side to help debug why the HTTP/2 fallback fails here?

Comment 12

[Max Inden]

Thanks for clarifying!

Two follow-ups to help us narrow down the fallback issue:

1. Platform scope of the fallback failure — you mention the HTTP/2 fallback fails on Linux even with network.http.happy_eyeballs_enabled set. Have you been able to reproduce the fallback failure (connection failing completely without a cert prompt) on Windows or macOS as well, or only on Linux? That'll help us tell whether it's a general fallback bug or something Linux-specific.

2. HTTP log captured via the Firefox Profiler — would you be able to capture a log of the failing case? Instructions: https://firefox-source-docs.mozilla.org/networking/http/logging.html#using-about-logging

   • Please use the Firefox Profiler option in about:logging (rather than logging to a file) with the HTTP/3 preset selected. The profiler integration is much easier for us to work with — it opens a new tab with the captured profile, which you can share as a single link instead of juggling per-process log files, and it lets us correlate the network events with everything else happening in the browser at the same time.

   • Please capture it in a fresh Firefox profile (about:profiles → "Create a New Profile"), import only the mTLS cert needed to reproduce, then start logging → reproduce → stop logging. HTTP logs include URLs, cookies, and auth headers from whatever profile they're captured in, so a clean profile avoids attaching anything from your normal browsing.