GNOME Bugzilla – Bug 626066
“trust” properties on certificate authority reset at evolution startup or shutdown
Last modified: 2010-09-29 10:09:12 UTC
Hey, I'm reporting against eds because iirc NSS stuff is there but feel free to reassign to evolution in case I was wrong. I'm trying to add my own CA certificate to evolution, and I wanted to do it cleanly, so I moved .evolution/cert8.db and .evolution/key3.db which I had from the old times (and where my CA was correctly imported), run evolution and went to the certificates properties. There I imported my certificate under the “Authorities” tab, and checked the three “trust” checkboxes. Connecting to my imap server worked fine. Then, quiting evolution and re-running it, connection to my imap server failed, because of a “BAD Signature”. Going to the authorities certificates, I can see that my cert is there, but the three checkboxes are gone, somehow they are reset. If you need more info, please ask.
Any idea on this, it's rather important, since new evolution installs won't be able to use autorities whose certificates are not included in NSS.
Confirming, I see this too, with actual master of evolution and evolution-data-server and nss 3.12.4. Though I believe the nss shouldn't play a role here, it's rather the evolution forgot to save changes in the trust preferences for an authority.
Hmm, there doesn't seem to be any save or commit function for a certdb in nss, on the first look.
So, reverting all related between today and fix for the bug #585301 in eds and evo makes this work again. So some change in between broke this.
Hrm, I got out of idea here. I tried to not use NSS_InitWithMerge when the local secmod.db wouldn't exist, as I thought it's overwriting this on the merge process, but no luck, it behaves same wrong when using > status = NSS_InitReadWrite (nss_sql_configdir); Just for a record: nss_sql_configdir:'sql:/home/mcrha/.pki/nssdb' nss_configdir:'/home/mcrha/.local/share/evolution' and the call for sql init succeeded.
In each case, please indicate which version of NSS you have installed, and whether the 'shared system database' is enabled. There have been a lot of NSS bugs in this area.
(In reply to comment #6) > In each case, please indicate which version of NSS you have installed, and > whether the 'shared system database' is enabled. There have been a lot of NSS > bugs in this area. Please see comment #2. Tested also with nss 3.12.6-12, doesn't work either. Wouldn't it be better to not depend on an unfinished project in a stable version? I do understand this move in a development version, but with stable version of evolution? I know it's too late, I'm only wondering.
With evo HEAD, nss-3.12.6-12.fc13.x86_64, shared system db enabled (first line of /etc/pki/nssdb/pkcs11.txt is 'library=libnsssysinit.so'. My IMAP server has a cert signed by CAcert. I removed the CAcert CA from the system database, connected with Evo and it complained about the cert. I hit 'cancel', went into the preferences and imported the CAcert CAs. Reconnected and it was fine. Quit evolution, restarted it. It connected to the IMAP server happily, as it should. Went into the preferences and checked, and the CACert CAs both had all three boxes checked still. (Meanwhile, 'certutil -d sql:/home/dwmw2/.pki/nssdb -L' seems to show that there's no trust, but I think that's a certutil bug: CAcert Class 3 Root - Root CA ,, CA Cert Signing Authority - Root CA ,, )
I quit Evolution, turned the shared db *off*, and then when I restarted Evolution I found that the trust bits were cleared on the CAcert CAs, which matches what's described above. I removed the CAcert CAs and re-added them (in evo), and the same thing happened. Then I removed them again, and added them on the command line with certutil. Now they *do* show up with the trust bits set: (NULL) CT,C,C support@cacert.org CT,C,C ... and everything worked in Evolution. Then I removed them *again* and added them from Evolution again, and now they're *still* working correctly.
Did you check that there was no .evolution/{cert8,key3}.db ? It seems that evolution uses them first here, thought it might be config related: cat .pki/nssdb/pkcs11.txt library= name=NSS Internal PKCS #11 Module parameters=configdir='sql:/home/corsac/.pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='/home/corsac/.evolution' updateCertPrefix='' updateKeyPrefix='' updateid='/home/corsac/.evolution' updateTokenDescription='Evolution S/MIME' NSS=Flags=internal,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512] askpw=any timeout=30}) library=libnssckbi.so name=Mozilla Root Certs NSS=trustOrder=100
As far as I can tell, things are working fine as long as you use certutil (or firefox or nss-gui or anything else) to import and manage certificates. Please shout loudly if you believe that not to be the case. I'll look at the issues which our GUI certificate manager has with import (sometimes giving wrong trust), modification of trust (doing nothing), and deletion (doing nothing). And try to make sure it's fixed by Monday...
I think this is only happening when you have a password on your certificate store. It's not logging in to the slot correctly.
Created attachment 170084 [details] [review] log in to slot before initialising certificate GUI I think this should fix it.
I filed bug 629432 and bug 629433 for other, probably unrelated bugs in the certificate manager GUI. Note that the latter may cause confusion here.
To ssh://dwmw2@git.gnome.org/git/evolution 86e9076..96f4d86 gnome-2-30 -> gnome-2-30 a6e9aca..fab32c9 master -> master
OK, it "fixed" the issue for me, but in a very horrible way. The first time I open Edit->Preferences, then instead of preferences window I'm asked for my password for the certificate store. When I provide it it works, but when I do not, then it doesn't work (it ~~ changing trust model on an authority certificate). Though what I hate on this is a fact that I'm going to deal with my account preferences, not with my certificates, thus the password question is quite annoying and useless for most of the times.
Created attachment 170159 [details] [review] login on demand Here's an alternative -- we find the places which may fail with SEC_ERROR_TOKEN_NOT_LOGGED_IN and we individually patch them to attempt to login and then retry the operation (except for import, which only needs to set the trust bits; retrying the import will fail because the certificate *does* get imported the first time; ick). I don't know if this has yet caught *all* of the cases we'd need to catch; that and the horridness on import are why I went for the simple approach in my original patch.
Created attachment 170161 [details] [review] updated patch New patch: if the CERT_AddTempCertToPerm() call fails, we can't just call it again -- the cert *has* been added, just with the wrong permissions. To recover we need to call CERT_ChangeCertTrust() instead. Ewww.
https://bugzilla.mozilla.org/show_bug.cgi?id=595861
http://david.woodhou.se/login-on-demand-2.30.patch http://david.woodhou.se/login-on-demand-2.32.patch
To ssh://dwmw2@git.gnome.org/git/evolution 11cebc8..12415fd gnome-2-30 -> gnome-2-30 6ed1e54..c33a84d gnome-2-32 -> gnome-2-32 515ad2e..75d1c75 master -> master I still think the fact that we have to call CERT_ChangeCertTrust() after a failed call to CERT_AddTempCertToPerm() is an NSS bug -- it ought to fail *completely* and we ought to have to call CERT_AddTempCertToPerm() again, surely. Once NSS is fixed, we may have to try both -- after authenticating, if CERT_ChangeCertTrust() fails then try CERT_AddTempCertToPerm() again, or something like that?
See https://bugzilla.mozilla.org/show_bug.cgi?id=595861#c4 -- I think we may want to do something like that so we cope with future, fixed versions of NSS. Would like confirmation from Nelson (or someone else clueful about NSS) before we do it though.
My suggested workaround has now been confirmed as the sane approach, so I've commited it: To ssh://dwmw2@git.gnome.org/git/evolution c7f5d54..47d2599 master -> master How do I get permission to push the same change to 2.32?
(In reply to comment #23) > How do I get permission to push the same change to 2.32? Only after hard code freeze, which ends when 2.32.0 is released. Or you can ask release team for an approval and commit earlier, if they allow. What is the status of that updated patch in attachments, isn't it committed?
The cleaned-up version of the patch in comment 18 has been committed (looks like what's in comment 20), which went into 2.32 before the code freeze. So what's in 2.32 is working with all current versions of NSS but if they *fix* the bug I've reported, then it might stop working. Hence the incremental patch in 47d2599 that I'd like to commit to 2.32 too.
Created attachment 170486 [details] [review] outstanding patch for 2.32
Review of attachment 170486 [details] [review]: .
Created commit 58a1d6a in evo gnome-2-32 (2.32.1+)