Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
On Fri, Jan 01, 2010 at 01:28:47PM +, Sam Morris wrote: Package: libnss3-1d Version: 3.12.5-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since upgrading libnss3-1d to 3.12.5, I have been unable to connect to my company's email server. Evolution gives me this dialog: SSL Certificate check for imap.example.com: Issuer:serialNumber=,CN=Go Daddy Secure Certification Authority,OU=http://certificates.godaddy.com/repository,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US Subject: CN=*.example.com,OU=Domain Control Validated,O=*.example.com Fingerprint: ec:cf:43:7f:87:84:f0:63:ec:b4:5d:60:e5:7e:6b:23 Signature: BAD No problem with iceweasel, thunderbird, etc. but they don't appear to use the split-out package of NSS. I reported the same bug against gnutls, #563127. The maintainer found that gnutls refused to accept the certificate because it was issues by a V1 CA. Sadly I'm no X.509 expert so I don't know what that really means. The certificate in question was issued in April 2009, so it's not exactly ancient. Please tell me if you'd like the server address to debug this further yourself, or whether there are any command line utilities for NSS that I can use as the equivalent of gnutls-bin/'openssl s_client' to debug further. There is one, but you would need to build libnss3 yourself (and get the binary in mozilla/security/nss/cmd/vfyserv). If you'd prefer me to further investigate, please report the server address. Because this coincides with the upgrade from 3.12.4 to 3.12.5 I am assuming that NSS made a similar policy change to GnuTLS, to stop trusting V1 CAs. If this is the kind of thing that a user of NSS can override, please let me know and I'll forward that information to the (evolution) upstream bug at https://bugzilla.gnome.org/show_bug.cgi?id=605773. There is no such change that I can see related to trusting V1 CA certificates. Mike -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
On Wed, Jan 06, 2010 at 12:31:34PM +, Sam Morris wrote: Before I go all the way to install evolution, could you check if there is a secmod.db file in your evolution folder or somewhere else it would be using ? (you can try to check in a strace output, possibly). Same question for key3.db and cert8.db. These files do indeed exist, in ~/.evolution. If you just wanted to check where evolution stores its certificate information, you can skip the next paragraph. :) I needed to get access to my email for work, so I accepted evolution's certificate warning. This seems to add a _permanent_ exemption for the certificate, and evolution does not seem to have any UI for manipulating exemptions, leaving me unable to reproduce the problem on this computer any more. In order to try and remove the exemption, I deleted the cert8.db, key3.db and secomd.db files in ~/.evolution. Evolution happily recreated them, but they are empty; so now evolution doesn't know about _any_ certificate authorities at all. So I can't reproduce the bug on this computer any more (or connect to any SSL-using server without having to manually verify the certificate, argh)... the bug will still exist on my system at home, so if you want these files then I can pull them off there later this evening. That would be useful, thanks. You can also try giving the database to vfyserv (not sure if it needs to be the directory path, or if it needs to include the secmod.db leaf), which should theorically make vfyserv do the same thing as evolution. Mike PS: I'm Cc'ing the bug again to have all the above messages logged, with your server address stripped off. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
On Wed, 2010-01-06 at 13:53 +0100, Mike Hommey wrote: On Wed, Jan 06, 2010 at 12:31:34PM +, Sam Morris wrote: Before I go all the way to install evolution, could you check if there is a secmod.db file in your evolution folder or somewhere else it would be using ? (you can try to check in a strace output, possibly). Same question for key3.db and cert8.db. These files do indeed exist, in ~/.evolution. If you just wanted to check where evolution stores its certificate information, you can skip the next paragraph. :) I needed to get access to my email for work, so I accepted evolution's certificate warning. This seems to add a _permanent_ exemption for the certificate, and evolution does not seem to have any UI for manipulating exemptions, leaving me unable to reproduce the problem on this computer any more. In order to try and remove the exemption, I deleted the cert8.db, key3.db and secomd.db files in ~/.evolution. Evolution happily recreated them, but they are empty; so now evolution doesn't know about _any_ certificate authorities at all. So I can't reproduce the bug on this computer any more (or connect to any SSL-using server without having to manually verify the certificate, argh)... the bug will still exist on my system at home, so if you want these files then I can pull them off there later this evening. That would be useful, thanks. You can also try giving the database to vfyserv (not sure if it needs to be the directory path, or if it needs to include the secmod.db leaf), which should theorically make vfyserv do the same thing as evolution. I just had the idea of creating a new user, setting up my evolution accounts, and trying vfyserv: t...@durandal:~$ /tmp/nss/nss-3.12.5/mozilla/security/nss/cmd/vfyserv/Linux2.6_x86_64_glibc_PTH_64_OPT.OBJ/vfyserv -p 443 -d ~/.evolution/ imap.example.com Connecting to host imap.example.com (addr 217.160.200.53) on port 443 PROBLEM WITH THE CERT CHAIN: CERT 3. i...@valicert.com [Certificate Authority]: ERROR -8172: Peer's certificate issuer has been marked as not trusted by the user. e=i...@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O=ValiCert, Inc.,L=ValiCert Validation Network Error in function PR_Write: -8172 - Peer's certificate issuer has been marked as not trusted by the user. This also happens with my personal mail server (crypt.ethx.net) that works fine at home. This is looking more and more like a bug in evolution rather than NSS, except that if I downgrade to NSS 3.12.4 everything works again. Anyway, I will perform the same new-user test on my home machine with both versions of NSS and report back. -- Sam Morris s...@robots.org.uk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
Package: libnss3-1d Version: 3.12.5-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since upgrading libnss3-1d to 3.12.5, I have been unable to connect to my company's email server. Evolution gives me this dialog: SSL Certificate check for imap.example.com: Issuer:serialNumber=,CN=Go Daddy Secure Certification Authority,OU=http://certificates.godaddy.com/repository,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US Subject: CN=*.example.com,OU=Domain Control Validated,O=*.example.com Fingerprint: ec:cf:43:7f:87:84:f0:63:ec:b4:5d:60:e5:7e:6b:23 Signature: BAD No problem with iceweasel, thunderbird, etc. but they don't appear to use the split-out package of NSS. I reported the same bug against gnutls, #563127. The maintainer found that gnutls refused to accept the certificate because it was issues by a V1 CA. Sadly I'm no X.509 expert so I don't know what that really means. The certificate in question was issued in April 2009, so it's not exactly ancient. Please tell me if you'd like the server address to debug this further yourself, or whether there are any command line utilities for NSS that I can use as the equivalent of gnutls-bin/'openssl s_client' to debug further. Because this coincides with the upgrade from 3.12.4 to 3.12.5 I am assuming that NSS made a similar policy change to GnuTLS, to stop trusting V1 CAs. If this is the kind of thing that a user of NSS can override, please let me know and I'll forward that information to the (evolution) upstream bug at https://bugzilla.gnome.org/show_bug.cgi?id=605773. - -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (430, 'testing'), (420, 'unstable'), (410, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnss3-1d depends on: ii dpkg 1.15.5.4 Debian package management system ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libnspr4-0d4.8.2-1 NetScape Portable Runtime Library ii libsqlite3-0 3.6.21-2 SQLite 3 shared library ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime libnss3-1d recommends no packages. libnss3-1d suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAks9+IoACgkQshl/216gEHgbmgCg4/dEMui2RE3t+GgVJ9je7ouJ AB0AmgOjth0/Cy2emJ/RkhIl56IzQ0Ec =kMHW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
Hi, Did you read my message? I said that downgrading helps, setting NSS_SSL_ENABLE_RENEGOTIATION=1 didn't help me either. I can only guess, but I think that's because Evolution is so deeply integrated into GNOME that running NSS_SSL_ENABLE_RENEGOTIATION=1 evolution simply isn't enough. Would you be so kind to try downgrading libnss3-1d to the lenny version and (if successful) re-merge the bugs? Cheers Alexander Am Freitag, den 01.01.2010, 21:17 + schrieb Sam Morris: unmerge 563253 thanks On Fri, 2010-01-01 at 16:58 +0100, Alexander Kurtz wrote: I've got exactly the same problem here with Evolution 2.28 and my Googlemail-Account. It is caused by bug #561918 [1]. You should check my message there. Hi Alexander, that does not appear to be the case for me. Setting NSS_SSL_ENABLE_RENEGOTIATION=1 in the environment does not prevent the verification failure. I was careful to force shutdown evolution, then launch it afresh in case the child e-d-s processes also required it to be set. Regards, signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#563253: libnss3-1d: Fails to verify the certificate of my company email server
On Fri, 2010-01-01 at 23:02 +0100, Alexander Kurtz wrote: Hi, Did you read my message? I said that downgrading helps, setting NSS_SSL_ENABLE_RENEGOTIATION=1 didn't help me either. I can only guess, but I think that's because Evolution is so deeply integrated into GNOME that running NSS_SSL_ENABLE_RENEGOTIATION=1 evolution simply isn't enough. Would you be so kind to try downgrading libnss3-1d to the lenny version and (if successful) re-merge the bugs? I'm pretty sure the lenny version works fine, since 3.12.4 also worked for me until it was replaced by 3.12.5. Other than that, I don't see the similarity between the two bugs. I am not using a certificate to authenticate as the reporter of #561918 is, but regular password authentication. I also don't have the problem when connecting to the server with iceweasel (the same certificate is used by the web server on the same machine) Cheers Alexander -- Sam Morris https://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
