Bug 1383809 - NSS upgrade breaks openldap
Summary: NSS upgrade breaks openldap
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 24
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-11 19:59 UTC by Thomas Köller
Modified: 2017-07-26 10:18 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-07-26 10:18:41 UTC


Attachments (Terms of Use)
patch attempt v2 to disable RSA-PSS in NSS 3.27 (4.97 KB, patch)
2016-11-01 15:14 UTC, Kai Engert (:kaie) (inactive account)
rrelyea: review+
Details | Diff
attempted backport of upstream fix to NSS 3.27 (6.31 KB, patch)
2016-11-14 20:19 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 1311950 None None None 2019-06-12 20:28 UTC
Red Hat Bugzilla 1387380 None ASSIGNED [RFE] Support RSASSA-PSS 2019-06-12 20:28 UTC

Internal Trackers: 1387380

Description Thomas Köller 2016-10-11 19:59:42 UTC
Description of problem:
Upgrading nss-3.23.0-1.2.fc24 to nss-3.27.0-1.1.fc24 breaks openldap

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Thomas Köller 2016-10-11 20:07:37 UTC
After installing the said update, it is no longer possible to connect to slapd using TLS. This is very similar to a problem I reported earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1342745.

I do not actually intend to use NSS with slapd, instead, I am using OpenSSL-generated certificates stored as PEM files. However, the broken NSS library seems to prevent access to these.

Comment 2 Kai Engert (:kaie) (inactive account) 2016-10-12 15:37:25 UTC
I would be good to get help with debugging the cause of the breakage from openldap developers.

In particular, which functionality that openldap is using, breaks after the update?

Comment 3 Thomas Köller 2016-10-12 19:09:32 UTC
Slapd rejects all connections from clients using SSL/TLS.

Comment 4 Matus Honek 2016-10-13 13:26:00 UTC
$ ldapsearch -H ldaps://localhost:3636
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
        additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters.

slapd returns:
TLS: error: accept - force handshake failure: errno 107 - moznss error -8186
TLS: can't accept: TLS error -8186:security library: invalid algorithm..
57ff8167 connection_read(12): TLS accept failure error=-1 id=1004, closing

That's the issue, I presume. I guess it's some change in supported ciphers that introduced this - openldap has those hardcoded due to OpenSSL-like cipherstrings parsing. I'll try to sync them. Hopefully it helps.

FTR: The upstream won't be helpful here as it is an NSS-related stuff.

Comment 5 Kai Engert (:kaie) (inactive account) 2016-10-18 15:37:22 UTC
Is this possibly about an old export cipher, then the regression is expected.

Comment 6 Leendert van Doorn 2016-10-18 22:54:21 UTC
I'm seeing exactly the same problem, all LDAP clients on Fedora core broke. I compiled openldap with the default compile settings and its clients work.

Comment 7 Leendert van Doorn 2016-10-19 06:22:50 UTC
I just checked my certificate (it goes back a while). It does use sha1WithRSAEncryption and rsaEncryption with a 4096 bit key. sha1WithRSAEncryption is phased out on jan 1st, 2017. Is that what we are hitting here?

Comment 8 Thomas Köller 2016-10-19 07:04:35 UTC
I'd like to emphasize again that I have no NSS certificate data base at all, just plain PEM files generated by OpenSSL. My understanding is (and this is how it is documented and used to work), that slpad falls back to using these in the absence of a NSS data base. But even this use case is broken now. I'd therefore conclude that the breakage cannot be related to any certificate features.

Comment 9 Hubert Kario 2016-10-19 16:09:56 UTC
It looks like a problem with the newly introduced RSA-PSS signatures. The TLS connections work fine from OpenSSL but fail if the client is also using NSS library, that is because NSS advertises RSA-PSS signature method and NSS server will use it if available.

that being said, I can't reproduce it with selfserv, only with slapd

Comment 10 Hubert Kario 2016-10-19 17:14:19 UTC
Thomas, can you try configuring the server with nssdb for key and certificate storage? That should workaround the issue.

Comment 11 Thomas Köller 2016-10-20 06:35:00 UTC
(In reply to Hubert Kario from comment #9)
> It looks like a problem with the newly introduced RSA-PSS signatures. The
> TLS connections work fine from OpenSSL but fail if the client is also using
> NSS library, that is because NSS advertises RSA-PSS signature method and NSS
> server will use it if available.
> 
> that being said, I can't reproduce it with selfserv, only with slapd

No, my clients are all using OpenSSL.

Comment 12 Thomas Köller 2016-10-20 06:37:01 UTC
(In reply to Hubert Kario from comment #10)
> Thomas, can you try configuring the server with nssdb for key and
> certificate storage? That should workaround the issue.

This would take a couple of days, as I am rather busy right now.

Comment 13 Hubert Kario 2016-10-20 11:33:42 UTC
(In reply to Thomas Köller from comment #11)
> (In reply to Hubert Kario from comment #9)
> > It looks like a problem with the newly introduced RSA-PSS signatures. The
> > TLS connections work fine from OpenSSL but fail if the client is also using
> > NSS library, that is because NSS advertises RSA-PSS signature method and NSS
> > server will use it if available.
> > 
> > that being said, I can't reproduce it with selfserv, only with slapd
> 
> No, my clients are all using OpenSSL.

which version of OpenSSL? are you sure the server never processes a request from a client that uses new NSS before, for example, over loopback?

(In reply to Thomas Köller from comment #12)
> (In reply to Hubert Kario from comment #10)
> > Thomas, can you try configuring the server with nssdb for key and
> > certificate storage? That should workaround the issue.
> 
> This would take a couple of days, as I am rather busy right now.

If the issue is what Kai and I think it is, fixing it will require a lot of work so a fix likely won't be available quickly either, sorry.

Comment 14 Kai Engert (:kaie) (inactive account) 2016-10-20 14:28:03 UTC
Could we produce a NSS package update, that disables the use of RSA-PSS signatures with SSL/TLS completely, while we work on a smarter implementation?

Comment 15 Leendert van Doorn 2016-10-24 05:17:07 UTC
Any update on a work around?

Comment 16 Kamil Dudka 2016-10-24 05:48:51 UTC
(In reply to Leendert van Doorn from comment #15)
> Any update on a work around?

Have you tried the workaround suggested in comment #10?

Comment 17 Fabrice Bellet 2016-10-24 10:46:39 UTC
As suggested in comment #10, I switched to nssdb instead of individual TLS cert files, and it works for me (Fedora 23, openldap-servers-2.4.40-14.fc23.x86_64 and nss-3.27.0-1.1.fc23.x86_64). The problem has been introduced in nss-3.27.0, and downgrading to 3.26.0 makes it work back with TLS certs.

Comment 18 Leendert van Doorn 2016-10-24 18:22:45 UTC
I'm running fc24 and I can only find nss-3.23.0 and the system is very unhappy to downgrade to that.

Comment 19 Fabrice Bellet 2016-10-25 07:53:47 UTC
You can get other builds here : http://koji.fedoraproject.org/koji/packageinfo?packageID=248

Comment 20 Kai Engert (:kaie) (inactive account) 2016-11-01 15:14 UTC
Created attachment 1216147 [details]
patch attempt v2 to disable RSA-PSS in NSS 3.27

The following upstream patches have originally added support for RSA-PSS signatures:
https://hg.mozilla.org/projects/nss/rev/10b045de68e6
https://hg.mozilla.org/projects/nss/rev/71987d6f797f
https://hg.mozilla.org/projects/nss/rev/ab21f845dbf9

While we're waiting for an upstream fix in https://bugzilla.mozilla.org/show_bug.cgi?id=1311950
here is patch (attached) for NSS 3.27 that attempts to disable the use of RSA-PSS signature completely.

I created a scratch/test build that uses the attached patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=16260879

Could someone please test if that build fixes the bug, and NSS still works correctly? (The NSS test suite passes with this patch.)

Comment 21 Kai Engert (:kaie) (inactive account) 2016-11-01 15:20:29 UTC
Comment on attachment 1216147 [details]
patch attempt v2 to disable RSA-PSS in NSS 3.27

Bob, does this make sense?

Tim said, the patch might disable more than necessary, but it passes the NSS test suite.

Comment 22 Mark LaCroix 2016-11-02 12:37:55 UTC
I can provide one confirmation that the scratch build worked. Showing client/server versions for nss package. Omitting nss-sysinit and nss-tools package versions because they mirror nss package version.

-----------

Before test
  Server: nss-3.27.0-1.1.fc23.x86_64
  Client: nss-3.27.0-1.1.fc23.x86_64

[client] $ ldapsearch -D <snipped> -Z -W -x -d8
TLS: error: connect - force handshake failure: errno 0 - moznss error -12227
TLS: can't connect: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters..
ldap_start_tls: Connect error (-11)
        additional info: TLS error -12227:SSL peer was unable to negotiate an acceptable set of security parameters.
Enter LDAP Password:
ber_get_next failed.
ldap_result: Can't contact LDAP server (-1)

----------

After test
  Server: nss-3.27.0-1.1.0.test.2.fc24.x86_64
  Client: nss-3.27.0-1.1.fc23.x86_64

[client] $ ldapsearch -D <snipped> -Z -W -x -d8
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
<snipped results>

Comment 23 Kai Engert (:kaie) (inactive account) 2016-11-02 12:56:11 UTC
Mark, thanks a lot.

I think I should go ahead and create official builds for fedora testing with this change, so we can get broader feedback for potential regressions.

Comment 24 Fedora Update System 2016-11-02 16:42:56 UTC
nss-3.27.0-1.2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0de70c5c1

Comment 25 Fedora Update System 2016-11-02 16:43:12 UTC
nss-3.27.0-1.2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e49d6409c7

Comment 26 Fedora Update System 2016-11-02 16:43:22 UTC
nss-3.27.0-1.2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-456ead2c2e

Comment 27 Bob Relyea 2016-11-03 17:40:57 UTC
Comment on attachment 1216147 [details]
patch attempt v2 to disable RSA-PSS in NSS 3.27

r+ rrelyea.

Tim is working on a more friendly fix upstream, but this allows us to update NSS as is.

bob

Comment 28 Fedora Update System 2016-11-05 03:32:54 UTC
nss-3.27.0-1.2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d0de70c5c1

Comment 29 Fedora Update System 2016-11-05 03:51:05 UTC
nss-3.27.0-1.2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-456ead2c2e

Comment 30 Fedora Update System 2016-11-05 18:56:57 UTC
nss-3.27.0-1.2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e49d6409c7

Comment 31 Fedora Update System 2016-11-06 01:52:34 UTC
nss-3.27.0-1.2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-456ead2c2e

Comment 32 Thomas Köller 2016-11-06 20:28:43 UTC
Even after installing nss-3.27.0-1.2.fc24, I am still encountering problems:

[thomas@sarkovy ~]$ ldapsearch -H ldaps://sarkovy.koeller.dyndns.org:636 -Y plain -d 1
ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636)
ldap_create
ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636/??base)
ldap_sasl_interactive_bind: user selected: plain
ldap_int_sasl_bind: plain
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP sarkovy.koeller.dyndns.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: loaded CA certificate file /etc/pki/tls/root_ca.pem.
TLS: could not set cipher list TLSv1.2.
TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication.
TLS: can't create ssl handle.
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

Comment 33 Hubert Kario 2016-11-07 11:28:00 UTC
(In reply to Thomas Köller from comment #32)
> TLS: could not set cipher list TLSv1.2.

That is not a connection error, that looks like a configuration error to me

Comment 34 Matus Honek 2016-11-07 12:01:18 UTC
> TLS: could not set cipher list TLSv1.2.
This seems to be more of a bug 1375432 and/or bug 1387868 issue. Those should be fixed soon.

> TLS: error: could not initialize moznss security context - error -12285:Unable to find the certificate or key necessary for authentication.
This looks like an incorrect user cert/key configuration (but might be misleading due to the bugs I mentioned above).

Comment 35 Kai Engert (:kaie) (inactive account) 2016-11-07 13:12:12 UTC
Hubert, Matus, thanks for analysing the feedback from comment 32.

In the meantime, we've received 9 positive karma points on the f24 update.
(and two each for f25 and f23).

It seems we can risk pushing this update to stable.

Comment 36 Fedora Update System 2016-11-07 23:26:02 UTC
nss-3.27.0-1.2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 37 Thomas Köller 2016-11-07 23:43:10 UTC
(In reply to Hubert Kario from comment #33)
> (In reply to Thomas Köller from comment #32)
> > TLS: could not set cipher list TLSv1.2.
> 
> That is not a connection error, that looks like a configuration error to me

I had that setting in my ldap.conf, but removing it did not help:

---
[thomas@sarkovy ~]$ ldapsearch -H ldaps://sarkovy.koeller.dyndns.org:636 -Y plain -d 1
ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636)
ldap_create
ldap_url_parse_ext(ldaps://sarkovy.koeller.dyndns.org:636/??base)
ldap_sasl_interactive_bind: user selected: plain
ldap_int_sasl_bind: plain
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP sarkovy.koeller.dyndns.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: loaded CA certificate file /etc/pki/tls/root_ca.pem.
TLS: certificate [CN=Köller Family Host Signing Certificate,OU=Network Administration,O=Köller Family,L=Hamburg,ST=Hamburg,C=DE] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8179
TLS: can't connect: TLS error -8179:Peer's Certificate issuer is not recognized..
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
	additional info: TLS error -8179:Peer's Certificate issuer is not recognized.
---

Using 'opensssl s_client', I can connect without problems:

---
[thomas@sarkovy ~]$ openssl s_client -connect 127.0.0.1:ldaps -CAfile /etc/pki/tls/root_ca.pem -verify 3
verify depth is 3
CONNECTED(00000003)
depth=2 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = K\C3\B6ller Family Root Signing Certificate
verify return:1
depth=1 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = K\C3\B6ller Family Host Signing Certificate
verify return:1
depth=0 C = DE, ST = Hamburg, L = Hamburg, O = K\C3\B6ller Family, OU = Network Administration, CN = sarkovy.koeller.dyndns.org
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=sarkovy.koeller.dyndns.org
   i:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate
 1 s:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate
   i:/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Root Signing Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGfzCCBGcCAgECMA0GCSqGSIb3DQEBBQUAMIGdMQswCQYDVQQGEwJERTEQMA4G
A1UECAwHSGFtYnVyZzEQMA4GA1UEBwwHSGFtYnVyZzEXMBUGA1UECgwOS8O2bGxl
ciBGYW1pbHkxHzAdBgNVBAsMFk5ldHdvcmsgQWRtaW5pc3RyYXRpb24xMDAuBgNV
BAMMJ0vDtmxsZXIgRmFtaWx5IEhvc3QgU2lnbmluZyBDZXJ0aWZpY2F0ZTAgFw0x
NjAyMTIxMTQzMjFaGA8yMDYwMDYwNjIzNTk1OVowgZAxCzAJBgNVBAYTAkRFMRAw
DgYDVQQIDAdIYW1idXJnMRAwDgYDVQQHDAdIYW1idXJnMRcwFQYDVQQKDA5Lw7Zs
bGVyIEZhbWlseTEfMB0GA1UECwwWTmV0d29yayBBZG1pbmlzdHJhdGlvbjEjMCEG
A1UEAwwac2Fya292eS5rb2VsbGVyLmR5bmRucy5vcmcwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCu64YqsBJ8KNlrMTwJewgZB+XKaBNRQPetOEmjzyTz
U0MXwpJwzEZ9bAi4nTzaJ2YY/o898CKTf/x7UUxKiU3rb4Mzfmawkh4qhXn++2Cm
H6+oTYRB6rU90VEyuGbyJElG/tpICX/145pVCh0M/MB2+/ZvGxh8CoaGSOYOHVpX
MqhKlovnNO8YMopDuT8sOLsMYZqcC++nqXNFxHeNyZoXapoJl/pxywIgv5TJJsm0
kA7LmpHK1lS7aepT0i/D1ONmsTIgmBG6BsE39IJlSf+pV62RsZ3hu9Ryo3q+ua0p
SGuAnmZ2FSBqr17O+Z4pISr94uzCME2lxzwWTNdmiDMwy/HBNX94gLm85ww+K4qq
5AEO9n1vfjZGm4WeZC/0+66IYR8IdqTC+/OdczFm3YaYptU5x/rrZrNtQIgsDpEs
nr6XgPED3ZKBq/5HiLN5tAf1NZbifMBVjsuUc8Dom99jpnWn94BSfmGHBOhLJrmd
ujggP+Jr8qNClGh08rowJWoJnVZHlM2hemGLCIoCX4+8eu4hgiuRYXLEHLBJbtRH
o7f1597FRO0iJgne7l9StpufiS5PSWd6s7FGEVJ3tb02GR9mlySAoqQ96XT/uNfm
0MJenxgsP62T7cvIu70u6MlF9R0kk+y9xkzLQz6GQ9xR0H/Z23vxokV4BRrZrIun
CwIDAQABo4HWMIHTMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgQwMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjB+BgNVHREEdzB1hwTAqAABhwTAqAEBhwTA
qAIBghdkaGNwLmtvZWxsZXIuZHluZG5zLm9yZ4IWZG5zLmtvZWxsZXIuZHluZG5z
Lm9yZ4IXbWFpbC5rb2VsbGVyLmR5bmRucy5vcmeCF2xkYXAua29lbGxlci5keW5k
bnMub3JnMBcGA1UdHgQQMA6gDDAKhwjAqAAA//8AADANBgkqhkiG9w0BAQUFAAOC
AgEAfbAn/YoOFrrlph1vFOGT5lyTeclbT6DzzNgD8Y2cSOOcQBYWfQRZPBn5eUYp
FNPiC/kq3rfWSg9122dnYsJ60YVLWSj3WqYeX12ek6S5S/DWGWJmVpLNf9vsjML3
YzjaAZYOQomkQFMRdWp2y7gkiAS+yjOny6LPm2zU4AlXE/fKDtgmsFxg3lAnz9DZ
fpJZKxzgUUyjJaO8Z6NjlYf6tgInLWiEjEvyVLxkK2VywrUlvGLDTUJxmsJa7oYi
QCvPLK7xW2j0H4H3DK+czSrriJfbEYbs3yEA5guIgdisCIvY6I2wI2E6eUxeWv0H
NUxz/tTsyG4SxHFR8cmdfPftUr5CH1ZtTi+7j0p/cwV03Mb7Lf4CZOntfDgdDQ1i
TayvZCo6d1xsuSKYvuKRK8KXGnw6wHYhxuF2UG+J9fRoGu/S0rVucWJZUSt94ZFH
+m5FccArgBhDOMv70lW+bKhYK57K4oByABN7+vk4J9T1qgu+8mBiA802RCVFIqUi
2x2SIOr1c+zjtuNaXGfkj1UTCgBXXqTxzWfo+6PO4OkJcIqtZZsEy3xmIBVonrSK
+ILz8IfQRt6NYrpGruleEEwOeHIeKCCk9NuNKfQ3CZEbZIseyWNTF7GCQFTG33Mz
GxDRz0xUe4gNVawwC+voOuThKqHf6B3sQ+bsVelusNGTAXg=
-----END CERTIFICATE-----
subject=/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=sarkovy.koeller.dyndns.org
issuer=/C=DE/ST=Hamburg/L=Hamburg/O=K\xC3\xB6ller Family/OU=Network Administration/CN=K\xC3\xB6ller Family Host Signing Certificate
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3948 bytes and written 351 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: 05DE5F07B11BF607E242013D1FFE2A80C2F0B814E19380F0F1C42086790F1590
    Session-ID-ctx: 
    Master-Key: DE5EECC6E5EFA4BA8BB630FF724E6E6152ADB5102A4E19DD75ACD4D69D083F572D082294BA73216303351094EEAF88D1
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1478561956
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

So, I'd conclude it is a nss issue.

Comment 38 Kai Engert (:kaie) (inactive account) 2016-11-08 10:43:33 UTC
Thomas, it's a different issue.

Your ldap server uses a certificate that was issued by your own CA. When you connect using openssl, you're telling it to trust your own CA, which you apparently have installed at /etc/pki/tls/root_ca.pem (and openssl wouldn't trust the server cert without that option).

Although the ldapsearch command also appears to load that root CA certificate, it decides it isn't trustworth. The error messages clearly state that the connection is refused, because of certificate validation failures.

If you believe that this is a problem with openldap/NSS, please let's keep this bug clear of this separate issue, and please file a separate bug (and cc me and Matus).

Comment 39 Fedora Update System 2016-11-08 22:53:19 UTC
nss-3.27.0-1.2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 40 Flo 2016-11-09 08:54:44 UTC
Even after installing nss-3.27.0-1.2.fc23 I'm running into problems.

Not all "clients" are able to connect.
- sssd is able to connect via port 636
- php is not able to connect (still a tls negotiation error occurs)

Comment 41 Flo 2016-11-09 09:53:42 UTC
Please ignore my previous comment. It was a configuration issue (missmatch between certificate and the configured CA certificate for validation)

Comment 42 Kai Engert (:kaie) (inactive account) 2016-11-14 20:19:15 UTC
The bug has apparently been fixed upstream, for NSS 3.28

It will be another 4 weeks, until we'll have a stable version of NSS 3.28 that we could test with Fedora.

Should we try to test this earlier, by proving NSS 3.27 builds with a backported patch?

Comment 43 Kai Engert (:kaie) (inactive account) 2016-11-14 20:19 UTC
Created attachment 1220527 [details]
attempted backport of upstream fix to NSS 3.27

Comment 44 Fedora Update System 2016-11-16 08:15:35 UTC
nss-3.27.0-1.3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-03d76071b6

Comment 45 Fedora Update System 2016-11-16 08:15:53 UTC
nss-3.27.0-1.3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-56cfdb6815

Comment 46 Fedora Update System 2016-11-16 08:16:04 UTC
nss-3.27.0-1.3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383

Comment 47 Kai Engert (:kaie) (inactive account) 2016-11-16 15:04:11 UTC
Everyone who was affected by this bug:

Could you please repeat your testing with the most recent packages (which contains the better fix mentioned in comment 42), and test if everything still works for you? Thanks in advance.

See comments 44, 45 and 46 for the newer package versions.

Comment 48 Fedora Update System 2016-11-16 20:25:43 UTC
nss-3.27.0-1.3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-56cfdb6815

Comment 49 Fedora Update System 2016-11-17 03:53:06 UTC
nss-3.27.0-1.3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-03d76071b6

Comment 50 Fedora Update System 2016-11-17 03:57:37 UTC
nss-3.27.0-1.3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383

Comment 51 Jason Tibbitts 2016-11-17 22:37:50 UTC
I installed the -1.3 package (which, BTW, doesn't follow the Fedora versioning guidelines) on an F24 ldap slave server and restarted slapd.  Everything seems fine so far.  I'm not sure how to really exercise it but I can talk to it via ldaps which I couldn't do when the -1.1 package came out.

Comment 52 Fedora Update System 2016-11-19 21:08:52 UTC
nss-3.27.0-1.2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 53 Fedora Update System 2016-12-22 05:22:57 UTC
nss-3.27.0-1.3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 54 Fedora Update System 2017-01-13 15:54:06 UTC
nss-3.28.1-1.1.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18

Comment 55 Daiki Ueno 2017-01-13 15:59:19 UTC
Please ignore comment 54, I mistakenly attached this bug to the update.

Comment 56 Fedora Update System 2017-01-16 08:20:10 UTC
nss-3.27.0-1.3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383

Comment 57 Fedora Update System 2017-01-16 22:21:59 UTC
nss-3.27.0-1.3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-cddf0ec383

Comment 58 Fedora Update System 2017-01-18 09:50:53 UTC
firefox-50.1.0-3.fc24 nss-3.28.1-1.2.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18

Comment 59 Fedora Update System 2017-01-19 07:22:16 UTC
firefox-50.1.0-3.fc24, nss-3.28.1-1.2.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18

Comment 60 Fedora Update System 2017-01-21 11:52:12 UTC
firefox-50.1.0-3.fc24 icecat-45.5.1-6.fc24 nss-3.28.1-1.3.fc24 nss-softokn-3.28.1-1.0.fc24 nss-util-3.28.1-1.0.fc24 seamonkey-2.46-3.fc24 thunderbird-45.6.0-5.fc24 xulrunner-44.0-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18

Comment 61 Fedora Update System 2017-01-21 21:52:06 UTC
firefox-50.1.0-3.fc24, icecat-45.5.1-6.fc24, nss-3.28.1-1.3.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24, seamonkey-2.46-3.fc24, thunderbird-45.6.0-5.fc24, xulrunner-44.0-9.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bbb320ba18

Comment 62 Fedora Update System 2017-01-24 03:48:09 UTC
firefox-50.1.0-3.fc24, icecat-45.5.1-6.fc24, nss-3.28.1-1.3.fc24, nss-softokn-3.28.1-1.0.fc24, nss-util-3.28.1-1.0.fc24, seamonkey-2.46-3.fc24, thunderbird-45.6.0-5.fc24, xulrunner-44.0-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 63 Fedora End Of Life 2017-07-25 23:26:01 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 64 Daiki Ueno 2017-07-26 10:18:41 UTC
Closing this, as the fix shipped 6 months ago.


Note You need to log in before you can comment on or make changes to this bug.