Bug 842022 - slapd refuses to set up TLS with self-signed PEM certificate
slapd refuses to set up TLS with self-signed PEM certificate
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jan Vcelak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-20 18:13 EDT by Miloslav Trmač
Modified: 2013-03-03 20:30 EST (History)
4 users (show)

See Also:
Fixed In Version: openldap-2.4.31-7.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-09 19:20:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Tarball with configuration, keys etc. (12.09 KB, application/x-xz)
2012-07-20 18:13 EDT, Miloslav Trmač
no flags Details

  None (edit)
Description Miloslav Trmač 2012-07-20 18:13:45 EDT
Created attachment 599467 [details]
Tarball with configuration, keys etc.

To reproduce:
Try to rebuild libuser in Koji (tested f17 and f18 branches), e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=4284035 , https://koji.fedoraproject.org/koji/taskinfo?taskID=4283740 .

LDAP connection using TLS fails.

Note that this seems to happen only in mock, not on an installed F17 with the same version of openldap.


Additional information generated by enabling debugging:

> 5009d4ab daemon: epoll: listen=6 active_threads=0 tvp=NULL
> 5009d4ab send_ldap_extended: err=0 oid= len=0
> 5009d4ab send_ldap_response: msgid=1 tag=120 err=0
> ber_flush2: 14 bytes to sd 15
>   0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........    
> ldap_write: want=14, written=14
>   0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........    
> 5009d4ab daemon: activity on 1 descriptor
> 5009d4ab daemon: activity on:5009d4ab  15r5009d4ab 
> 5009d4ab daemon: read active on 15
> 5009d4ab daemon: epoll: listen=6 active_threads=0 tvp=NULL
> 5009d4ab connection_get(15)
> 5009d4ab connection_get(15): got connid=1002
> 5009d4ab connection_read(15): checking for input on id=1002
> TLS: certificate [CN=127.0.0.1] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
> TLS: error: unable to find and verify server's cert and key for certificate > CN=127.0.0.1
> TLS: error: could not initialize moznss security context - error -8172:Peer's certificate issuer has been marked as not trusted by the user.
> TLS: can't create ssl handle.
> 5009d4ab connection_read(15): TLS accept failure error=-1 id=1002, closing
> 5009d4ab connection_closing: readying conn=1002 sd=15 for close
> 5009d4ab connection_close: conn=1002 sd=15
> 5009d4ab daemon: activity on 1 descriptor

"peer's certificate issuer has been marked as not trusted" makes no sense to me:
1) the peer is a client, who does not supply any certificate
2) the certificate is in PEM format, which unlinke the NSS DB does not have any trust bits.

The second time the message is different, namely 
> TLS: error: could not initialize moznss security context - error -5925:The one-time function was previously called and failed. Its error code is no longer available
> TLS: can't create ssl handle.


More information to hopefully help reproducing this:
The server command is 
> /usr/sbin/slapd -h ldap://127.0.0.1:42883/ -f /builddir/build/BUILD/libuser-0.57.6/test_default_pw/slapd.conf -d 255
The client command is
> HOME=tests ldapsearch -d 255 -Z -h 127.0.0.1 -p 42883 -x -D cn=Manager,dc=libuser -w password -s sub -b 'dc=libuser'

with tests/ldaprc containing:
> HOST 127.0.0.1
> BASE dc=libuser
> # Don't check hostname on certificate
> TLS_REQCERT allow

I'll attach a tarball containing the test_default_pw directory (includes slapd.conf, the key, and the database)
Comment 1 Jan Vcelak 2012-07-20 19:35:13 EDT
> "peer's certificate issuer has been marked as not trusted" makes no sense to me:

This is implicit error message from Mozilla NSS when the certificate validation fails. It obviously doesn't differentiate between the sides of the connection.

> -8172:Peer's certificate issuer has been marked as not trusted by the user.

Looks like the recent changes introduced a problem with self-signed certificates. We ignore unknown cert issuer in the described situation. But in this case we in fact have the issuer certificate but it does not have appropriate trust flags.

I thought that setting the certificate as TLSCACertificateFile would solve it. But it didn't. I do not know why. I will take a look at it more deeply.

I suppose that your configuration did work with older OpenLDAP builds. Am I right?
Comment 2 Jan Vcelak 2012-07-21 12:02:25 EDT
Upstream report and patch submission:
http://www.openldap.org/its/index.cgi?findid=7331
Comment 3 Jan Vcelak 2012-07-21 13:13:24 EDT
Should be resolved in openldap-2.4.31-7.fc17
Comment 4 Fedora Update System 2012-07-21 13:14:58 EDT
openldap-2.4.31-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-10873/openldap-2.4.31-7.fc17
Comment 5 Fedora Update System 2012-07-21 18:50:27 EDT
Package openldap-2.4.31-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.31-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10873/openldap-2.4.31-7.fc17
then log in and leave karma (feedback).
Comment 6 Miloslav Trmač 2012-07-23 10:09:46 EDT
(In reply to comment #1)
> I suppose that your configuration did work with older OpenLDAP builds. Am I
> right?

Yes, it used to work.

And I confirm rawhide openldap-2.4.31-7.fc18 works again.  Thanks for the fast fix!
Comment 7 Fedora Update System 2012-08-09 19:20:19 EDT
openldap-2.4.31-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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