Created attachment 531040 [details] sssd.conf Description of problem: System configured with ldap and kerberos for authentication. If I ssh as root, it takes about 5 minutes to get a prompt. I cannot login as myself. I cannot login as root on the console, it times out. Version-Release number of selected component (if applicable): sssd-1.6.2-4.fc17.x86_64 How reproducible: Everytime
Created attachment 531041 [details] sssd logs
Note that this is the identical sssd.conf that I'm using fine on F16, and very nearly the same version, so probably some library that sssd uses is the problem?
These lines from the domain log: ---- (Mon Oct 31 15:01:01 2011) [sssd[be[default]]] [sdap_process_message] (9): Message type: [LDAP_RES_EXTENDED] (Mon Oct 31 15:01:01 2011) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server wil ling to negotiate SSL. (Mon Oct 31 15:01:49 2011) [sssd[be[default]]] [server_setup] (3): CONFDB: /var/lib/sss/db/config.ldb (Mon Oct 31 15:01:49 2011) [sssd[be[default]]] [recreate_ares_channel] (4): Initializing new c-ares channel ---- Indicate that the SSSD back end might have crashed. Can you check syslog for crasher messages and/or consult abrt? If SSSD is indeed crashing, then a core file or a backtrace would be nice.
Sorry, I spoke too soon. The back end did not crash, but was killed by the monitor: ---- (Mon Oct 31 15:01:49 2011) [sssd] [tasks_check_handler] (1): Killing service [default], not responding to pings! ---- I only see one "ping" received by the back end in the back end logs.. Can you check if there are any AVC denials?
Hmm, this is suspicious. The last message is (Mon Oct 31 15:01:01 2011) [sssd[be[default]]] [sdap_connect_done] (3): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL After that, we *should* be seeing messages about it trying to read the RootDSE. Instead, it's simply hanging there. From inspection of the source, the most likely culprit is the call to ldap_start_tls() (which is noted in the code as being potentially blocking). I have a feeling that the recent update to nss-3.13.0rc0.1 in Rawhide is probably responsible (since the openldap libraries are unchanged). Could you try downgrading to nss-3.12.10-7.fc16 to see if it resolves the issue? If so, we'll reassign this bug to the nss component.
It works with nss-3.12.10-7.fc16.
Reassigning this BZ to the 'nss' component. As witnessed above, this is a regression in nss-3.13.0rc0.1
Why the heck is nss-3.13.1 which still breaks sssd and others being submitted as an update to F16? sssd[be[default]]: Could not start TLS encryption. TLS error -8172:Peer's c ertificate issuer has been marked as not trusted by the user.
> sssd[be[default]]: Could not start TLS encryption. TLS error > -8172:Peer's certificate issuer has been marked as not trusted by the user. What is the cert chain from the ldap server? Several CA certs have been explicitly turned off in the latest version of NSS. I really don't think that's the issue, but it would be good to eliminate it. Also, what is the ldap server you are trying to connect to (RHDS, openldap, active directory, etc...)? Finally does setting NSS_SSL_CBC_RANDOM_IV=0 in the environment fix the problem?
Interestingly enough, sssd seems to be working for me on rawhide now with nss-3.13.1-3.fc17.x86_64 and sssd-1.6.3-2.fc17.x86_64. The LDAP server's certificate is signed by our internal CA. That CA cert is in /etc/openldap/cacerts/. Server is 389/FDS on EL5: 389-ds-1.2.1-1.el5 389-ds-base-1.2.9.9-1.el5 NSS_SSL_CBC_RANDOM_IV=0 does not have an effect.
Thanks Orion, that eliminates a lot. The next question what does: certutil -L -d sql:/etc/pki/nssdb show? bob
Actually do that on both the f16 and the rawhide system. (I'm particularly interested in certs that have the 'p' bit set).
*** Bug 752990 has been marked as a duplicate of this bug. ***
*** Bug 753282 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > The next question what does: > > certutil -L -d sql:/etc/pki/nssdb > > show? Appears to be empty on both. [root@makani ~]# certutil -L -d sql:/etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@makani ~]#
*** Bug 753390 has been marked as a duplicate of this bug. ***
FYI: we just stumbled over a bug in the NSS 3.13.x headers that can lead to compilation errors for code that compiled fine with NSS 3.12. "compilation error: pkcs11n.h:365:26: error: "__GNUC_MINOR" is not defined" <https://bugzilla.mozilla.org/show_bug.cgi?id=702090> I would vote against updating to 3.13.x before this is fixed.
(In reply to comment #17) > FYI: we just stumbled over a bug in the NSS 3.13.x headers that can lead to > compilation errors for code that compiled fine with NSS 3.12. This seems to be already fixed in Fedora: http://pkgs.fedoraproject.org/gitweb/?p=nss.git;a=commitdiff;h=dc20ddf
nss 3.13.1 is breaking yum....I just spent 2 hours trying to figure out why. Going back to 3.12.10 fixes the problem.
For the F-16 nss 3.13.1 update, it appears to be broken because a matching nss-softokn 3.13.1 wasn't included. nss-3.13.1-2.fc16 works OK when combined with nss-softokn-3.13.1-1.fc17 from koji.
(In reply to comment #15) > (In reply to comment #11) > > The next question what does: > > > > certutil -L -d sql:/etc/pki/nssdb > > > > show? > > Appears to be empty on both. > [root@makani ~]# certutil -L -d sql:/etc/pki/nssdb > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > [root@makani ~]# Orion, Please save the databases and send them to us. I would like to examine them using the sqlite db tool. Thee reason is that databeses may actually contain old trust records in them that certutil cannot currently list them. Thanks.
Created attachment 533590 [details] /etc/pki/nssdb Here is the F16 nssdb
Hi, I notices similar problem with LDAP and TLS. LDAP can't be used for authentication, when TLS encryption is enabled at Fedora 15 and 16. You can notice same problems, when ldapsearch is used: sssd[be[default]]: Could not start TLS encryption. TLS error -8172:Unknown code ___f 20 Exactly the same openldap conficuration works at RedHat 6 or CentOS 6. The reason is following: openldap is linked with GnuTLS library at Fedora, but openldap is linked with OpenSSL at RedHat/CentOS 6. Please, relink openldap library with OpenSSL. I guess that it will fix many bugs in bugzilla.
(In reply to comment #23) > Exactly the same openldap conficuration works at RedHat 6 or CentOS 6. The > reason is following: openldap is linked with GnuTLS library at Fedora, but > openldap is linked with OpenSSL at RedHat/CentOS 6. > > Please, relink openldap library with OpenSSL. I guess that it will fix many > bugs in bugzilla. OpenLDAP is linked againt Mozilla's Network Security Services (NSS), not GnuTLS. It is the same on both Red Hat Enterprise Linux 6 and Fedora. The bug here is that a Mozilla NSS package was released with a regression in the certificate validation routines. Once the 'nss' package is fixed, this will continue working. Also, we will *not* be linking against openssl. It used to be that way, but we changed it to Mozilla NSS as part of the crypto-consolidation effort (intended to allow for full crypto-certification).
Ah, you are right about Mozilla NSS at Fedora: Fedora16 # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fffb53ff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00000030fce00000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00000030fd600000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00000030f9600000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000030f0a00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00000030e7a00000) libssl3.so => /usr/lib64/libssl3.so (0x00000030f4600000) libsmime3.so => /usr/lib64/libsmime3.so (0x00000030f3e00000) libnss3.so => /usr/lib64/libnss3.so (0x00000030f3200000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000030f3600000) libplds4.so => /lib64/libplds4.so (0x00000030f2600000) libplc4.so => /lib64/libplc4.so (0x00000030f2a00000) libnspr4.so => /lib64/libnspr4.so (0x00000030f2200000) libc.so.6 => /lib64/libc.so.6 (0x00000030e5600000) libdl.so.2 => /lib64/libdl.so.2 (0x00000030e5e00000) libfreebl3.so => /lib64/libfreebl3.so (0x00000030f0e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e5a00000) libz.so.1 => /lib64/libz.so.1 (0x00000030e6e00000) /lib64/ld-linux-x86-64.so.2 (0x00000030e5200000) But RedHat/CentOS really uses OpenSSL RedHat/CentOS6 # ldd /usr/bin/ldapsearch linux-vdso.so.1 => (0x00007fff807ff000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x0000003b87400000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x0000003b85000000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003b84400000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003b81c00000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003b7f800000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003b80800000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003b75c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003b74000000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003b74800000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003b81000000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003b7fc00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003b7e800000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003b7f400000) libz.so.1 => /lib64/libz.so.1 (0x0000003b75000000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003b80400000) /lib64/ld-linux-x86-64.so.2 (0x0000003b73800000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003b7ec00000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003b80c00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b74c00000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003b75800000) When can I expect fixing this bug in NSS? Does anybody work on it? Can I help with this?
(In reply to comment #25) > But RedHat/CentOS really uses OpenSSL That was a bug in RHEL 6.0 that was fixed in RHEL 6.1. CentOS is lagging very far behind these days (six months).
Do I understand you right that OpenLDAP has used OpenSSL at RHEL 6.0 and OpenLDAP uses Mozila NSS at RHEL 6.1 now? Sorry, that I'm asking, because I have access only to RHEL 5.7 right now. OpenLDAP uses OpenSSL at RHEL 5.7 too.
(In reply to comment #27) > Do I understand you right that OpenLDAP has used OpenSSL at RHEL 6.0 and > OpenLDAP uses Mozila NSS at RHEL 6.1 now? Sorry, that I'm asking, because I > have access only to RHEL 5.7 right now. OpenLDAP uses OpenSSL at RHEL 5.7 too. Yes, RHEL 6.1 has OpenLDAP with Mozilla NSS. RHEL 5.7 and 6.0 are still on openssl.
bmo #702090 is now fixed in their CVS tree.
I am able to reproduce the problem by attempting a yum update something or yum install something while having nss-3.13.1-x and nss-softokn-3.12.y installed in my system. Now that I have a Rawhide system with lots of debug-info packages installed I should able to trace through the code. Stay tuned.
I have learned is that yum depends on nss indirectly via libcurl. yum uses the python-urlgrabber. Even though I was doing a yum local{install|update} the python_urlgrabber comes into play. This is the python binding into libcurl. Looking at its code there is some references to the CA cert and and peer authentication. The pem module comes into play. I now remember looking at this stuff when Kamil Dudka and I where dealing with some candlepin problems for the RHEL 6.1 relase. The bug may not be in pem after all but given past experience I can't help but considering PEM a possible suspect :-) I want to rule that out.
The problems turns out to be related to the way we build the pem module after all. It's fine to have nss from 3.13 coexist with nss-softokn from 3.12, that combination is not the cause as Bob was able to verify with some simple tests. 1) Thee vfyserver test tool and is able to verify the fedora server cert. 2) Replacing the pem module shared library with the one from f15, which was built while totally on 3.12.10, made the problems go way. The pem module calls freebl directly and at build time is statically linked with libfreebl3.a. At runtime the static freebl library dynamically loads the libfreebl3.so shared library. Odd as it seems this was done this way for Solaris support. Bob can give give you gory details if you need them. I won't get into this here. Bob explained that if you link pem with the latest version of freebl there could be problems because due to the changes from 3.12 to 3.13 the tables have changed. The buildroot has softoken/freebl from 3.12.10 so in principle that should caused problems but it does as I was able to verify when I built on my system. I have freebl from 3.12 in my buildroot and so do the koji build system. The problem is that the linking was not done against the library on the buildroot but against the library on the build tree. The tree has 3.13 sources and the previously build freebl was used. We must ensure that the buildroot version is the one used with pem and build time. This will be the case if we build nss without any softoken present in the tree. There is such a bug and while working on RHEL 6.2 I was able to do such build and the patches where approved but not applied as there were some remaining issues to solve. Readjusting the patches for 3.13 is quite a bit of work to gte right. For the time being I have opted for a less ambitious approach. 1) First get pem to link with the 3.12 freebl in the buildroot. 2) Patch other parts of nss so they to build against the old nss-softokn. Basically conditionally compile out calls the new crypto algorithms, sha224 and RSA PSS, which aren't supported by the old softoken. 3) Disable the tests that require sha224 or PSS. 4) Deal with new or renamed symbols, e.g CERTDB_TERMINAL_RECORD. It builds with such changes and the problem goes away when I install on my system nss and nss-util 3.13.1 while keeping softokn at 3.12. I can do yum updates an installs now. Everything is currently on the buildroot. I will do further testing and wish to deal with CERTDB_TERMINAL_RECORD a cleaner way before we merge into the new RHEL git repo. I will attach the patches next.
Created attachment 541096 [details] do not compile fipstest in the nss build This application runs test agaitns the NIST/Lab supplied test data and is used as part of our submissions to the lab. It properly belongs in nss-softokn. We will eventually compile it as part of the nss-softokn build.
Created attachment 541103 [details] Conditionally compile code that depends on sha224 or pss The compile flag -DNO_SHA224_AVAILABLE is passed in when we are using the nss-softokn 3.12.x from the build root which doesn't have support for SHA224 nor PSS. The NO_SHA224_AVAILABLE flag is turned via an export USE_SYSTEM_FREEBL=1 in the nss.spec file.
Created attachment 541104 [details] makes pem and other code use system freebl Forces the build to statically link the PEM shared library against the system freebl, the 3.12.x one in the buildroot. This is the patch that fixes this bug.
Created attachment 541106 [details] define CERTDB_TERMINAL_RECORD if not defined already This a patch that I really don't like. /mozilla/dist/public/nss/certdb.h has a new symbol defined as #define CERTDB_TERMINAL_RECORD (1<<0) Even though I'm including the header the symbol doesn't get seen. I ended up conditionally defining in various places which is not too clean. Even tough it works I want to find a cleaner way
Created attachment 541120 [details] Properly fix the 'undefined' CERTDB_TERMINAL_RECORD problem The old header in /usr/include/nss3/certdb.h was being used instead of the one in the tree as I had mistakenly added that path in front in the include path in CFLAGS. Problem fixed cleanly and the ugly patch removed.
How about the GNUC bug in comment 17 and comment 29?
(In reply to comment #38) > How about the GNUC bug in comment 17 and comment 29? Regarding comment 17: I moved Dan Williams's patch for this, (http://pkgs.fedoraproject.org/gitweb/?p=nss.git;a=commitdiff;h=dc20ddf) from nss.pec, to nss-util.spec because it's nss-util-devel that's actually installs the pkcs11n.h header. Regarding comment 29: Thanks for pointing that out, we better test the fix with OpenLDAP.
(In reply to comment #39) > Regarding comment 17: I moved Dan Williams's patch for this, > (http://pkgs.fedoraproject.org/gitweb/?p=nss.git;a=commitdiff;h=dc20ddf) > from nss.pec, to nss-util.spec because it's nss-util-devel that's actually > installs the pkcs11n.h header. Oh, thank you for pointing out.
(In reply to comment #25) > > When can I expect fixing this bug in NSS? Does anybody work on it? Can I help > with this? Hi Jiri, Builds with a proposed fix are now available. nss: http://koji.fedoraproject.org/koji/buildinfo?buildID=277574 nss-util: http://koji.fedoraproject.org/koji/packageinfo?packageID=9041 You certainly can help by verifying that with these you can access your LDAP server. Thanks in advance.
Appears to work fine for me.
Hi Elio, I use 64 bit systems and it seems that 64 rpms has some dependency problems. I tried to install rpms with yum with following results: --> Finished Dependency Resolution Error: Package: nss-tools-3.13.1-6.fc16.x86_64 (/nss-tools-3.13.1-6.fc16.x86_64) Requires: libnssutil3.so(NSSUTIL_3.13)(64bit) Error: Package: nss-3.13.1-6.fc16.x86_64 (/nss-3.13.1-6.fc16.x86_64) Requires: nss-util >= 3.13.1 Installed: nss-util-3.12.10-1.fc16.x86_64 (@fedora) nss-util = 3.12.10-1.fc16 Error: Package: nss-3.13.1-6.fc16.x86_64 (/nss-3.13.1-6.fc16.x86_64) Requires: libnssutil3.so(NSSUTIL_3.13)(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest rpm -Uvh gave similar results. When tried to use yum with --skip-broken, then it tried to install some i686 packages. May be, I do something wrong.
I have an x86_64 system where I'm trying to reproduce you install problem. 1) I first did a su -c 'yum distro-sync' to make I only had 3.12.10 packages and I now have this: [emaldona@localhost Downloads]$ rpm -qa | grep ^nss nss-pkcs11-devel-3.12.10-7.fc16.x86_64 nss-debuginfo-3.12.10-7.fc16.x86_64 nss-util-3.12.10-1.fc16.x86_64 nss-3.12.10-7.fc16.x86_64 nss-softokn-3.12.10-6.fc16.x86_64 nss-util-debuginfo-3.12.10-1.fc16.x86_64 nss-myhostname-0.3-1.fc16.x86_64 nss-softokn-freebl-devel-3.12.10-6.fc16.x86_64 nss-softokn-freebl-3.12.10-6.fc16.x86_64 nss-softokn-debuginfo-3.12.10-6.fc16.x86_64 nss-softokn-devel-3.12.10-6.fc16.x86_64 nss-tools-3.12.10-7.fc16.x86_64 nss-sysinit-3.12.10-7.fc16.x86_64 nss-softokn-freebl-3.12.10-6.fc16.i686 nss-util-devel-3.12.10-1.fc16.x86_64 nss_compat_ossl-0.9.6-2.fc15.x86_64 nss-devel-3.12.10-7.fc16.x86_64 2) These are rpm's I want to install via yum local update: [emaldona@localhost Downloads]$ ls nss-*.rpm nss-3.13.1-6.fc16.x86_64.rpm nss-pkcs11-devel-3.13.1-6.fc16.x86_64.rpm nss-util-3.13.1-3.fc16.x86_64.rpm nss-debuginfo-3.13.1-6.fc16.x86_64.rpm nss-sysinit-3.13.1-6.fc16.x86_64.rpm nss-util-debuginfo-3.13.1-3.fc16.x86_64.rpm nss-devel-3.13.1-6.fc16.x86_64.rpm nss-tools-3.13.1-6.fc16.x86_64.rpm nss-util-devel-3.13.1-3.fc16.x86_64.rpm 3) Now a log update with --verbose turned on: [emaldona@localhost Downloads]$ su -c 'yum --verbose localupdate nss-*.rpm' Password: Loading "auto-update-debuginfo" plugin Not loading "blacklist" plugin, as it is disabled Loading "fastestmirror" plugin Loading "langpacks" plugin Loading "presto" plugin Loading "refresh-packagekit" plugin Not loading "whiteout" plugin, as it is disabled Adding en_US to language list Config time: 0.029 Yum Version: 3.4.3 Setting up Local Package Process rpmdb time: 0.000 Examining nss-3.13.1-6.fc16.x86_64.rpm: nss-3.13.1-6.fc16.x86_64 Marking nss-3.13.1-6.fc16.x86_64.rpm as an update to nss-3.12.10-7.fc16.x86_64 Setting up Package Sacks Found 41 installed debuginfo package(s) Loading mirror speeds from cached hostfile * fedora: mirror.lib.ucdavis.edu * fedora-debuginfo: mirror.lib.ucdavis.edu * fedora-source: mirrors.usc.edu * updates: mirror.lib.ucdavis.edu * updates-debuginfo: mirror.lib.ucdavis.edu * updates-source: mirror.lib.ucdavis.edu pkgsack time: 1.365 Obs Init time: 1.685 Building updates object up:simple updates time: 0.053 up:obs time: 0.007 up:condense time: 0.000 updates time: 0.670 Examining nss-debuginfo-3.13.1-6.fc16.x86_64.rpm: nss-debuginfo-3.13.1-6.fc16.x86_64 Marking nss-debuginfo-3.13.1-6.fc16.x86_64.rpm as an update to nss-debuginfo-3.12.10-7.fc16.x86_64 Examining nss-devel-3.13.1-6.fc16.x86_64.rpm: nss-devel-3.13.1-6.fc16.x86_64 Marking nss-devel-3.13.1-6.fc16.x86_64.rpm as an update to nss-devel-3.12.10-7.fc16.x86_64 Examining nss-pkcs11-devel-3.13.1-6.fc16.x86_64.rpm: nss-pkcs11-devel-3.13.1-6.fc16.x86_64 Marking nss-pkcs11-devel-3.13.1-6.fc16.x86_64.rpm as an update to nss-pkcs11-devel-3.12.10-7.fc16.x86_64 Examining nss-sysinit-3.13.1-6.fc16.x86_64.rpm: nss-sysinit-3.13.1-6.fc16.x86_64 Marking nss-sysinit-3.13.1-6.fc16.x86_64.rpm as an update to nss-sysinit-3.12.10-7.fc16.x86_64 Examining nss-tools-3.13.1-6.fc16.x86_64.rpm: nss-tools-3.13.1-6.fc16.x86_64 Marking nss-tools-3.13.1-6.fc16.x86_64.rpm as an update to nss-tools-3.12.10-7.fc16.x86_64 Examining nss-util-3.13.1-3.fc16.x86_64.rpm: nss-util-3.13.1-3.fc16.x86_64 Marking nss-util-3.13.1-3.fc16.x86_64.rpm as an update to nss-util-3.12.10-1.fc16.x86_64 Examining nss-util-debuginfo-3.13.1-3.fc16.x86_64.rpm: nss-util-debuginfo-3.13.1-3.fc16.x86_64 Marking nss-util-debuginfo-3.13.1-3.fc16.x86_64.rpm as an update to nss-util-debuginfo-3.12.10-1.fc16.x86_64 Examining nss-util-devel-3.13.1-3.fc16.x86_64.rpm: nss-util-devel-3.13.1-3.fc16.x86_64 Marking nss-util-devel-3.13.1-3.fc16.x86_64.rpm as an update to nss-util-devel-3.12.10-1.fc16.x86_64 Resolving Dependencies --> Running transaction check ---> Package nss.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss.x86_64 0:3.13.1-6.fc16 - u looking for ('config(nss)', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss.x86_64 0:3.13.1-6.fc16 - u looking for ('nspr', 'GE', ('0', '4.8.9', None)) as a requirement of nss.x86_64 0:3.13.1-6.fc16 - u looking for ('nss-softokn(x86-64)', 'GE', ('0', '3.12.9', None)) as a requirement of nss.x86_64 0:3.13.1-6.fc16 - u looking for ('nss-util', 'GE', ('0', '3.13.1', None)) as a requirement of nss.x86_64 0:3.13.1-6.fc16 - u looking for ('libnssutil3.so(NSSUTIL_3.13)(64bit)', None, (None, None, None)) as a requirement of nss.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-debuginfo.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss-debuginfo.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss-debuginfo.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss-debuginfo.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-devel.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss-devel.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss-devel.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('nss', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('nspr-devel', 'GE', ('0', '4.8.9', None)) as a requirement of nss-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('pkgconfig(nspr)', 'GE', ('0', '4.8.9', None)) as a requirement of nss-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('pkgconfig(nss-util)', 'GE', ('0', '3.13.1', None)) as a requirement of nss-devel.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-pkcs11-devel.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss-pkcs11-devel.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('nss-devel', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 - u looking for ('nss-softokn-freebl-devel', 'GE', ('0', '3.12.9', None)) as a requirement of nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-sysinit.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss-sysinit.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss-sysinit.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss-sysinit.x86_64 0:3.13.1-6.fc16 - u looking for ('config(nss-sysinit)', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss-sysinit.x86_64 0:3.13.1-6.fc16 - u looking for ('nss', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss-sysinit.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-tools.x86_64 0:3.12.10-7.fc16 will be updated Checking deps for nss-tools.x86_64 0:3.12.10-7.fc16 - ud ---> Package nss-tools.x86_64 0:3.13.1-6.fc16 will be an update Checking deps for nss-tools.x86_64 0:3.13.1-6.fc16 - u looking for ('nss', 'EQ', ('0', '3.13.1', '6.fc16')) as a requirement of nss-tools.x86_64 0:3.13.1-6.fc16 - u looking for ('libnssutil3.so(NSSUTIL_3.13)(64bit)', None, (None, None, None)) as a requirement of nss-tools.x86_64 0:3.13.1-6.fc16 - u ---> Package nss-util.x86_64 0:3.12.10-1.fc16 will be updated Checking deps for nss-util.x86_64 0:3.12.10-1.fc16 - ud ---> Package nss-util.x86_64 0:3.13.1-3.fc16 will be an update Checking deps for nss-util.x86_64 0:3.13.1-3.fc16 - u looking for ('nspr', 'GE', ('0', '4.8.9', None)) as a requirement of nss-util.x86_64 0:3.13.1-3.fc16 - u looking for ('/sbin/ldconfig', None, (None, None, None)) as a requirement of nss-util.x86_64 0:3.13.1-3.fc16 - u looking for ('/sbin/ldconfig', None, (None, None, None)) as a requirement of nss-util.x86_64 0:3.13.1-3.fc16 - u ---> Package nss-util-debuginfo.x86_64 0:3.12.10-1.fc16 will be updated Checking deps for nss-util-debuginfo.x86_64 0:3.12.10-1.fc16 - ud ---> Package nss-util-debuginfo.x86_64 0:3.13.1-3.fc16 will be an update Checking deps for nss-util-debuginfo.x86_64 0:3.13.1-3.fc16 - u ---> Package nss-util-devel.x86_64 0:3.12.10-1.fc16 will be updated Checking deps for nss-util-devel.x86_64 0:3.12.10-1.fc16 - ud ---> Package nss-util-devel.x86_64 0:3.13.1-3.fc16 will be an update Checking deps for nss-util-devel.x86_64 0:3.13.1-3.fc16 - u looking for ('nss-util', 'EQ', ('0', '3.13.1', '3.fc16')) as a requirement of nss-util-devel.x86_64 0:3.13.1-3.fc16 - u looking for ('nspr-devel', 'GE', ('0', '4.8.9', None)) as a requirement of nss-util-devel.x86_64 0:3.13.1-3.fc16 - u looking for ('pkgconfig(nspr)', 'GE', ('0', '4.8.9', None)) as a requirement of nss-util-devel.x86_64 0:3.13.1-3.fc16 - u --> Finished Dependency Resolution Dependency Process ending Depsolve time: 0.259 Dependencies Resolved ==================================================================================================================================== Package Arch Version Repository Size ==================================================================================================================================== Updating: nss x86_64 3.13.1-6.fc16 /nss-3.13.1-6.fc16.x86_64 2.5 M nss-debuginfo x86_64 3.13.1-6.fc16 /nss-debuginfo-3.13.1-6.fc16.x86_64 32 M nss-devel x86_64 3.13.1-6.fc16 /nss-devel-3.13.1-6.fc16.x86_64 726 k nss-pkcs11-devel x86_64 3.13.1-6.fc16 /nss-pkcs11-devel-3.13.1-6.fc16.x86_64 291 k nss-sysinit x86_64 3.13.1-6.fc16 /nss-sysinit-3.13.1-6.fc16.x86_64 31 k nss-tools x86_64 3.13.1-6.fc16 /nss-tools-3.13.1-6.fc16.x86_64 2.6 M nss-util x86_64 3.13.1-3.fc16 /nss-util-3.13.1-3.fc16.x86_64 152 k nss-util-debuginfo x86_64 3.13.1-3.fc16 /nss-util-debuginfo-3.13.1-3.fc16.x86_64 969 k nss-util-devel x86_64 3.13.1-3.fc16 /nss-util-devel-3.13.1-3.fc16.x86_64 282 k Transaction Summary ==================================================================================================================================== Upgrade 9 Packages Total size: 39 M Is this ok [y/N]: y Downloading Packages: Member: nss-sysinit.x86_64 0:3.12.10-7.fc16 - ud Member: nss.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-3.13.1-6.fc16.x86_64 in mode u Member: nss-debuginfo.x86_64 0:3.12.10-7.fc16 - ud Member: nss-devel.x86_64 0:3.12.10-7.fc16 - ud Member: nss-tools.x86_64 0:3.12.10-7.fc16 - ud Member: nss-util-devel.x86_64 0:3.13.1-3.fc16 - u Adding Package nss-util-devel-3.13.1-3.fc16.x86_64 in mode u Member: nss-util.x86_64 0:3.13.1-3.fc16 - u Adding Package nss-util-3.13.1-3.fc16.x86_64 in mode u Member: nss-tools.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-tools-3.13.1-6.fc16.x86_64 in mode u Member: nss-util.x86_64 0:3.12.10-1.fc16 - ud Member: nss-sysinit.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-sysinit-3.13.1-6.fc16.x86_64 in mode u Member: nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-pkcs11-devel-3.13.1-6.fc16.x86_64 in mode u Member: nss-debuginfo.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-debuginfo-3.13.1-6.fc16.x86_64 in mode u Member: nss.x86_64 0:3.12.10-7.fc16 - ud Member: nss-util-devel.x86_64 0:3.12.10-1.fc16 - ud Member: nss-devel.x86_64 0:3.13.1-6.fc16 - u Adding Package nss-devel-3.13.1-6.fc16.x86_64 in mode u Member: nss-util-debuginfo.x86_64 0:3.12.10-1.fc16 - ud Member: nss-util-debuginfo.x86_64 0:3.13.1-3.fc16 - u Adding Package nss-util-debuginfo-3.13.1-3.fc16.x86_64 in mode u Member: nss-pkcs11-devel.x86_64 0:3.12.10-7.fc16 - ud Running Transaction Check Transaction Check time: 0.177 Running Transaction Test Transaction Test Succeeded Transaction Test time: 0.185 Running Transaction Updating : nss-util-3.13.1-3.fc16.x86_64 1/18 Updating : nss-sysinit-3.13.1-6.fc16.x86_64 2/18 Updating : nss-3.13.1-6.fc16.x86_64 3/18 Updating : nss-util-devel-3.13.1-3.fc16.x86_64 4/18 Updating : nss-devel-3.13.1-6.fc16.x86_64 5/18 Updating : nss-pkcs11-devel-3.13.1-6.fc16.x86_64 6/18 Updating : nss-tools-3.13.1-6.fc16.x86_64 7/18 Updating : nss-util-debuginfo-3.13.1-3.fc16.x86_64 8/18 Updating : nss-debuginfo-3.13.1-6.fc16.x86_64 9/18 Cleanup : nss-tools-3.12.10-7.fc16.x86_64 10/18 Cleanup : nss-pkcs11-devel-3.12.10-7.fc16.x86_64 11/18 Cleanup : nss-devel-3.12.10-7.fc16.x86_64 12/18 Cleanup : nss-util-devel-3.12.10-1.fc16.x86_64 13/18 Cleanup : nss-util-debuginfo-3.12.10-1.fc16.x86_64 14/18 Cleanup : nss-debuginfo-3.12.10-7.fc16.x86_64 15/18 Cleanup : nss-sysinit-3.12.10-7.fc16.x86_64 16/18 Cleanup : nss-3.12.10-7.fc16.x86_64 17/18 Cleanup : nss-util-3.12.10-1.fc16.x86_64 18/18 VerifyTransaction time: 0.586 Transaction time: 14.684 Updated: nss.x86_64 0:3.13.1-6.fc16 nss-debuginfo.x86_64 0:3.13.1-6.fc16 nss-devel.x86_64 0:3.13.1-6.fc16 nss-pkcs11-devel.x86_64 0:3.13.1-6.fc16 nss-sysinit.x86_64 0:3.13.1-6.fc16 nss-tools.x86_64 0:3.13.1-6.fc16 nss-util.x86_64 0:3.13.1-3.fc16 nss-util-debuginfo.x86_64 0:3.13.1-3.fc16 nss-util-devel.x86_64 0:3.13.1-3.fc16 Complete! It works for me on a real life x86_64 system with a lots of development packages on it. In the nss.spc and nss-util the Requires: haven't changed save for the updated version and release numbers. I don't use %{?isa} anywhere. Well, I do have on a line on nss-softokn.spec but that's not being used here. I have seen problems dealing with having i686 and x86_64 in the system in the past - which Dennis Gilmore was able to solve. I suspect you were not installing all the packages like I did. Don't know if that matters.
Hi, I'm sorry. I forget to download nss-util package. Downloading this package fixed my problem with installing packages. When I tried to test it, then it prints to /var/log/messages: sssd[be[default]]: Could not start TLS encryption. TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. It's progress :-), but authentication of users still doesn't work. Jiri
(In reply to comment #45) > Hi, > I'm sorry. I forget to download nss-util package. Downloading this package > fixed my problem with installing packages. > > When I tried to test it, then it prints to /var/log/messages: > > sssd[be[default]]: Could not start TLS encryption. TLS error -8172:Peer's > certificate issuer has been marked as not trusted by the user. > > It's progress :-), but authentication of users still doesn't work. Actually, the problem is that it doesn't trust the CA that signed the server cert. I am assuming the server cert is not a self-signed cert, could you confirm that? Do you have the CA cert separate from the server cert, or do you have them one after the other in the same file? The latter can be a problem. We do have an outstanding request for the PEM module to handle certificate chains in PEM files and I that may be the case of your problems but I am not sure. Until then the CA certs have to be separately added to the list of trusted certs in the nss database. Our certutil tool allows you to do that. I will help you with that once I know more about your setup.
Regarding my earlier comment "outstanding request for the PEM module to handle certificate chains in PEM files" plase see Bug 733794. It's sill a mere conjecture at this time so let's see what further information Jiri can provide us.
nss-3.13.1-6.fc16 with nss-util-3.13.1-3.fc16 are as bad as nss-3.13.1-2.fc16 with regard to breaking yum / curl: $ curl --verbose 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f16&arch=x86_64' * About to connect() to mirrors.fedoraproject.org port 443 (#0) * Trying 213.175.193.206... connected * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Certificate is signed by an untrusted issuer: 'CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US' * NSS error -8172 * Closing connection #0 * Peer certificate cannot be authenticated with given CA certificates curl: (60) Peer certificate cannot be authenticated with given CA certificates More details here: http://curl.haxx.se/docs/sslcerts.html Why is the upstream single NSS package even split into 3 separate .src.rpm packages? The nsspem-use-system-freebl.patch and similar parts of nss.spec look wrong - they define variables like USE_SYSTEM_FREEBL and FREEBL_LIB_DIR but nothing in any of the source Makefiles actually checks those variables. Should they be setting SOFTOKEN_LIB_DIR and SOFTOKEN_INCLUDE_DIR instead?
I can confirm Ed's results for curl. Perhaps my ldap works because we are our own CA and install our CA certificate.
(In reply to comment #48) > > Why is the upstream single NSS package even split into 3 separate .src.rpm > packages? There have actually been plans to do something like that upstream. We need the ability to release to tag and release softokn/feebl by itself in order optionally keep the cryptographic module at the last version that got FIPS 140 validation while continuing updating the rest of nss. See the feture page for Fedora/RHEL at https://fedoraproject.org/wiki/Features/SplitSoftoknFromNSS#Feature_Name It's a requirement RHEL but not is not Fedora. The way it was done before (RHEL5 and 4) became a maintenance header. I think those who at looked at the nss.spec will tend to agree :-) > > The nsspem-use-system-freebl.patch and similar parts of nss.spec look wrong - > they define variables like USE_SYSTEM_FREEBL and FREEBL_LIB_DIR but nothing in > any of the source Makefiles actually checks those variables. Should they be > setting SOFTOKEN_LIB_DIR and SOFTOKEN_INCLUDE_DIR instead? Definitely yes! That patch is missing a truck load of changes to the makefile and a config file which is what ensures the linking is against the system (or buildroot) libfreebl.so of the in tree one and I had written over a week ago. I was trying something more ambitious originally, then started from scratch and never copied over that part. You'll see it soon.
Created attachment 542372 [details] Corrected patch to make pem link against system freebl
A scratch build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=3573486 that you may want to test. It's prudent to have all patches reviewed.
(In reply to comment #50) > (RHEL5 and 4) became a maintenance header. s/header/headache/
(In reply to comment #46) > Actually, the problem is that it doesn't trust the CA that signed the server > cert. > I am assuming the server cert is not a self-signed cert, could you confirm > that? > Do you have the CA cert separate from the server cert, or do you have them one > after the other in the same file? The latter can be a problem. We do have an > outstanding request for the PEM module to handle certificate chains in PEM > files and I that may be the case of your problems but I am not sure. Until then > the CA certs have to be separately added to the list of trusted certs in the > nss database. Our certutil tool allows you to do that. I will help you with > that once I know more about your setup. Hi Elio, The server certificate is signed by CA. The certificate file of this CA is downloaded into the /etc/openldap/cacerts/ directory. The symlink on this .pem file is created correctly. I can see in log file of strace that this pem file is loaded, when ldapsearch is used. ldd proved that ldapsearch is using libraries from new rpms. Jiri
(In reply to comment #54) > Hi Elio, > The server certificate is signed by CA. The certificate file of this CA is > downloaded into the /etc/openldap/cacerts/ directory. The symlink on this .pem > file is created correctly. I can see in log file of strace that this pem file > is loaded, when ldapsearch is used. ldd proved that ldapsearch is using > libraries from new rpms. > > Jiri I just noticed that ldapsearch tries to use CA bundle from /etc/pki/tls/cert.pem at CentOS/RHEL 6.0. This CA bundle is not used (loaded) in fedora 16 (CentOS/RHEL 6.1). Certificate from "our" CA requires this bundle. When I copied this cert.pem to /etc/openldap/cacerts and I created symlink to this file, then it still prints: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.
(In reply to comment #52) > A scratch build is at > http://koji.fedoraproject.org/koji/taskinfo?taskID=3573486 > that you may want to test. It's prudent to have all patches reviewed. This seems to fix curl for me.
Orion, Thanks for retesting. We need for it to work for Jiri. Jiri, It isn't clear to me from your comments what build you used last. Does http://koji.fedoraproject.org/koji/taskinfo?taskID=3573486 help you at all?
Comment on attachment 541103 [details] Conditionally compile code that depends on sha224 or pss r+ for now, but these *Really* need to be runtime checks, not compile time checks. The code should work if you install a version of softoken/freebl that supports them! bob
Comment on attachment 541103 [details] Conditionally compile code that depends on sha224 or pss hey, why do you need to make changes to libfreebl. You aren't still linking with this version of libfreebl are you?
Comment on attachment 542372 [details] Corrected patch to make pem link against system freebl r+
(In reply to comment #59) > Comment on attachment 541103 [details] > Conditionally compile code that depends on sha224 or pss > > hey, why do you need to make changes to libfreebl. You aren't still linking > with this version of libfreebl are you? Good catch, glad I asked for your review, the sha224 patch shouldn't touch freebl at all, that's inside the FIPS boundary. I should remove those sections and things should work. The answer to the second question is no. The patch to link with system freebl is meant for the PEM module only. (In reply to comment #58) > r+ for now, but these *Really* need to be runtime checks, not compile time > checks. The code should work if you install a version of softoken/freebl that > supports them! > Agreed, A runtime check is is preferable. Looking at pkcs11{f|t}.h it looks like I could use C_GetMechanismList/C_GetMechanismInfo to find out if CKM_SHA224 or CKM_RSA_PKCS_PSS are supported by the softokn/freebl being used. Is there a simpler way?
There's a pk11wrap function that does it for you. PK11_DoesMechanism() is called on a specific slot. PK11_TokenExits() returns true of any token supports the mechanism. Which you use depends on context (if you're asked to operate on a specific key in a token, PK11_DoesMechanism() on that token. If you just want to do a function and don't have a slot in mind, PK11_TokenExists() will give you the right answer). NOTE: most of these already happen automatically under the covers. You may just want to trace down the calls and make sure the return the appropriate error. Also, if you ever call PK11_GetBestSlot(), it will return NULL if there are no tokens that can do the requested mechanism. The table of hashes may be the biggest challenge. don't worry about runtime checks in bltest, that needs to move to nss-softokn anyway, so compile time checks are fine for now.
(In reply to comment #62) > There's a pk11wrap function that does it for you. > > PK11_DoesMechanism() is called on a specific slot. > PK11_TokenExits() returns true of any token supports the mechanism. Thanks, this much nicer. We may not need it for this bug after all. > > don't worry about runtime checks in bltest, that needs to move to nss-softokn > anyway, so compile time checks are fine for now. Yes, bltest should move to nss-softokn. I actually did so, Bug 715402, but it's currently disabled on account of the current work. It can and should be done in a much cleaner fashion. Until that happens we need the sha224.patch. Revising your "hey, why do you need to make changes to libfreebl", Not only that but a lot of other stuff can be removed from the patch as well. The patching should be confined to blapitest and even that is strictly optional. Needed only so we can build a version that can be used to test against the old softoken until it the test moves where it belongs. Less is better. let me attach a new version.
Created attachment 545472 [details] Confine that no sha224 patching to blapitest
Hi, sorry for late response. I was stuck with different tasks. It seems that http://koji.fedoraproject.org/koji/taskinfo?taskID=3573487 does very good job for me :-). ldapsearch and user authentication works with our LDAP server. BTW: I had to create manually symlink: /etc/openldap/cecerts/9c472bf7.0 pointing to /etc/pki/tls/cert.pem anyway. May be, this could be created automatically during rpm install. Thanks, Jiri
(In reply to comment #65) Jiri, Thanks a lot for restesting. > http://koji.fedoraproject.org/koji/taskinfo?taskID=3573487 does very good job I'm glad you picked that build as it has very latest version of the patches.
I correct the earlier statement. The most up to date scratch build is http://koji.fedoraproject.org/koji/taskinfo?taskID=3577434 It has the reduced nosha224.path but is otherwise the same. The one you tested is fine as it already had the corrected patch to link libpem against system freebl. Otherwise, you test would have failed.
*** Bug 753931 has been marked as a duplicate of this bug. ***
Discussed at the 2012-01-27 blocker review meeting. This is a long complex bug and it's quite hard to understand. sgallagh proposed it as an F17 Alpha blocker back in November. Can anyone clarify the exact impact of this bug? Does it still make sense for it to block F17 Alpha? Has it actually now been fixed in Rawhide, as recent comments seem to suggest? Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug has long being fixed. The impact of the bug was only on systems that have nss at nss-3.13+ while keeping nss-softokn at 3.12. Such was the case on F-16 but only briefly. The investigation gave us a fix useful for RHEL 6 where it is actually needed. Since for Fedora (Rawhide/F-16/F-15) we have updated nss-softokn to be the same version as nss has, 3.13.1, that has fixed the problem.