The procedure for adding new certificate authorities (cacert.org, or other company-private CAs) doesn't seem to be documented... or simple. Are we expected simply to append to /etc/pki/tls/certs/ca-bundle.crt?
Will that take effect in Firefox too?
Ubuntu apparently has an 'update-ca-certificates' script which does something like this; do we?
If you just append to the /etc/pki/tls/certs/ca-bundle.crt it will affect just some OpenSSL based applications. It will not modify the CA cert list in Firefox (NSS based).
I agree that there should be some easy-to-use command line and GUI tool that would configure the CA certs for most/all of the possible applications. The problem is though that you probably want different CA cert lists for the various applications - one CA cert list for casual web browsing, one CA cert list for security critical web browsing (for example internet banking), one CA cert list for verification of LDAP server that provides account information for the machine and so on.
So correctly setting up PKI on a computer is not an easy task.
*** Bug 488537 has been marked as a duplicate of this bug. ***
Agree with Tomas' comments. At a simplest level I would imagine a root CA database would be a trust database associating :
service -> list-of-trusted-actions -> list-of-CAs
service is e.g. "web browsing", "mail server", "web server"
trusted-actions are, e.g. "code signing", "e-mail signing", "server authentication", the NSS trust database has an appropriate set of bits here.
The current NSS database model doesn't seem appropriate for this, lacking the ability to differentiate per service. There's no file format for storing such trust bits for OpenSSL/GnuTLS, AFAIK.
And this doesn't get into anything more complicated such as specifying revocation preferences (CRL, OCSP, etc).
That consideration certainly shouldn't block us from implementing _basic_ support for stuff like 'Add CAcert.org' or 'Add my company's internal CA chain', where we _don't_ want it to be conditional. The latter is quite important for acceptance within certain corporate environments.
It would be good to start with getting that working.
The question of 'which CAs do we trust' is a per-user, per-application thing -- sometimes it even depends on what the application is doing at the time (you might accept an untrusted certificate from your mail server when you use CRAM-MD5 authentication, but demand a trusted one for LOGIN where you give the password in plain-text).
I don't think it makes _any_ sense to try to handle that complexity in the central store -- the ca-certificates package should provide the central database of known CAs without trying to address that question.
A CA being 'known' shouldn't necessarily imply that it should be trusted for all purposes, although most applications would probably default to doing that.
The security-conscious applications can happily have their own ways of remembering which CAs they want to trust and which they don't, for various purposes.
I don't think that should hold up the implementation of a central store which works with openssl/nss/gnutls though.
I've been looking at how Debian handle this and I think it'd be fine to do something similar or maybe a bit simpler. I'd propose this:
1) split out the Mozilla CA root into one PEM file per CA, with filenames derived from the cert Subject. Dump these PEM files in /usr/share/ca-certificates, or somewhere similar in /usr (i.e. treating them as user-unmutable content)
2) introduce a new directory, /etc/pki/tls/ca-certificates.d/ into which users can place their own CA root certs.
3) have a script which produces ca-bundle.crt at the current location, as the union of the contents of those two directories, matching *.crt.
4) have that script obey a config file /etc/pki/tls/ca-certificates.conf or similar, which contains simply a list of files to *exclude* from the default root CA bundle.
e.g. presume the filename of one of the split-out Mozilla CA roots is
you could then put "Verisign_Class_1_Public_Primary_Certification_Authority" in the .conf file, and the aggregrator-script would exclude that cert from ca-bundle.crt
5) that script is run on %post of ca-certificates and can be run manually by users after modifying the config
6) that script could also build up a directory with the c_rehash-style symlinks for programs which can use that.
The script wants to build the NSS db in /etc/pki/nssdb, and the Java one in /etc/pki/java/cacerts too, right? The ca-certificates.conf file can specify which 'privileges' to grant, in the NSS db?
We'll also want to file bugs against NSS-using programs which don't use /etc/pki/nssdb -- such as firefox, evolution... in fact is there anything which _does_ use the database in /etc/pki/nssdb?
The plan is good. Here are just some thoughts.
As some sites would prefer to exclude all the root certs except some explicitely specified ones, it would be good idea to have some way of specifying a wildcards (either regexp or shell) in the ca-certificates.conf file. Also the file should be named differently if it is a list of excludes - perhaps ca-cert-exclude.conf or something similar.
Also would be inclusion of the certs from /etc/pki/tls/ca-certificates.d/ affected by the exclude config file?
As for 6) - perhaps the ca-bundle.crt should be declared as deprecated and the applications should be encouraged to use this hashed directory?
(In reply to comment #7)
> As for 6) - perhaps the ca-bundle.crt should be declared as deprecated and the
> applications should be encouraged to use this hashed directory?
We can do that fairly easily by changing openssl.cnf, can't we?
But I don't see how it helps. The hashed directory has a fundamentally flawed design which means it _also_ has to be recreated by the same kind of script that generates the ca-bundle.crt file.
The problem is that the filenames have to have the form $HASH.$NUM, and the $NUM part must be sequential starting from zero. If you have abcdabcd.0 and abcdabcd.2, then the second one won't be found.
So you can't just drop files in place called abcdabcd.$RANDOMNUM and expect them to be found... which means the whole scheme still needs a post-processing step.
Yes, the design of the hashed dir is much less than ideal. However I thought it could at least improve the load time of applications - the ca-bundle.crt is getting pretty large nowadays.
Yeah, that would probably make sense.
Firefox bug filed as bug #546221
I think David's comment #6 is good. It fits in with getting nss apps into system nss. Managing certs in the DB is relatively simple using certutil.
RE: Tomas Mraz comments. NSS database also have the notion of 'excluded certs'. That is we can make /etc/pki/nssdb exclude root certs that could not be overridden (depending on the way the administrator configures the system). Of course I expect that we would still want user to override root trust locally (that is for the user, but not for other users on the system).
(In reply to comment #9)
> Yes, the design of the hashed dir is much less than ideal. However I thought it
> could at least improve the load time of applications - the ca-bundle.crt is
> getting pretty large nowadays.
I can never explain to people how to really use the hashed-dir approach. Most normal users wont' do it.
So as a user, how would I select the CA certificate I'd like to use from the UI using this scheme?
Ideally it would be a self-contained GtkWidget subclass that I could simply include in my GTK-based application. Unfortunately for programs like wpa_supplicant, vpnc, and openvpn that don't support NSS yet, we can't simply use NSS for everything (though I'd love to).
So I guess then I'd need to write a widget that would read all the certs in /etc/pki/tls/ca-certificates.d and /usr/share/ca-certificates and show them to the user, and allow the user to pick one. Unfortunately wpa_supplicant, vpnc, openvpn, etc only allow one CA certificate file, though that file can often be a CA cert bundle with multiple PEM certs inside.
Or is there a better way?
(In reply to comment #14)
> So as a user, how would I select the CA certificate I'd like to use from the UI
> using this scheme?
Just to check: We're talking about certificates, _not_ private keys.
I believe that the cacert bundle you provide to wpa_supplicant/vpnc/openvpn/etc. has always worked in _addition_ to the known root CAs which are in the default ca-bundle.crt.
This bug is about providing a way to manage the contents of that system-wide ca-bundle.crt (and the equivalent in NSS; cf. bug #546221).
So part of the answer to your question is that the user won't _have_ to select a CA bundle from the UI. It'll be installed _properly_ system-wide, and stuff will JustWork™.
However, if you _do_ want to add extra certs that for some reason you don't want to install system-wide, you can still do that too. And the situation hasn't changed at all.
(In reply to comment #15)
> (In reply to comment #14)
> > So as a user, how would I select the CA certificate I'd like to use from the UI
> > using this scheme?
> Just to check: We're talking about certificates, _not_ private keys.
I'm talking about either one. Often you'll get from your network admin (or a web page) your (a) CA cert, (b) client cert, and (c) private key. You now have 2 or 3 files. What do you do with them? You do need to tell wpa_supplicant to use them /all/. So you need to select them. While this specific bug is talking about CA certificates, the I-want-ponies future is a certificate store that does handle /all/ of these items.
> I believe that the cacert bundle you provide to
> wpa_supplicant/vpnc/openvpn/etc. has always worked in _addition_ to the known
> root CAs which are in the default ca-bundle.crt.
Not necessarily. It depends on whether the service calls the default verify directory call, which may or may not be the correct thing to do depending on whether or not you want to use the system CA certs to auth your network.
> This bug is about providing a way to manage the contents of that system-wide
> ca-bundle.crt (and the equivalent in NSS; cf. bug #546221).
Ideally this solution would also incorporate a certificate store, but that is likely out-of-scope for the simple solution you are proposing, which is fine.
> So part of the answer to your question is that the user won't _have_ to select
> a CA bundle from the UI. It'll be installed _properly_ system-wide, and stuff
> will JustWork™.
Only if the user elects to use the default certificate store, yes. If they are given a certificate by their network admin then we need to either add that certificate to the system store for them (via nm-applet) or else continue as normal.
(In reply to comment #16)
> Ideally this solution would also incorporate a certificate store, but that is
> likely out-of-scope for the simple solution you are proposing, which is fine.
We're moving in that direction. But yes, it's out of scope for this particular bug.
We do want to get to the point where everything is using NSS (or at least the NSS database -- an OpenSSL engine for that shouldn't be hard). And every NSS-using application is using the proper system store (which adds /etc/pki/nssdb readonly and ~/.pki/nssdb in read-write mode).
Then we'll take a closer look at what things like wpa_supplicant are going to need, when connecting to a network with keys that the user owns. As discussed on IRC, we have the choice of letting them read the database files directly (with home_cert_t selinux context), or doing some kind of proxying and letting it actually get handled by a process which runs in the user's session.
Just some more brain-dumping.
OpenSSL does in fact have a way to store trust bits along with a certificate; the X509_AUX structure, serialized using the tag "TRUSTED CERTIFICATE" in PEM files.
The trust bits OpenSSL recognizes are:
TSA server (TSA = some kind of timestamping protocol)
these can be mapped from the trust bits from certdata.txt; I've hacked up the python script to test that out and it works fine.
GnuTLS doesn't read this TRUSTED CERTIFICATE PEM format, however. What we could do is generate:
a) ca-bundle.crt in current location using normal PEM format readable by GnuTLS
b) the hashed directory using certs in TRUSTED CERTIFICATE format
and configure OpenSSL to use only (b) as the default location used by
X509_STORE_set_default_paths/SSL_CTX_set_default_verify_paths. (I think that's possible)
This would mean we could possibly still include the CA roots which are *only* trusted for code signing or only for e-mail signing and have them usable by OpenSSL. I'm not sure whether the OpenSSL cert verification code/apps which use it actually do this "purpose" checking by default though; it looks like it's something which needs to be done explicitly by the app.
I wrote this:
It's only for NSS, not for openssl. It may be a bit ugly and minimal, but hopefully it does its job.
It's based on xulrunner, reusing the certificate management code we have in Firefox.
But in order to make it work and access the correct database path, we must apply the patch from bug https://bugzilla.mozilla.org/show_bug.cgi?id=462919
(I should have checked in this patch long ago, but it's a small patch, we could easily apply this patch to our Fedora xulrunner package.)
By default it operates on a NSS database in path ~/.nssdb/
but a command line argument to the nss-gui binary can be used to specify any path.
Together with sudo this could also be used to manage /etc/pki/nssdb
Does this help?
Java (IcedTea, OpenJDK) should be able to use /etc/pki/tls/certs/ca-bundle.crt directly, at least that's how I read http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=39 .
Oops, should have checked things more carefully. The patches to use the cert bundle directly were dropped later (see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=150#5 ) so Java uses /etc/pki/java/cacerts (from the "ca-certificates" package.
(In reply to comment #19)
> I wrote this:
I've been able to land the mandatory base patch into Mozilla, it will be contained in xulrunner-188.8.131.52 and xulrunner-184.108.40.206, which are scheduled for around March 30.
I'd be interested in your feedback related to comment 19. I wonder if I should create a fedorahosted or sourceforge project to host it.
Meanwhile Firefox 3.6.2 and the associated Xulrunner have landed in Fedora 12 and later, this means, the feature required for nss-gui is now available.
Would you like to try the tool that I described in comment 19?
rpmbuild --rebuild nss-gui-0.3.0-1.fc12.src.rpm
and install the resulting binary package,
nss-gui --dbdir /path/to/your/nss-db
I'm looking for feedback, thanks in advance!
I must be doing something wrong, because the app doesn't show up if I specify --dbdir:
% sudo strace -eexecve -s100 nss-gui --dbdir /etc/pki/nssdb
execve("/usr/bin/nss-gui", ["nss-gui", "--dbdir", "/etc/pki/nssdb"], [/* 19 vars */]) = 0
execve("/usr/bin/xulrunner", ["xulrunner", "/usr/share/nss-gui/xrnssgui.ini", "", "\1", 0x3, "PS@"], [/* 20 vars */]) = -1 EFAULT (Bad address)
Thanks for testing, I can reproduce your problem on a x86_64 machine.
- nss-gui refused to run with the newer 1.9.2.* core. Fixed.
- I had used execlp which suppresses the error output from
the ececuted process.
I've switched to calling "system",
in the future failures should be easier to find.
Could you please try the new
Thanks in advance
thanks for creating this utility. I tested it briefly and in general it works nicely but I did notice few small issues:
- when starting without parameters it tries to open("~/.nssdb") which fails - using --dbdir /home/user/.nssdb works ok
- when selecting a certificate provider (not a certificate) in Certificate Manager buttons like Delete are not grayed out but they do not work - it would be probably useful to allow deleting all cerficates of a provider by deleting the selected provider? (one actually sees an exception in Error Console when trying to do this)
- the Delete button does not actually work, when restarting nss-gui the previously deleted certificates are still present
- when starting nss-gui the nssdb path is shown in a box which looks a bit like it could be edited but it's read-only - would it be possible to make the path editable in the gui?
Hi Marko, thanks a lot for testing and your feedback. Replies are below.
(In reply to comment #28)
> - when starting without parameters it tries to open("~/.nssdb") which fails -
> using --dbdir /home/user/.nssdb works ok
Ok, I can update it to use a better path by default.
I can evaluate $HOME. I saw that nss-sysinit defaults to sql:$HOME/.pki/nssdb
so I probably should change nss-gui to the use same path.
I wonder, should the default be different for the root user?
I mean, if we have root permissions, should we use sql:/etc/pki/nssdb ?
(Another option is to always use sql:/etc/pki/nssdb
but this will be incorrect if a system has disabled nss-sysinit )
> - when selecting a certificate provider (not a certificate) in Certificate
> Manager buttons like Delete are not grayed out but they do not work - it would
> be probably useful to allow deleting all cerficates of a provider by deleting
> the selected provider? (one actually sees an exception in Error Console when
> trying to do this)
The contents and behaviour of the GUI are identical with the certificate manager found in Firefox and Thunderbird, and we have the same behaviour there.
I agree the usability of this dialog could be enhanced.
This particular issue is already being tracked upstream at
> - the Delete button does not actually work, when restarting nss-gui the
> previously deleted certificates are still present
Yes, another unfortunate usability issue, also present in upstream Firefox cert manager.
Roots that are stored in the builtin code module can't be deleted, they only can have their trust removed. It's unfortunate that we offer to delete from the list, and many people have already complained about this detail.
The issue is tracked at
I recently made a proposal to improve it by changing the wording (change delete to "delete or distrust" and change edit to "edit trust".
> - when starting nss-gui the nssdb path is shown in a box which looks a bit like
> it could be edited but it's read-only - would it be possible to make the path
> editable in the gui?
If you think the box looks confusing, should we simply change it to a "label" (text without box).
Changing the path will require a restart of nss-gui.
If you ask for "editable", you'd probably ask for a "browse for directory" next, and an automatic restart.
I wonder if this feature is necessary, as most people will worry about a single database, only.
w.r.t. nss-gui. This seems to be a few steps ahead of the problem at hand here.
Are we even any closer to having all NSS-based apps use /etc/pki/nssdb as the authoritative system-wide root CA db? My reading of bug 546221 etc says "no"?
thanks for providing the links to those upstream bug reports.
> I wonder, should the default be different for the root user?
> I mean, if we have root permissions, should we use sql:/etc/pki/nssdb ?
I think this would make sense and be better default for the root user then /root/.nssdb.
> If you think the box looks confusing, should we simply change it to a "label"
> (text without box).
That would probably make it more obvious that it's a read-only value.
> I wonder if this feature is necessary, as most people will worry about a single
> database, only.
Yep, most likely such a feature is not really needed.
(In reply to comment #30)
> Are we even any closer to having all NSS-based apps use /etc/pki/nssdb as the
> authoritative system-wide root CA db? My reading of bug 546221 etc says "no"?
Indeed. NSS is still fairly broken if you enable the system store, so it's unfortunately a little premature to be switching the apps.
I've uploaded a new version 0.3.2 at:
- changed wording in main window
- removed the box around NSS directory information
- will filter the "sql:" from the displayed path,
as this technical access method might confuse users
(certificates use sql, what?)
- fix the default database directory,
when running as an ordinary user its: sql:$HOME/.pki/nssdb/
when running with root permissions its: sql:/etc/pki/nssdb/
I tested the new version 0.3.2 and otherwise it looks good but it seems that it doesn't work without the --dbdir option. By looking at the strace output below one sees quite a difference:
user@localhost:~> rm -rf .nssgui .nssdb
user@localhost:~> cp -a /etc/pki/nssdb .nssdb
user@localhost:~> strace -f -eopen nss-gui --dbdir /home/user/.nssdb 2>&1 | grep nssdb
[pid 4997] open("/usr/lib/libnssdbm3.so", O_RDONLY) = 31
[pid 4997] open("/home/user/.nssdb/secmod.db", O_RDONLY) = 31
[pid 4997] open("/home/user/.nssdb/cert8.db", O_RDWR) = 31
[pid 4997] open("/home/user/.nssdb/key3.db", O_RDWR) = 32
[pid 4997] open("/home/user/.nssdb/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory)
user@localhost:~> strace -f -eopen nss-gui 2>&1 | grep nssdb
[pid 5021] open("/home/user/.pki/nssdb//pkcs11.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5021] open("/home/user/.pki/nssdb//pkcs11.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5021] open("/home/user/.pki/nssdb//pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = -1 ENOENT (No such file or directory)
[pid 5021] open("/home/user/.pki/nssdb//cert9.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 ENOENT (No such file or directory)
[pid 5021] open("/home/user/.pki/nssdb//cert9.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 5021] open("/home/user/.pki/nssdb//pkcs11.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
(In reply to comment #34)
> user@localhost:~> rm -rf .nssgui .nssdb
> user@localhost:~> cp -a /etc/pki/nssdb .nssdb
I believe you complain that different directories are being used in your examples.
You're copying to the wrong directory.
I have changed the default directory in nss-gui-0.3.2, when I learned about nss-sysinit.rpm's behaviour (as said above).
The new default directory is
I think you want:
cp -a /etc/pki/nssdb .pki/
which will copy everything to
This is the default directory also used by the tricky libnsssysinit.so module, which is used if you instruct an application to access NSS at sql:/etc/pki/nssdb
yep, I indeed missed the updated default - using ~/.pki/nssdb makes it work ok.
Created attachment 423619 [details]
use system db for non-root where appropriate
It's wrong to use ~/.pki/nssdb for the user when the 'shared system database' is enabled. This patch checks the status of libnsssysinit, and uses the system database where appropriate.
(In reply to comment #32)
> (In reply to comment #30)
> > Are we even any closer to having all NSS-based apps use /etc/pki/nssdb as the
> > authoritative system-wide root CA db? My reading of bug 546221 etc says "no"?
> Indeed. NSS is still fairly broken if you enable the system store, so it's
> unfortunately a little premature to be switching the apps.
I think this is no longer true. We have patches which make everything work. I'm now running a F-13 system with patched NSS and xulrunner, and with evolution patches which are already committed to the 2.30 branch. The system database is working.
I think we ought to be in a position to get this done as a feature for F-14.
Comment 3 in this bug points out some of the 'server' side functions that 'matter'. Do the existing applications one uses -- sendmail for MTA, apache for webserver, dovecot for pop/imap server -- have doco written to enable such a cutover? migration tools? testing?
-- Russ herrold
Russ, I think you misunderstood that list. Joe was asking the question "how do we tell which services we trust each CA to authenticate".
We don't actually need to modify the SSL-enabled server applications; they only care about their _one_ private key and corresponding certificate, and they aren't getting it from an NSS database at the moment anyway -- it's generally in PKCS#12 or more likely PEM files in the file system.
This mostly affects _client_ applications, which need to validate a certificate which is presented by some remote server that they connect to. I'm sure there will be more client apps which need patching just like firefox and evolution, but it _is_ all basically working, and it's reasonable to set about patching them now.
dunno -- all I know is what I read:
> service is e.g. "web browsing", "mail server", "web server"
one is the client side; the other the server side, in that list's enumeration
-- Russ herrold
> I think we ought to be in a position to get this done as a feature for F-14.
Possibly in F-13 as well. Once we verify things are working as we want them to in
Fedora we should not delay submitting patches upstream. Also, I'm currently working on making the PEM module take advantage of nss-sysinit so that should provide more testing.
Russ, can you explain exactly what would need to be changed in sendmail/exim/dovecot/cyrus-imap/apache/tinyhttpd? Don't go overboard -- just outline what you think there is that needs to be changed in _one_ of them.
(In reply to comment #42)
> > I think we ought to be in a position to get this done as a feature for F-14.
> Possibly in F-13 as well.
Works for me.
> Once we verify things are working as we want them to in
> Fedora we should not delay submitting patches upstream.
The evo patch is already committed and will be in the 2.30.2 release next week.
The xulrunner patch is attached to Kai's upstream mozilla bug:
The NSS patch (from bug 603313) isn't yet filed upstream -- I was hoping for someone with a bit more NSS-clue to look at it first.
sendmail, as to the text based certificate files
1. make the needed directories -- I use:
mkdir -p /etc/mail/certs
I also then retreive and place the certificate bundle for the CA I will be using
under the name: rollup.pem
2. generate the keyfile -- I use:
openssl genrsa -des3 -out mail.acme.com-YY.key 2048
where YY is the last two digits of the year
which has a user interaction to provide the passphrase
3. one time task -- update the details of the entity
4. generate a signing request to be send to the oversigning CA
openssl req -new -sha1 -key mail.acme.com-YY.key -out mail.acme.com.csr
from memory there is a user interaction to provide the passphrase, but I may be misremembering; certainly the hostname is manually provided as it is not unchanging and thus eligible for openssl.cnf
[CA returns notice that a properly contersigned PEM may be retrieved]
5. harvest that content into a file -- I use the form:
6. amend sendmail.mc
a. force the banners hostname to a match
b. use the certs
c. a make will rebuild sendmail.mc into sendmail.cf
7. attend to perms
the key needs to be no more than 600 (possibly 700)
the pem can be 644
8. off machine backups now
10. How to thread the passphrase needle [actually a MTA passphrase is in less need of a passphrase in many use cases than a web server, which is why I chose this example]
I have NO IDEA how to do this with NSS only; that is why I ask how this is 'ready'
-- Russ herrold
Russ, you're talking about the server's private key, and it's been explicitly stated that we're _not_ currently talking about using the central database for private keys. See also the second paragraph of comment 40, only a short time ago.
Created a python script to handle indexing, please review and comment on "update-ca-certificates"
I don't think Sascha's tool provides all the pie-in-the-sky features we've contemplated, but it's a good start. I think we should go ahead with it, and we can improve it incrementally.
Joe, Tomas, Bob, Elio, Kai, etc.... please shout if you object to me approving Sascha's package (in bug 620752) on that basis.
It is definitely better than nothing so I have no objections.
If you are going to use a tool called update-ca-certificates please have a look at http://gitorious.org/opensuse/ca-certificates/trees/master. We use that one on openSUSE 11.3. It works similar to Debian's version so it should be familiar to people coming from there at least.
However, Joe has plans for an even more elaborate tool.
Ludwig, thanks. I really would like to avoid reinventing the wheel if possible -- if we can do things the same way that openSuSE does, that would be nice.
Do you have any plans in openSuSE to enable the shared system NSS database?
(In reply to comment #51)
> Ludwig, thanks. I really would like to avoid reinventing the wheel if possible
Me too. I consider update-ca-certificates a temporary solution until Joe's tool is ready for the public though.
> Do you have any plans in openSuSE to enable the shared system NSS database?
I think our nss maintainer wants to do that at some point in the future, yes. The nss script in the aforementioned git repo is just a PoC hack btw. It's not actually used on the distro. It would need to be rewritten in C for production use I guess.
(In reply to comment #37)
> It's wrong to use ~/.pki/nssdb for the user when the 'shared system database'
> is enabled. This patch checks the status of libnsssysinit, and uses the system
> database where appropriate.
David, thank you very much.
I merged your patch:
nss-gui is now available as a package in Fedora 14 (and later) and EPEL 6.
See https://fedoraproject.org/wiki/Features/SharedSystemCertificates for plans for Fedora 19.
Making this a tracker bug for the Fedora 19 feature.
In order to replace these files:
with an automatically managed copy we need to be able to replace it with a symlink. Since these files are marked as %config files in RPM, if they are modified by a customer, then we should have the new symlink go to a .rpmnew file.
Bug #445202 blocks this one because symlinks that replace %config(noreplace) do not trigger the usual .rpmnew behavior.
I don't know how to distinguish during the RPM package scripts between
"config file is untouched original"
"config file is modified"
Bug 445202 hasn't seen progress in years, but we need a solution with the next couple of days.
Therefore I consider the following pragmatic approach:
- during package installation of the new ca-certificates.rpm
which uses the new symbolic links,
let's use a %pre script
- during the %pre script, we move the existing files to .rpmsave files
- we move only once. if during %pre script, we find that there already
are .rpmsave files, we don't move again
(this is for the edge case scenario where people upgrade and downgrade
This way, we force people to adjust their old system to our new system, if they want to continue to use override certs, because we no longer support the old way.
By keeping the .rpmsave, users don't lose data.
This work has completed for Fedora 19. Further work will be tracked by other bugs.