| Summary: | Cannot establish SSL/TLS-connection to slapd | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Köller <thomas> | ||||||
| Component: | nss | Assignee: | Kai Engert (:kaie) (inactive account) <kengert> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 24 | CC: | dueno, emaldona, kdudka, kengert, mhonek, rmeggins | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-07-11 13:27:29 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
I see that ldapsearch attempts to load /etc/pki/tls/root_ca.pem And although loading that file seems to work with s_client, it apparently doesn't help ldapsearch. Can you please explain how you configured /etc/pki/tls/root_ca.pem so ldapsearch knows about it? Maybe you used a configuration that hasn't the intended effect? Also, it would be best if you could full copies of the involved certificates (without private keys), then we could try to check if something's wrong with them that NSS doesn't like. Created attachment 1219097 [details]
self-signed root ca certificate
Created attachment 1219098 [details]
server certificate
The root certificate is found via openldap configuration in $HOME/.ldaprc: [thomas@sarkovy ~]$ cat $HOME/.ldaprc BASE dc=koeller,dc=dyndns,dc=org URI ldapi://%2Frun%2Fldapi/ SASL_MECH external TLS_CACERT /etc/pki/tls/root_ca.pem Attached all certificates involved. Your CA configuration is incorrect. You have two different self-signed CA certificates that match the issuer name of the server cert. Your server sends out a CA with serial number 256. That certificate isn't trusted. The CA that you configured as trusted has serial number 0. When NSS attempts to verify the server cert, it searches for a potential issuer CA. The CA that your server sends is a match, so NSS stops searching for other ones. But the one that NSS found isn't trusted, therefore NSS concludes the server cert isn't trusted. From my point of view, it doesn't make sense that you have two separate CAs that both use identical issuer and subject. That's confusing the logic that attempts to find a trusted issuer. The CA with serial 256 seems unnecessary, I suggest you remove it everywhere. (In reply to Kai Engert (:kaie) from comment #5) > Your CA configuration is incorrect. > > You have two different self-signed CA certificates that match the issuer > name of the server cert. No, there is just one self-signed root CA. > Your server sends out a CA with serial number 256. > That certificate isn't trusted. That is because it is not a self-signed root CA, just an intermediate CA. > The CA that you configured as trusted has serial number 0. Correct. > When NSS attempts to verify the server cert, it searches for a potential > issuer CA. > > The CA that your server sends is a match, so NSS stops searching for other > ones. But the one that NSS found isn't trusted, therefore NSS concludes the > server cert isn't trusted. See above. The incomplete certificate chain sent by the server consists of an intermediate CA signed by the root CA, and the server certificate signed with the intermediate CA. If NSS really stops searching for a root CA after encountering the intermediate CA, I'd consider that a bug. > From my point of view, it doesn't make sense that you have two separate CAs > that both use identical issuer and subject. That's confusing the logic that > attempts to find a trusted issuer. > > The CA with serial 256 seems unnecessary, I suggest you remove it everywhere. That is not correct. The two certificates do not have identical subject fields, and only one of them is self-signed. Please have another look at the output from 'openssl s_client', the entire certificate chain is displayed nicely there. Ok, I'll doublecheck. Reopening, my comment 5 was incorrect, the subjects look very similar, and I had failed to see the difference earlier. I've unable to reproduce your failure. I used a similar setup, where a server has end entity and intermediate CA, and I used a self signed root CA, which I've added with TLS_CACERT to ~/.ldaprc It fails without the TLS_CACERT config, and once I add it, the connection works. The error code you're getting means that NSS is unable to find the issuer certificate. Did you say your exact same configuration worked with NSS 3.26? Some non-standard variables that I see in your environment are: entries in ldaprc: URI ldapi://%2Frun%2Fldapi/ SASL_MECH external I cannot tell if the use of the SASL_MECH has any influence here, if you can, please try to test without that. I don't know what effect the URI ldap configuration has. Your CAs contain a path length constraint. I've used certutil -V on your server certificate, and certutil is able to verify it, so that shouldn't be causing the problem. You could try to run the following commands. /usr/lib64/nss/unsupported-tools/tstclnt -V tls1.0: -D -h sarkovy.koeller.dyndns.org -p 636 -CC This command should fail with the same error as above, because it doesn't know about the server CA. The command should print the same CAs that you see with openssl. Next, you could try to prepare a test database that trusts your CA. mkdir /tmp/testdb certutil -d dbm:/tmp/testdb -N --empty-password certutil -d dbm:/tmp/testdb -A -n root_ca -t C,, -a -i /etc/pki/tls/root_ca.pem certutil -d dbm:/tmp/testdb -L /usr/lib64/nss/unsupported-tools/tstclnt -V tls1.0: -d dbm:/tmp/testdb -h sarkovy.koeller.dyndns.org -p 636 -CC If your CA in /etc/pki/tls/root_ca.pem is an correct issuer for the chain that your server sends, then tstclnt should be able to connect. What output does the above produce? Closing as insufficient data, because I cannot reproduce a failure, and there was no follow up with more information in 8 months. |
Cannot connect to slapd using the ldapsearch client if using SSL/TLS. Here is a transcript of a failed attempt to connect: --- [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. --- The file /etc/pki/tls/root_ca.pem contains a single self-signed root certificate, while the server certificate consist of two concatenated certificates. The three certificates together form a valid chain that is accepted by opensssl's s_client: --- [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: 05DE8564C26F7969DF8B5532DB57F64CB4E410725CA049014EAAE17829774AB6 Session-ID-ctx: Master-Key: 52AEC1F382FB1F978ED17D439887A5C12A110E96C0E4B7FBD88947D3A9BDD194A8CBE033F9C1F310C93F4CA957531E22 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1478641224 Timeout : 300 (sec) Verify return code: 0 (ok) --- Q DONE