Summary: | www-client/seamonkey-1.1.14 - Cannot import a PKCS12 certificate | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rabbe Fogelholm <rabbe> |
Component: | New packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Rabbe Fogelholm
2008-12-31 18:20:51 UTC
In case you updated dev-libs/nspr or dev-libs/nss recently, try to re-emerge seamonkey or run revdep-rebuild. I had a similar problem with seamonkey after update of dev-libs/nspr where seamonkey refused to access https websites being unable to verify the certificates provided by such sites. I had those symptoms too. A revdep-rebuild caused seamonkey to be rebuilt. That led me up to the current state where my old certificates are lost and new ones cannot be added. Does certificate handling work for you? My versions of nss and nspr are: nss: 3.12.2_rc1 nspr: 4.7.3 Which I found a workaround, like this: Download the Seamonkey binary distribution for Linux from the Seamonkey website. Do some certificate operations. Then switch back to Gentoo-built-from-source Seamonkey. Everything works. The funny thing is that before installing binary Seamonkey I moved my ~/.mozilla directory to a backup location. The binary Seamonkey caused another ~/.mozilla directory to be created. Then, as soon as I restored my original ~/.mozilla the problems were gone--I could again see my old "lost" certificates. It seems as if this bug may be hard to reproduce. I would not know how to get back to a state where the bug can again be seen. Can it be the case that using Seamonkey certificate handling updates some other directory besides ~/.mozilla? I just discovered that I am again in a situation where certificate handling is broken. My machine has two installations of Seamonkey. There is www-client/seamonkey-1.1.14, built from source the Gentoo way. There is also Seamonkey 1.1.14 installed as binary from the official website. Both installations share some resources. For example, I see the same set of bookmarks regardless of which browser I start. However, the binary Seamonkey sees my certificates and I can do Internet bank transactions. The Gentoo-built Seamonkey tells me I have no certificates. When I open the bank URL I am told to download a certificate before proceeding. So, I have a system where I can do some digging for the cause of the fault. I won't do any upgrades or other changes for some time. If anyone can tell me where to look I'll be happy to help. I have done a Gentoo install from scratch on a different machine. I emerged seamonkey-1.1.16 and there are no problems with the certificate handling, at least not yet. The problem that I reported may be difficult to reproduce I guess. I still have the old machine around; if anyone has ideas on how to investigate it please write a comment here. It is always nicer to understand why there was a problem rather than to reinstall and hope for the best :-) Can you reproduce the problem with seamonkey-2? I'm afraid not. My Internet bank has switched from certificates to "BankID" (http://www.bankid.com/en/What-is-BankID/) with its own load of problems. Look here for awkward details: http://unix.se/BankID_Skandiabanken_Ubuntu_steg-f%F6r-steg-beskrivning So, instead of Seamonkey I now use kvm to start a virtualized Ubuntu, in which I run firefox, with "BankID" installed. Hmm, sounds quite... ehm... awkward to do for online banking... nevertheless I gonna mark this bug as NEEDINFO then. Maybe someone else can provide updated information which requires this bug to be reopened again. Awkward indeed .. I agree completely with the guy who wrote this, http://daniel.haxx.se/blog/2009/11/14/the-swedish-bankid-curse-and-debian |