Problems importing PKCS #12 client certs
Gen Kanai
Bug 542441 claims that Gecko/Firefox is not importing PKCS#12 client certs.
https://bugzilla.mozilla.org/show_bug.cgi?id=542441
I am also being told by the bug filer that IE, Opera, Chrome and Safari
have no problems importing PKCS#12 certs.
Could those of you who have more experience with PKCS#12 certs take a
look at this bug and provide feedback? I'm a bit surprised that Firefox
doesn't support PKCS#12.
Thank you,
Gen
--
Gen Kanai
http://blog.mozilla.com/gen/
Subrata Mazumdar
My experience so far is that PSM Certificate Manager is never launched
when PKCS#12 link is clicked. Not on Windows. Not on Linux (as described
by the bug filer). Do not remember for Mac OS X.
Here is what I think is the explanation for the behavior on windows:
On Windows PKCS#12 file type is associated with MS Crypto certificate
manager. So when someone clicks on the PKCS#12 file link, Windows crypto
manager is launched for importing the keys/certificates.
Since IE and Chrome (do not know about Safari and Opera) uses the same
Windows Crypto DB/Manager, the imported keys/certificates in PKCS#12 is
always visible to both browsers. FF does not uses Windows CertDB - FF
uses it's own CertDB. As a result, imported key/cert is not visible in
PSM certificate manager.
--
Subrata
Wan-Teh Chang
<subrata....@ieee.org> wrote:
> Hi,
>
> My experience so far is that PSM Certificate Manager is never launched when
> PKCS#12 link is clicked. Not on Windows. Not on Linux (as described by the
> bug filer). Do not remember for Mac OS X.
>
> Here is what I think is the explanation for the behavior on windows:
>
> On Windows PKCS#12 file type is associated with MS Crypto certificate
> manager. So when someone clicks on the PKCS#12 file link, Windows crypto
> manager is launched for importing the keys/certificates.
>
> Since IE and Chrome (do not know about Safari and Opera) uses the same
> Windows Crypto DB/Manager, the imported keys/certificates in PKCS#12 is
> always visible to both browsers. FF does not uses Windows CertDB - FF uses
> it's own CertDB. As a result, imported key/cert is not visible in PSM
> certificate manager.
This is correct.
The user who reported that bug did not realize that Firefox is not
using the Windows system certificate store, so the user had the
wrong expectations.
In any case, both Nelson and I have posted comments in that
bug report.
Wan-Teh
Chris Hills
> Since IE and Chrome (do not know about Safari and Opera) uses the same
> Windows Crypto DB/Manager, the imported keys/certificates in PKCS#12 is
> always visible to both browsers. FF does not uses Windows CertDB - FF
> uses it's own CertDB. As a result, imported key/cert is not visible in
> PSM certificate manager.
You can install the third party pkcs module from secure endpoints
(kpkcs11.dll) in order to use client certificates from the windows
certificate store. Unfortunately it does not read CA certificates, and
you cannot install new certificates into the windows store from firefox.
Perhaps there is place for a fork of firefox (perhaps an "enterprise"
version) that uses the windows certificate store and dispenses with the
local certificate store. I understand that support for MSI installation
is already being worked on.
Gen Kanai
On 2/17/10 9:42 AM, Wan-Teh Chang wrote:
On Sun, Feb 14, 2010 at 6:57 PM, Subrata Mazumdar <subrata....@ieee.org> wrote:
Hi, My experience so far is that PSM Certificate Manager is never launched when PKCS#12 link is clicked. Not on Windows. Not on Linux (as described by the bug filer). Do not remember for Mac OS X. Here is what I think is the explanation for the behavior on windows: On Windows PKCS#12 file type is associated with MS Crypto certificate manager. So when someone clicks on the PKCS#12 file link, Windows crypto manager is launched for importing the keys/certificates. Since IE and Chrome (do not know about Safari and Opera) uses the same Windows Crypto DB/Manager, the imported keys/certificates in PKCS#12 is always visible to both browsers. FF does not uses Windows CertDB - FF uses it's own CertDB. As a result, imported key/cert is not visible in PSM certificate manager.
This is correct. The user who reported that bug did not realize that Firefox is not using the Windows system certificate store, so the user had the wrong expectations. In any case, both Nelson and I have posted comments in that bug report.
Do you see the logic of the user who had the wrong expectations here? Is there logic in reassessing the current functionality as it is shipped?
I have been told that Firefox is the only one of the 5 major desktop browsers that functions in the way that it does (i.e. the other browsers all have handlers for application/x-pkcs12.)
-- Gen Kanai
Eddy Nigg
I have been told that Firefox is the only one of the 5 major desktop browsers that functions in the way that it does (i.e. the other browsers all have handlers for application/x-pkcs12.)
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org Blog: http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg
Wan-Teh Chang
>
> Lets see....Internet Explorer (obviously), Safari and Chrome. Which other
> major browser? :-)
It's Opera.
Gen: I agree that Firefox should have a handler for application/x-pkcs12
that imports a PKCS #12 file into the NSS certificate/key databases.
Wan-Teh
Jean-Marc Desperrier
> Perhaps there is place for a fork of firefox (perhaps an "enterprise"
> version) that uses the windows certificate store and dispenses with the
> local certificate store. I understand that support for MSI installation
> is already being worked on.
I think it would make much, much more sense to use the OS store for
private keys across all Firefox versions !
This is the strategy followed by Chrome.
In fact, there is code to do that in NSS but I'm afraid it's currently
not really maintained :
Mac OS X version :
http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/nssmkey/
Microsoft CAPI version :
http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/
Until now, I thought Chrome was using that code, but it uses in fact
three separate implementation of it's security and ssl code, for
Windows, Mac OS, Linux, based on the CAPI-schannel/ CSSM-Secure
Transport / NSS stack. As can be seen here :
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_win.cc
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_win.cc
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_nss.cc
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_nss.cc
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_mac.cc
http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_mac.cc
Eddy Nigg
>> Perhaps there is place for a fork of firefox (perhaps an "enterprise"
>> version) that uses the windows certificate store and dispenses with the
>> local certificate store. I understand that support for MSI installation
>> is already being worked on.
>
> I think it would make much, much more sense to use the OS store for
> private keys across all Firefox versions !
>
Yes, and with a compromise of the system you'd also loose those
installed at the Mozilla applications. Not nice :S
Wan-Teh Chang
>
> I think it would make much, much more sense to use the OS store for private
> keys across all Firefox versions !
>
> This is the strategy followed by Chrome.
>
> In fact, there is code to do that in NSS but I'm afraid it's currently not
> really maintained :
> Mac OS X version :
> http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/nssmkey/
> Microsoft CAPI version :
> http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/
Right. They may also be incomplete.
> Until now, I thought Chrome was using that code, but it uses in fact three
> separate implementation of it's security and ssl code, for Windows, Mac OS,
> Linux, based on the CAPI-schannel/ CSSM-Secure Transport / NSS stack. As can
> be seen here :
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_win.cc
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_win.cc
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_nss.cc
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_nss.cc
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/ssl_client_socket_mac.cc
> http://src.chromium.org/viewvc/chrome/branches/official/build_166.1/src/net/base/x509_certificate_mac.cc
Yes. Chrome uses NSS only on Linux, and it uses the system NSS
libraries. On Mac and Windows, Chrome uses the system crypto
and SSL libraries.
Wan-Teh
aero...@gmail.com
On Thu, Mar 4, 2010 at 6:42 AM, Eddy Nigg <eddy...@startcom.org> wrote:
>> Chris Hills wrote:
>>>
>>> Perhaps there is place for a fork of firefox (perhaps an "enterprise"
>>> version) that uses the windows certificate store and dispenses with the
>>> local certificate store. I understand that support for MSI installation
>>> is already being worked on.
>>
>> I think it would make much, much more sense to use the OS store for
>> private keys across all Firefox versions !
>>
>
> Yes, and with a compromise of the system you'd also loose those installed at
> the Mozilla applications. Not nice :S
Well, no, not nice -- but with the fact that even your CA system will only create a single certificate valid at a time per email address per identity class (and only a single developer certificate, period), this means that the user has to go through an arduous process to be able to do more than a single thing with the certificates you offer. (As you know, the more times a key is exposed to the world, the higher the chance of compromise.)
This basically means that your PKI design enforces the very "not nice"ness that you now bemoan.
-Kyle H
Eddy Nigg
But that's not really the same - the public shall be exposed and if
that's not good enough, the key probably shouldn't be used at all either.
I'm speaking about a system and key compromise of that specific crypto
store. It really hasn't much to do with exposure of the public key. But
- the best would be a hardware token anyway. :-)
Martin Paljak
> On 03/07/2010 11:23 AM, aero...@gmail.com:
>> On Thu, Mar 4, 2010 at 6:42 AM, Eddy Nigg <eddy...@startcom.org> wrote:
>>>
>>> Yes, and with a compromise of the system you'd also loose those installed at
>>> the Mozilla applications. Not nice :S
>>
>> Well, no, not nice -- but with the fact that even your CA system will only create a single certificate valid at a time per email address per identity class (and only a single developer certificate, period), this means that the user has to go through an arduous process to be able to do more than a single thing with the certificates you offer. (As you know, the more times a key is exposed to the world, the higher the chance of compromise.)
>
> But that's not really the same - the public shall be exposed and if that's not good enough, the key probably shouldn't be used at all either.
>
> I'm speaking about a system and key compromise of that specific crypto store. It really hasn't much to do with exposure of the public key. But - the best would be a hardware token anyway. :-)
Have I missed something?
The reason of "central certificate stores" for software keys is universality and API. Windows provides an API, Mac provides an API, Firefox implements only PKCS#11.
If you care about compromised keys you use hardware tokens (which both platform API-s provide access to), system compromise has (almost) nothing to do with the chosen software API.
The fact that platform APIs are not used (or the argument that they work poorly or something similar) is something Mozilla people should answer to.
--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495
Eddy Nigg
> The reason of "central certificate stores" for software keys is universality and API. Windows provides an API, Mac provides an API, Firefox implements only PKCS#11.
>
PKCS11 is a standard and I suspect that it's possible to interact with
those crypto stores through PKCS11. APIs may be invented and changed by
various software, which mostly don't follow any standard.
> The fact that platform APIs are not used (or the argument that they work poorly or something similar) is something Mozilla people should answer to.
>
Well, the arguments were usually exactly the point I made. Firefox (and
other applications) have their own crypto store, making it independent
from what happens at the system level. There are obviously pros and cons
for this approach.
Martin Paljak
> On 03/07/2010 04:01 PM, Martin Paljak:
>>
>> The reason of "central certificate stores" for software keys is
>> universality and API. Windows provides an API, Mac provides an API, Firefox
>> implements only PKCS#11.
>>
>
> PKCS11 is a standard and I suspect that it's possible to interact with those
> crypto stores through PKCS11. APIs may be invented and changed by various
> software, which mostly don't follow any standard.
Windows is also a (de facto) "standard" which you can't ignore. Same
goes for OS X. There's no point in discussing "standards" if you want
to produce an .exe that works with Windows Vista (and whatever
standard or non-standard glitches and quirks it has) or discuss
replace the GUI on Mac OS X for a "standard" GUI (X11?). Windows (and
whatever APIs it provides) is a standard (for applications that run on
windows), OSX with its APIs is a standard (for mac apps). Yes, there
is POSIX and whatnot, but that's mostly on the paper. For Fedora, NSS
is the "crypto standard", for others it is OpenSSL. Windows and Mac
are not like Linux.
Discussions (and implementations) which layer should be the topmost
(PKCS#11->CAPI or vice versa, CDSA->PKCS#11 or vice versa) have not
yet been usable or practical, to my knowledge. Conceptually it should
be possible, in real life matching the corner cases becomes difficult
if not possible. Last time I checked the PKCS#11 module that came with
OS X that should translate at least Tokend (smart card) drivers to
Firefox ... just crashed.
It is not about APIs, it is about "how it should be done" and what it
is you're trying to do. Why the file open dialog tends to come from
the OS platform?
>> The fact that platform APIs are not used (or the argument that they work
>> poorly or something similar) is something Mozilla people should answer to.
>>
>
> Well, the arguments were usually exactly the point I made. Firefox (and
> other applications) have their own crypto store, making it independent from
> what happens at the system level. There are obviously pros and cons for this
> approach.
One of the major cons: you need to multiply the I in PKI. The same way
Firefox makes you depend on the root CA selection done by somebody
else, it would be OK to make the user depend on the PKI interfaces
(and trust management) of the platform, if the platform provides one.
For me soft certs on both mac and windows, with firefox, feel like
split personality (all this importing-exporting for no obvious reason)