1966565 - Client TLS Certificate Support Broken in 138.0.2

Status: VERIFIED FIXED

(Core :: Security: PSM, defect, P1)

Description

[Mike]

Steps to reproduce:

1. Install a User Client Certificate in the Android system certificate store for a site requiring client certificate authorization.
2. Navigate to the site in Firefox Android.
3. Get dialog prompt to pick a user certificate.
4. Pick the correct user certificate.
5. Wait for the page to stop loading with no content actually displayed.
6. Refresh the page.

Actual results:

When Firefox 138.0.0 or 138.0.1 is used, the page loads properly and doesn't reprompt for the certificate.
With Firefox 138.0.2, the page reprompts for the certificate without loading the content (infinit3 loop with that page never loading).

Expected results:

The page should have loaded content after selecting the certificate, but I'll settle for the 138.0.0 and 138.0.1 behavior of it at least caching the user certificate selection for use during the page refresh bso the site can be reached.

Comment 1

[Mike]

The behavior in Firefox Android 139.0b7 currently matches the behavior in 138.0.0 and 138.0.1 pretty closely. It doesn't load or prompt initially and requires a manual refresh of the page to get the certificate prompt, unlike the 138.0.x series. But once a cert is selected, it works like 138.0.0 and 138.0.1 and requires refreshing the page again to get content to load.

Comment 2

[Mike]

Firefox Android Nightly 140.0a1-20250512213630 works exactly like 138.0.0 and 138.0.1 did. It promtpts immediately on navigating to the site, but then requires a refresh after certificate selection to get the content to load. But it does load rather than going into an infinite prompt-without-loading cycle like 138.0.2 does.

Comment 3

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

The severity field is not set for this bug.
:boek, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Mike]

Updating: Still broken as of 139.0.3

Comment 5

[Makoto Kato [:m_kato]]

Reporter, does this occurs on Firefox Beta (140)? It has a new fix for bug 1966033.

Comment 6

[Mike]

(In reply to Makoto Kato [:m_kato] from comment #5)

Reporter, does this occurs on Firefox Beta (140)? It has a new fix for bug 1966033.

Testing the Beta 140.0b7 (2016095855), it's actually more broken than Stable. The client certificate selection pop up never even appears now.
The broken Stable builds do present the system client certificate selection pop up, they just don't retain the selection when the page is refreshed, and won't render the page if a selection is necessary (even after a valid selection was made) unless manually refreshed.

Also, when 139 was still in Alpha, and then when it was still in Beta, the feature worked and a manual refresh of the page after selecting a certificate was the only work around required. But once 139 was released to Stable it stopped retaining the certificate selection after refresh and put you into an infinite loop of needing to select the certificate again after every refresh, then needing to refresh to get the page to render using that certificate that was selected.

Comment 7

[Mike]

Just for clarity, the site I'm using is a self-hosted personal site I've setup LetsEncrypt TLS on, and configured to require a Client certificate from a custom manually generated root CA.
In Chrome, navigating to the site pops up the client certificate picker with only the one relevant client certificate available (I have multiple installed in the system user certs database), and picking it immediately renders the page.

In Firefox Stable 138 thru 139 (inclusive) the system pop up for the client user certificates does pop up, and presents every installed client certificate as an option. Picking a certificate would them hide the pop up, but even when the correct certificate was selected the page never attempted to render anything.

In Firefox Stable from 138.0.0-138.0.3 (non-inclusive), Firefox Beta 138-139 (inclusive), and Firefox Alpha 138-140 (inclusive), picking the correct certificate from the pop up and then manually refreshing would retain the selection and render the page.

Comment 8

[Makoto Kato [:m_kato]]

I think that this should be handled/triaged by Security: PSM since this supports are implemented by bug 1813930. Moving Core: Security: PSM. Sorry for late.

Comment 9

[Mike]

FYI, this item on the Ideas board has been loosely tracking the versions it does and does not work in: https://connect.mozilla.org/t5/ideas/allow-personal-certificates-in-firefox-mobile/idi-p/176#feedback-success

From there:

• 139.0.4 works and automatically re-renders after certificate selection with no need to manually refresh.
• 140.0.b7 and 140.0.b10 are both broken and won't even prompt.

Comment 10

[Dana Keeler (she/her) [:keeler]]

Would you be able to use Wireshark or similar to get the certificate_authorities list the server is sending in the certificate request?

Comment 11

[Mike]

(In reply to Dana Keeler (she/her) [:keeler] from comment #10)

Would you be able to use Wireshark or similar to get the certificate_authorities list the server is sending in the certificate request?

I assume you don't care very much what the client device is, you just want to see an example of the TLS handshake? I can setup a wireshark capture easily from a computer, but much less easily from my Android device.

Since the logs posted here are effectively public, I'm going to setup a quick instance on a throw away domain, verify it acts the same, and capture those logs. I should have something in the next couple days.

Comment 13

[Dana Keeler (she/her) [:keeler]]

Steven, since you're having the same problem, would you be able to use Wireshark or similar to get the certificate_authorities list the server is sending in the certificate request?

Comment 14

[Steven]

I was able to capture the TLS traffic, however the certificate request is encrypted and I'm having trouble figuring out how to get Firefox for Android to dump the TLS session keys. Can you point me in the right direction?

In case it helps, I got the certificate_authorities field from the desktop version of Firefox. Here is the relevant dump:

0000   00 2f 00 1c 00 1a 00 18 30 16 31 14 30 12 06 03   ./......0.1.0...
0010   55 04 03 0c 0b 53 74 65 76 65 6e 27 73 20 43 41   U....Steven's CA

And here is how Wireshark decodes is:

Comment 15

[Steven]

Sorry, I accidentally sent an incomplete reply. Here is how Wireshark decodes the previous dump:

Extension: certificate_authorities (len=28)
    Type: certificate_authorities (47)
    Length: 28
    Distinguished Names Length: 26
    Distinguished Names (26 bytes)
        Distinguished Name Length: 24
        Distinguished Name: (id-at-commonName=Steven's CA)
            RDNSequence item: 1 item (id-at-commonName=Steven's CA)
                RelativeDistinguishedName item (id-at-commonName=Steven's CA)
                    Object Id: 2.5.4.3 (id-at-commonName)
                    DirectoryString: uTF8String (4)
                        uTF8String: Steven's CA

Comment 16

[Dana Keeler (she/her) [:keeler]]

You could maybe run wireshark on the server? In any case, presumably the issuer distinguished name of your client auth certificate matches byte-for-byte what the server is requesting?

Comment 17

[Steven]

The capture I got was already taken by running Wireshark on the server, however in order to decrypt the TLS traffic I had to get Firefox to dump the TLS session keys (the free version of Nginx, does not allow to easily dump these keys from the server side) .

The issuer's name in the client certificate is identical to the one requested by the server.

Comment 19

[Dana Keeler (she/her) [:keeler]]

Attachment: Bug 1966565 - properly convert binary caNames to strings for android client auth selection r?jschanck

Previously, the implementation tried to use TextDecoder as an easy way to
convert an array of bytes to a JavaScript string (to use with btoa).
This would have never worked, because bytes with value 128-255 would have been
replaced with U+FFFD (the unicode replacement character), which a) would have
lost data and b) would not have worked with btoa.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/537ce4b12dd8
https://hg.mozilla.org/integration/autoland/rev/a972425ff5c8
properly convert binary caNames to strings for android client auth selection r=jschanck

Comment 21

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/a972425ff5c8

Comment 22

[Mike]

Does this fix the original problem, or just the new one that was linked?

The original reported problem was when certificate functionality did seem to still work sort of, but the client certificate selection wasn't retained on refresh, and selecting a certificate didn't cause a re-render of the site. In the meantime, basic certificate functionality was completely broken as well.

Comment 23

[Dana Keeler (she/her) [:keeler]]

I had to fix the new problem before trying to untangle the original issues you were describing. Let's verify this bug first and then if you're still having problems, go ahead and file a new bug.

Comment 24

[Mike]

(In reply to Dana Keeler (she/her) [:keeler] from comment #23)

I had to fix the new problem before trying to untangle the original issues you were describing. Let's verify this bug first and then if you're still having problems, go ahead and file a new bug.

It sounds like you incorrectly merged https://bugzilla.mozilla.org/show_bug.cgi?id=1975296 into this existing bug. That bug blocked this one from being investigated, but was not a duplicate, and that's the bug you've solved.

Is there any way to unmerge so you can close the proper bug report instead? Or is there a way to duplicate all the history and discussion from this bug, which is still pertinent to this bug that isn't closed or fixed, into a new bug?

Comment 25

[Dana Keeler (she/her) [:keeler]]

To be fair, you described the exact symptoms of bug 1975296 in comment 6, which is why I marked it as a duplicate of this one.
In any case, bug are cheap. Please wait until this bug has been verified and then file a new bug if you're still having problems. You can link it to this one with the "see also" field.

Comment 27

[Vasilica Tamas (Android QA) [:vtamas]]

Attachment: CertificateDialog.mp4

This issue is verified as fixed on Firefox for Android Nightly 142 (2025-07-17) using a Samsung S24 Ultra (Android 15). Confirming that the page prompts for the certificate only once, on the initial load and the certificate selection dialog does not appear again, regardless of how many times the page is refreshed.

Comment 28

[Mike]

(In reply to Vasilica Tamas (Android QA) [:vtamas] from comment #27)

Created attachment 9501453 [details]
CertificateDialog.mp4

This issue is verified as fixed on Firefox for Android Nightly 142 (2025-07-17) using a Samsung S24 Ultra (Android 15). Confirming that the page prompts for the certificate only once, on the initial load and the certificate selection dialog does not appear again, regardless of how many times the page is refreshed.

Testing note: Requires turning on the "Allow third party certificates" setting in the Secret Menu.

Also confirmed on Firefox Nightly 142.0a1 using a Google Pixel Fold running CalyxOS Android 15. Immediately prompts for the certificate, only offers certificates that match the site's client certificate Root CA, and immediately renders the destination site after selection. Refreshing and site navigation never cause certificate reprompts in the same browser session.