November 2016 - openldap-bugs

(ITS#8535) ITS4337 regression test failure

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The regression test for ITS4337 currently fails due to a bad script and bad configuration file. Fix incoming.

6 years, 3 months

1
0
0 / 0

(ITS#8534) ITS4336 regression test failure

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The regression test for ITS4336 fails due to an incorrect configuration file. Fix incoming.

6 years, 3 months

1
0
0 / 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d

by quanah＠symas.com

--On Friday, October 21, 2016 11:02 PM +0000 elecharny(a)gmail.com wrote: > o Step 3 : On the consumer, we inject the following entry : > ># Context entry > dn: dc=3Dexample,dc=3Dcom > changetype: add > objectClass: domain > objectClass: top > dc: example This step is not valid. The consumer should have no pre-existing data that differs from the provider's database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 3 months

1
0
0 / 0

Re: (ITS#8533) Support OpenSSL-1.1.0c

by quanah＠symas.com

--On Saturday, November 26, 2016 10:50 PM +0000 sca(a)andreasschulze.de wrote: > But I personally need pkg-config because my openssl library is named > libssl-dv / libcrypto-dv > to coexist with the distribution versions. Viktor Dukhovni told me to > build openssl-1.1 that way > and beside the requirement for pkg-config I'm personally fine with > that advise :-) > > should I prepare the new patch to fit your needs? > otherwise I would be fine if you modify the contribution to your needs. > > Anyway: after I wrote the patch for git-master it was very easy to > create a patch to compile also 2.4.44 with openssl-1.1 > I could publish that also next week. Do you think that makes sense? Hi Andreas, Thanks for looking into this. I have a few additional comments: a) "configure.in" should be patched rather than "configure", and then I'd verify that regenerating configure works appropriately. b) A coding style issue found throughout the patch, where you are using NULL == variable rather than variable == NULL. This should be fixed. For example, you have: if ( NULL == tlso_bio_method ) { this instead should be: if ( tlso_bio_method == NULL ) { Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 3 months

1
0
0 / 0

Re: (ITS#8533) Support OpenSSL-1.1.0c

by sca＠andreasschulze.de

Howard Chu: > Patches should be relative to git master. There is no 2.4.45. right, I wrongly named the git master 2.4.45 - my fault but in fact it's git master... > Don't use pkg-config. Not all systems support it. I know only linux, sorry. Again: your right, support for openssl-1.1 don't require pkg-config. But I personally need pkg-config because my openssl library is named libssl-dv / libcrypto-dv to coexist with the distribution versions. Viktor Dukhovni told me to build openssl-1.1 that way and beside the requirement for pkg-config I'm personally fine with that advise :-) should I prepare the new patch to fit your needs? otherwise I would be fine if you modify the contribution to your needs. Anyway: after I wrote the patch for git-master it was very easy to create a patch to compile also 2.4.44 with openssl-1.1 I could publish that also next week. Do you think that makes sense? Thanks, Andreas

6 years, 3 months

1
0
0 / 0

Re: (ITS#8533) Support OpenSSL-1.1.0c

by hyc＠symas.com

sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45~git Patches should be relative to git master. There is no 2.4.45. > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > while http://www.openldap.org/its/index.cgi/Development?id=8353 > end with "work with openssl-1.1" I checked out openldap from git in november > 2016 > and found it does not compile. So I write the patch. > > it solve the following challenges: > - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl > - configure use pkg-config to find the names of libssl and libcrypto Don't use pkg-config. Not all systems support it. > - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced > by openssl-1.1.0 > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 years, 3 months

1
0
0 / 0

(ITS#8533) Support OpenSSL-1.1.0c

by sca+openldap＠andreasschulze.de

Full_Name: Andreas Schulze Version: 2.4.45~git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) while http://www.openldap.org/its/index.cgi/Development?id=8353 end with "work with openssl-1.1" I checked out openldap from git in november 2016 and found it does not compile. So I write the patch. it solve the following challenges: - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl - configure use pkg-config to find the names of libssl and libcrypto - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced by openssl-1.1.0

6 years, 3 months

1
0
0 / 0

Re: (ITS#8531) Segfault in servers/slapd/back-sql/search.c

by quanah＠symas.com

--On Thursday, November 17, 2016 3:47 PM +0000 winkelmann(a)hornetsecurity.com wrote: > Full_Name: Guido Winkelmann > Version: 2.4.44 > OS: Gentoo Linux > URL: > Submission from: (NULL) (80.146.184.86) > > > Hi, > > I have been trying to set up OpenLDAP to serve some data from a MySQL > database using back_sql. I have gotten to the point where it should show > the base object of its tree, but when I try to query it using Hello Guido, As noted in the slapd-sql(5) man page the backend is entirely experimental and one uses it at their own risk. There is not, to my knowledge, any current maintainer for the backend at this time. Patches welcome. If you do decide to pursue a patch, please be sure and read over: <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 4 months

1
0
0 / 0

Re: (ITS#8532) Blank subject name results in failed SSLHandshake

by quanah＠symas.com

--On Monday, November 21, 2016 8:50 PM +0000 graham.wells(a)gmail.com wrote: > Full_Name: Graham Wells > Version: 2.4.28 > OS: macOS 10.12.1 > URL: > Submission from: (NULL) (50.207.27.182) Hi Graham, Thanks for the report. However, Apple builds of OpenLDAP have hacked in support for a custom TLS library called Secure Transport. Use of this TLS library is not supported by the OpenLDAP project, thus we cannot address this problem. You will need to contact Apple for help with this problem. Hope that helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 4 months

1
0
0 / 0

(ITS#8532) Blank subject name results in failed SSLHandshake

by graham.wells＠gmail.com

Full_Name: Graham Wells Version: 2.4.28 OS: macOS 10.12.1 URL: Submission from: (NULL) (50.207.27.182) SSLHandshake fails for ldapsearch when the subject is blank, even if the certificate is valid and certificate chain trusted (should only require a valid SAN and for SAN to be marked as critical): Command: /usr/bin/ldapsearch -b "CN=userid,ou=foo,ou=bar,dc=domain,dc=com" -D "CN=bind-dn,ou=foo,ou=bar,dc=domain,dc=com" -H ldaps://server-ldap.com:636 -W -d-1 ldap_url_parse_ext(ldaps://server-ldap.com:636) ldap_create ldap_url_parse_ext(ldaps://server-ldap.com:636/??base) Enter LDAP Password:AlAldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-ldap.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.2.2.2:636 ldap_pvt_connect: fd: 3 tm: -1 async:%D tlsst_thr_init() tlsst_init() tlsst_ctx_new() = 0x7fa10de02f90 tlsst_ctx_init(0x7fa10de02f90) tlsst_ciphers_get((null), TLS_CIPHER_SUITE) tlsst_trusted_certs_get(CA 002|CA 001|CA 003|ROOT CA 001|Other Root CA, TLS_TRUSTED_CERTS) tlssttetem_get(CA 002, TLS_TRUSTED_CERTS) tlsst_item_get(CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(CA 003, TLS_TRUSTED_CERTS) tlsst_item_get(ROOT CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(Other Root CA, TLS_TRUSTED_CERTS) tlsst_session_new(0x7fa10de02f90) tlsst_ciphers_set(42, TLS_CIPHER_SUITE) TLS: 42 ciphers wanted: ...(omitted) TLS: 72 ciphers supported: ...(omitted) TLS: 16 ciphers enabled ...(omitted) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_new(0x7fa10de02f90) = 0x7fa10dd08280 tlsst_sb_setup(0x7fa10dd08280) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_connect(0x7fa10dd08280) tlsst_session_handshake() tlsst_socket_write(0x7fa10dd0ef68, 123) tls_write: want=123, written=123 0000: 16 03 01 00 76 01 00 00 72 03 03 58 33 55 fe 4e ....v...r..X3U.N 0010: 8e 16 0d df 99 3a e6 68 36 a1 ff 90 71 1f 78 bb .....:.h6...q.x. 0020: 70 bf 2a 02 05 44 c9 94 07 33 2f 00 00 22 00 ff p.*..D...3/..".. 0030: 00 9d 00 9f 00 3d 00 6b 00 35 00 39 00 9c 00 9e .....=.k.5.9.... 0040: 00 3c 00 67 00 2f 00 33 00 0a 00 16 00 05 00 04 .<.g./.3........ 0050: 01 00 00 27 00 0d 00 12 00 10 04 01 02 01 05 01 ...'............ 0060: 06 01 04 03 02 03 05 03 06 03 00 05 00 05 01 00 ................ 0070: 00 00 00 00 12 00 00 00 17 00 00 ........... tlsst_socket_read(0x7fa10e81d800, 5) tls_read: want=5, got=5 0000: 16 03 03 11 38 ....8 tlsst_socket_read(0x7fa10e81d805, 4408) tls_read: want=0808, got=2891 ...(sanitized) tlsst_socket_read - received (2891) bytes of (4408) requested bytes - (1517) encrypted bytes remaining tlsst_socket_flags sess(0x7fa10dd08280) tlsst_socket_flags ->(2) tlsst_socket_read(0x7fa10e81e350, 1517) tls_read: want=1517, got=1517 ...(sanitized) TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure tlsst_session_upflags(0x7fa10dd08280) tlsst_session_errmsg(0x7fa10dd08280) TLS: can't connect: SSLHandshake() failed: misc. bad certificate (-9825). tlsst_sb_remove(0x7fa10dd08280) tlsst_session_free(0x7fa10dd08280) tlsst_ctx_free(0x7fa10de02f90) ldap_err2string ldap_sasl_bind(SIMPLE): Can7t7t contact LDAP server (-1) ldap_pvt_clear_search_results_callback: ld 0x7fa10dd00ab0 ldap_pvt_close_select_pipe: sip = 0x7fa10e803800 tlsst_ctx_free(0x7fa10de02f90) tlsst_ctx_free(0x7fa10de02f90) tlsst_destroy() Certificate is otherwise valid: Certificate: Data: Version: 3 (0x2) Serial Number: (redacted) Signature Algorithm: sha256WithRSAEncryption Issuer: DC=foo, DC=bar, CN=CA 003 Validity Not Before: Oct 25 23:33:16 2016 GMT Not After : Oct 25 23:33:16 2017 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): (redacted) Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.7: 0-.%+.....7....`...W......./....W...b......d... X509v3 Extended Key Usage: 1.3.6.1.5.2.3.5, Microsoft Smartcardlogin, TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment 1.3.6.1.4.1.311.21.10: 010...+......0.. +.....7...0 ..+.......0 ..+....... X509v3 Subject Key Identifier: E2:D2:D9:24:6D:A6:5A:2D:59:03:08:38:03:AE:E8:F4:2A:EA:EB:9F X509v3 Authority Key Identifier: keyid:16:70:AA:1C:31:53:76:FB:26:B5:B8:EA:FC:76:08:E6:3F:17:0D:2F X509v3 CRL Distribution Points: URI:http://foo.bar.com/CertData/CA 003.crl URI:ldap:///CN=CA 003,CN=server-ldap,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=co3F3FcertificateRevocationList?base?objectClass=cRLDistributionPoint Authority Information Access: CA Issuers - URI:http://foo.bar.com/CertData/server-ldap_CA-003.crt CA Issuers - URI:ldap:///CN=CA 003,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=com?cACertificate?base?objectClass=certificationAuthority X509v3 Subject Alternative Name: critical DNS:server-ldap.com, DNS:domain.com, DNS:DOMAIN Signature Algorithm: sha256WithRSAEncryption (redacted) The certificate is RFC5280 compliant despite having a blank subject name, specifically: "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." Reissuing the certificate and populating the subject field resolves the issue, but it should not be necessary according to the RFC.

6 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2016