Closed Bug 1120350 Opened 9 years ago Closed 4 years ago

Firefox unable to use client certificates in Windows certificate store

Categories

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

x86_64
Windows
defect

Tracking

()

RESOLVED DUPLICATE of bug 1586915
Tracking Status
firefox-esr68 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix

People

(Reporter: pysrisur, Unassigned, NeedInfo)

References

(Depends on 1 open bug)

Details

(Keywords: csectype-other, Whiteboard: [psm-backlog])

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; Tablet PC 2.0; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

Client certificate is mandated by some applications during TLS client challenge. Microsoft IE and Google Chrome browsers use MS CNG API to use the client certificate in windows store. However, Firefox has a certificate store of its own, and does not recognize the client certificate(s) in windows store. 

Try connecting to any web application that challenges for client certificate authentication from Firefox browser.  Firefox simply fails to respond to TLS client auth challenge.




Actual results:

Firefox users are unable to connect with web apps that challenge the browser for TLS client auth. The same web app can be accessed from Microsoft IE, and Google Chrome browsers. It would be great if users can have the same seamless application access experience, no matter which browser they use.


Expected results:

Firefox browser on Windows is unable to connect with applications demanding TLS client authentication, as Firefox does not recognize client certificates in Windows store. When a plugin that imports clients certs from Windows store is available, Firefox on Windows will be able to respond to TLS client authentication challenge, and allow users to connect with apps demanding TLS client auth.

An NSSCAPI plugin module that imports client certificates to Firefox, using Microsoft CNGAPI will fix the issue.
Severity: normal → critical
Keywords: csectype-other
Assignee: nobody → kwilson
Severity: critical → normal
Status: UNCONFIRMED → NEW
Component: Untriaged → CA Certificates
Ever confirmed: true
Product: Firefox → mozilla.org
Version: unspecified → other
Pretty sure this is a PSM/NSS issue, not a CA cert policy one. I also would have sworn we had this on file already. Brian, do you know more?
Assignee: kwilson → nobody
Component: CA Certificates → Security: PSM
Flags: needinfo?(brian)
Product: mozilla.org → Core
Version: other → Trunk
It's pretty obvious to me that Firefox should use the windows certificate store for finding the user's *client* certificates instead of using NSS's certificate store. However, I also expect that nobody will want to work on this any time soon. So, a motivated contributor would probably have to do all the work.
Flags: needinfo?(brian)
Hi guys,

Is there a workaround for this scenario, for example to install some Security Modules and Devices in order to specify Firefox to use Windows certificate store.

Thanks in advance,
Vladimir
Hi, can someone please give an update on this.
There is no update - we are not currently working on this.
(In reply to David Keeler [:keeler] (use needinfo) from comment #6)
> There is no update - we are not currently working on this.

Thanks.
(In reply to pysrisur@microsoft.com from comment #0)
> An NSSCAPI plugin module that imports client certificates to Firefox, using
> Microsoft CNGAPI will fix the issue.

A CAPI module was added in-tree in 2005: https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/capi/)

However it has not been modified since then, and it was later disabled in Firefox builds: https://hg.mozilla.org/projects/nss/rev/e744d78d0dcc


Can anyone speak to what is currently missing or broken in the CAPI module that would allow it to be used even experimentally in test builds? I found a 10-year-old thread (https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/aL7UHhmF454), but otherwise I can't seem to find anywhere that is tracking this.
Flags: needinfo?(nelson)
Flags: needinfo?(dkeeler)
Flags: needinfo?(rrelyea)
I wasn't aware that existed. I am not familiar with its capabilities.
Flags: needinfo?(dkeeler)
When it was written, it could access user certificates in the Microsoft database. It does not see root certificates. It hasn't been maintained in quite some time, so I don't know if it has bit-rotted. If you want to supply that capability, it might be a good place to start. The code worked, but was not extensively tested, so there could be issues.

bob
Flags: needinfo?(rrelyea)
I had a look at the CAPI module. It does build, but it uses the old Windows crypto API. As a result, it doesn't support modern algorithms like SHA-256 and doesn't work with TLS 1.2 or 1.3. It would have to be updated to CNG (the new crypto API).
I work at Microsoft and am experiencing this issue. I would be happy to test any fixes or perform any troubleshooting necessary to help get this resolved.
Does setting the preference:

security.enterprise_roots.enabled

help any with regards to this?

We did some Window cert work here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1265113

for enterprise roots.
Unfortunately, no. Supporting client certificates provided by native (OS) APIs would be much more work.

Would appreciate this feature too, because Enterprise certificate based applications do not work with Firefox, but with Chrome.
I'd like to keep Chrome outside the company....

FYI, My company just auto uninstalled & blocked Firefox and Thunderbird from all corporate assets.
Not honoring the system certificate store was the reason.
This will start to cause a larger decrease in installs & usage as this propagates.
Had to send this from chrome!

(In reply to Jestre from comment #25)

FYI, My company just auto uninstalled & blocked Firefox and Thunderbird from all corporate assets.
Not honoring the system certificate store was the reason.
This will start to cause a larger decrease in installs & usage as this propagates.
Had to send this from chrome!

Are you using client certificates specifically? Or just trying to read CAs from the system store?

If this was enabled, it is possible that Microsoft would be able to get Firefox working for Azure Active Directory Conditional Access bypass, so enterprise users implementing compliance policies or multi-factor authentication bypasses would be able to use FireFox (alongside Chrome, Edge, IE):

https://social.technet.microsoft.com/Forums/en-US/eafe0951-3929-46d1-bcbd-bbe5c006f0e4/firefox-not-compatible-with-conditional-access-why?forum=microsoftintuneprod#ebc8065d-bd5f-466a-aa20-c9014733f29a

OS: Windows 8.1 → Windows

The reason for me to use the Windows certificate store for client certificates, is that they can be marked as non-exportable. With Firefox, there's no way to prevent someone from making a backup of the client certificates.

In addition to Anthony, I am on the other side - a user, whose company administratively has marked the user certificate as non-exportable in Windows certstore. As result I cannot use Firefox productively and have to fallback to another pretty uncomfortable browser.

I think this might work in current Nightly now. Bug 1591269 and dependencies.

Firefox Nightly now supports using client auth certs directly from OS* storage - flip the pref "security.osclientcerts.autoload" to give it a try!

https://twitter.com/mozkeeler/status/1197592164756115456

I can get the current nightly working with that setting in our corporate intranet - excellent! Hope this gets rolled out asap.

I tried it also and I was able to see my client certificate from the Windows store in the FF certificates. However, the client cert authentication didn't work, it seems FF didn't send my certificate to the remote server and I always get the logon page.
In addition, I was not able to see the trusted CA certificates from the Windows store. I had to import the relevant ones manually into the FF store in order for the server cert to be accepted.

@lassenov The server cert issue is another one, and has a solution, see bug 1265113 (tl:dr; set security.enterprise_roots.enabled in about:config to true).

Thanks, Cailin. After enabling enterprise roots I can see the trusted CAs now, but the client cert authn still fails.
How can I find out why it fails?

No clue, I only happened to know the answer to that one question :D

Caitlin: are you using nightly or something else?

Depends on: osclientcerts

I am already able to see the client certs in the Windows store and in most of the cases the client cert authn works. However, there are cases, where it doesn't. How can I check what is wrong or collect traces for further analysis?

(In reply to Lyubomir from comment #42)

I am already able to see the client certs in the Windows store and in most of the cases the client cert authn works. However, there are cases, where it doesn't. How can I check what is wrong or collect traces for further analysis?

You can file a new bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM
It would be good to include things like what kinds of certificates work vs. don't, or if there are any server differences, and if you can, include a packet trace of the working/not working TLS handshakes.

Flags: needinfo?(lassenov)
Flags: needinfo?(lassenov)

I think we can go ahead and close this.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.