Firefox does not display imported certificate
Andrei Korostelev
certutil.exe utility or programatically using NSS API
(P12U_ImportPKCS12Object / PK11_ImportCert), I can see that the
certificate has been successfully imported (%certutils.exe -L) ,
however Firefox does not display it (Tools->Options->Advanced->View
Certificates) until I restart the browser.
I am wondering is it a way to instruct the already running Firefox to
reload its security database (containing certs) without restarting it
(e.g. this happens when I import cert. from Firefox UI)?
Andrei Korostelev
Here is what I've realized so far (special thanks to Subrata Mazumda
and Robert Relyea).
1. Currently (Firefox <= 2.x) the Mozilla Security Db supports
multiple readers and a single writer only hence it is not safe to
write to the Db while the Firefox is running. The situation is
promised to be improved in future versions of Firefox: the shared Db
has been just checked in to the Firefox 3 trunk. Thus, closing Firefox
is the only solution to safely write to its security Db from the
external process for Firefox <= 2.x.
2. Because the Security Db can be safely accessed from Firefox as the
only writer, a safe solution would be in implementing our certificate
managing logic as a Firefox extension (JavaScript), as XPCOM object (C+
+) or both (XPCOM object called from the extension). As an example one
can have a look at this extension https://addons.mozilla.org/en-US/firefox/addon/4471,
which extends the Firefox certificate management capability with the
key management. Mozilla provides NSS (Network Security Services) API
to develop security-enabled client and server applications. There are
several possibilities we can use NSS for managing certificate database
from Firefox:
- Use NSS API directly. NSS is a rather low-grained API written on C.
Because it is fine-grained, you need quite some effort to bring these
functions together to implement a business logic you need. To make
sure you are on the right track, you can have a look at the source
code of the certutil command-line tool. Java developers can use JSS
API built on top of NSS (http://www.mozilla.org/projects/security/pki/
jss/).
- Manage certificate Db through nsIX509CertDB XPCOM interface (http://
www.xulplanet.com/references/xpcomref/ifaces/nsIX509CertDB.html). The
first advantage of using XPCOM interface is that, besides the ability
to call it from your C++ XPCOM object, you can directly call methods
of XPCOM interfaces from the extension using JavaScript. Another
advantage is a pretty coarse-grained interface which simplifies its
usage (nsIX509CertDB interface is clearly implemented using NSS API).
The major downside of XPCOM approach is that it requires user
intervention: for some reason you cannot pass the certificate trust as
an argument for the certificate import methods (see e.g.
nsIX509CertDB::ImportCertsFromFile) so the user will be presented with
a pop-up dialog where he'll have to tick appropriate check-boxes; the
same story is with the password for the imported PKCS#12 package
(nsIX509CertDB::ImportPKCS12File) which the user can simply not be
aware of. Finally, annoying message boxes indicating the method
success status bring me to a conclusion that this interface was
intended for GUI-enabled XUL components.
-- Andrei
Nelson Bolyard
> Here is what I've realized so far (special thanks to Subrata Mazumda
> and Robert Relyea).
>
> 1. Currently (Firefox <= 2.x) the Mozilla Security Db supports
> multiple readers and a single writer only hence it is not safe to
> write to the Db while the Firefox is running.
Actually it's worse than that. The DB presently used in mozilla for
cert and key DBs supports these combinations, only:
a) multiple simultaneous readers and NO simultaneous writers, or
b) one writer with NO other simultaneous readers or writers.
> The situation is
> promised to be improved in future versions of Firefox: the shared Db
> has been just checked in to the Firefox 3 trunk. Thus, closing Firefox
> is the only solution to safely write to its security Db from the
> external process for Firefox <= 2.x.
FireFox is always a writer. So, there must be NO other processes that
open the DB AT ALL while FireFox has it open.
I agree with the rest of what you wrote, down to here:
> The major downside of XPCOM approach is that it requires user
> intervention: for some reason you cannot pass the certificate trust as
> an argument for the certificate import methods (see e.g.
> nsIX509CertDB::ImportCertsFromFile) so the user will be presented with
> a pop-up dialog where he'll have to tick appropriate check-boxes;
Yes. Does that surprise you? It shouldn't.
Should web pages be able to alter the user's set of trusted CAs without
his knowledge?
If they could, what would stop a "bad guy" from installing his own
evil root CA certs as trusted in the user's browser, then then thereafter
successfully attacking the user's otherwise "secure" pages?
With a bogus root CA installed and trusted, an attacker could successfully
MITM attack any server he chose. Imagine a rogue employee as your ISP
doing that. The user's ability to control what certs he trusts is his
PRIMARY DEFENSE against MITM attackers. If we take away that control
from the user, and give it to the web site designer, FireFox users
would have no reason remaining to trust anything they see in their
browser windows, ever again. That's why we require user participation
in matters affecting their security.
Andrei Korostelev
wrote:
> I agree with the rest of what you wrote, down to here:
>
> > The major downside of XPCOM approach is that it requires user
> > intervention: for some reason you cannot pass the certificate trust as
> > an argument for the certificate import methods (see e.g.
> > nsIX509CertDB::ImportCertsFromFile) so the user will be presented with
> > a pop-up dialog where he'll have to tick appropriate check-boxes;
>
> Yes. Does that surprise you? It shouldn't.
>
> Should web pages be able to alter the user's set of trusted CAs without
> his knowledge?
>
> If they could, what would stop a "bad guy" from installing his own
> evil root CA certs as trusted in the user's browser, then then thereafter
> successfully attacking the user's otherwise "secure" pages?
>
> With a bogus root CA installed and trusted, an attacker could successfully
> MITM attack any server he chose. Imagine a rogue employee as your ISP
> doing that. The user's ability to control what certs he trusts is his
> PRIMARY DEFENSE against MITM attackers. If we take away that control
> from the user, and give it to the web site designer, FireFox users
> would have no reason remaining to trust anything they see in their
> browser windows, ever again. That's why we require user participation
> in matters affecting their security.
You are right that importing *root* CA is actually a process of
establishing trust between the user the the cert. issuer. Thus, user
should explicitly (dis)approve this. However installing *non-root*
stuff, or specifying password for pfx are the tasks that can be
performed without user. And this is exactly what I am grumbling about.