openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by quanah＠symas.com 10 May '19

10 May '19

--On Friday, May 10, 2019 9:32 PM +0000 darshan mistry <darshankmistry(a)yahoo.com> wrote: > how we can ignore to look server name in subject of certificate so I can > use LDAP server ip address instead of host name? If you want to allow connecting over the IP address with TLS, then add it as a subjectAltName value in the certificate, for example: subjectAltName=IP:1.2.3.4 > Also want to know if there is any open CVE which says it is > vulnerabilities to use LDAP server ip address instead of name in ldap > configuration. I'm not aware of any such CVE or why there would be one. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by darshankmistry＠yahoo.com 10 May '19

10 May '19

------=_Part_545863_1662769086.1557520342175 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable thank you very much for quick response and openldap behavior configuration.= =C2=A0 how we can ignore to look server name in subject of certificate so I can us= e LDAP server ip address instead of host name?=C2=A0 Also want to know if there is any open CVE which says it is vulnerabilities= to use LDAP server ip address instead of name in ldap configuration.=C2=A0 Thank you, Darshankumar Mistry darshankmistry(a)yahoo.com =20 On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson-Mount <quanah@s= ymas.com> wrote: =20 =20 --On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wrote: > Full_Name: Darshankumar Mistry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) > > > I would like to know why Open LDAP behavior was changed where we must > have to configure FQDN name mentioned in certificate in order to work LDA= P > authentication... else TLS start failing. OpenLDAP has worked this way since I first started using it in 2002.=C2=A0 = This=20 behavior is nothing new.=C2=A0 And this is the correct behavior. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> =20 ------=_Part_545863_1662769086.1557520342175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div class=3D"ydpf9876065yahoo-style-wrap" style= =3D"font-family:verdana, helvetica, sans-serif;font-size:13px;"><div><div>t= hank you very much for quick response and openldap behavior configuration.&= nbsp;</div><div><br></div><div>how we can ignore to look server name in sub= ject of certificate so I can use LDAP server ip address instead of host nam= e? </div><div><br></div><div>Also want to know if there is any open CV= E which says it is vulnerabilities to use LDAP server ip address instead of= name in ldap configuration. </div><div><br></div><div><br></div><div>= <br></div><div class=3D"ydpf9876065signature"><div><span class=3D"ydpf98760= 65yui_3_7_2_102_1375813203128_121" style=3D"font-family:arial, sans-serif;c= olor:rgb(80, 0, 80);">Thank you,</span><br class=3D"ydpf9876065yui_3_7_2_10= 2_1375813203128_122" style=3D"font-family:arial, sans-serif;color:rgb(80, 0= , 80);"><span class=3D"ydpf9876065yui_3_7_2_102_1375813203128_123" style=3D= "font-family:arial, sans-serif;color:rgb(80, 0, 80);">Darshankumar Mistry</= span><br class=3D"ydpf9876065yui_3_7_2_102_1375813203128_124" style=3D"font= -family:arial, sans-serif;color:rgb(80, 0, 80);"><a href=3D"mailto:darshank= mistry(a)yahoo.com" class=3D"ydpf9876065yui_3_7_2_102_1375813203128_125" styl= e=3D"color:rgb(17, 85, 204);font-family:arial, sans-serif;" rel=3D"nofollow= " target=3D"_blank">darshankmistry(a)yahoo.com</a><br></div></div></div> <div><br></div><div><br></div> =20 </div><div id=3D"ydpb3d55fc2yahoo_quoted_7562650282" class=3D"ydpb3= d55fc2yahoo_quoted"> <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s= ans-serif;font-size:13px;color:#26282a;"> =20 <div> On Friday, May 10, 2019, 12:58:38 PM PDT, Quanah Gibson= -Mount <quanah(a)symas.com> wrote: </div> <div><br></div> <div><br></div> <div>--On Friday, May 10, 2019 8:52 PM +0000 <a href=3D"mai= lto:darshankmistry@yahoo.com" rel=3D"nofollow" target=3D"_blank">darshankmi= stry(a)yahoo.com</a> wrote:<br><br>> Full_Name: Darshankumar Mistry<br>&gt= ; Version:<br>> OS:<br>> URL: <a href=3D"ftp://ftp.openldap.org/incom= ing/" rel=3D"nofollow" target=3D"_blank">ftp://ftp.openldap.org/incoming/</= a><br>> Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac)<b= r>><br>><br>> I would like to know why Open LDAP behavior was chan= ged where we must<br>> have to configure FQDN name mentioned in certific= ate in order to work LDAP<br>> authentication... else TLS start failing.= <br><br>OpenLDAP has worked this way since I first started using it in 2002= .  This <br>behavior is nothing new.  And this is the correct beh= avior.<br><br>This ITS will be closed.<br><br>--Quanah<br><br><br>--<br><br= >Quanah Gibson-Mount<br>Product Architect<br>Symas Corporation<br>Packaged,= certified, and supported LDAP solutions powered by OpenLDAP:<br><<a hre= f=3D"http://www.symas.com" rel=3D"nofollow" target=3D"_blank">http://www.sy= mas.com</a>><br><br></div> </div> </div></body></html> ------=_Part_545863_1662769086.1557520342175--

1 0

Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by quanah＠symas.com 10 May '19

10 May '19

--On Friday, May 10, 2019 8:52 PM +0000 darshankmistry(a)yahoo.com wrote: > Full_Name: Darshankumar Mistry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) > > > I would like to know why Open LDAP behavior was changed where we must > have to configure FQDN name mentioned in certificate in order to work LDAP > authentication... else TLS start failing. OpenLDAP has worked this way since I first started using it in 2002. This behavior is nothing new. And this is the correct behavior. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
by darshankmistry＠yahoo.com 10 May '19

10 May '19

Full_Name: Darshankumar Mistry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) I would like to know why Open LDAP behavior was changed where we must have to configure FQDN name mentioned in certificate in order to work LDAP authentication... else TLS start failing. I am getting below error and I know that I am using IP address of LDAP server in my configuration instead of certificate subject name (FQDN of ldap server) TLS: can't connect: TLS: hostname does not match CN in peer certificate

1 0

Re: (ITS#8708) SASL EXTERNAL binds and sasl-secprops minssf
by quanah＠symas.com 09 May '19

09 May '19

--On Wednesday, May 08, 2019 12:56 PM -0400 David Hawes <dhawes(a)vt.edu> wrote: >> Hi David, >> >> I believe this was fixed with ITS#8796 (part of the 2.4.46 release). Can >> you confirm? > > Confirmed. ITS#8796 fixes #8708. Hi David, Thanks for the quick confirmation! I've closed ITS#8708 and noted that the fix for ITS#8796 resolved it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9020) Inconsistent cn=config objectClasses for overlays
by quanah＠openldap.org 09 May '19

09 May '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The majority of supported overlays use an objectClass of the format: olcOVERLAYConfig However, there are two overlays that do *not* follow this format, which is confusing. memberOf -> olcMemberOf dynlist -> olcDynamicList For 2.5, I would suggest we change these to be consistent with all the other overlays and document this change in the Admin Guide section on upgrade notes etc.

1 0

Re: (ITS#8708) SASL EXTERNAL binds and sasl-secprops minssf
by quanah＠symas.com 08 May '19

08 May '19

--On Tuesday, August 08, 2017 7:08 PM +0000 dhawes(a)gmail.com wrote: > Full_Name: David Hawes > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:468:c80:2103:0:523:da5e:da5e) Hi David, I believe this was fixed with ITS#8796 (part of the 2.4.46 release). Can you confirm? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net 08 May '19

08 May '19

On Mon, Jan 22, 2018 at 11:57:38PM +0000, ondra(a)mistotebe.net wrote: > On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote: >> After doing conversion, the resulting cn=config database has *two* ldap backends >> defined: >> >> dn: olcDatabase={-1}frontend,cn=config >> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config >> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf > > This is the catchall database used to handle referrals that are not > handled by any other database you configure by hand. It collects all the > chain-* settings that appear before the first chain-uri. > >> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf >> >> The first instance ({0}ldap,...) isn't even valid. If you remove the entire >> chain configuration from this database, and then attempt to import it, you get >> the following: > > Yeah that is a problem. Turns out the problem is different yet. When the overlay is started up after adding its entry, it generates a default backend internally. On adding the above backend it now thinks it has a default one already (even though there is no entry for it yet) and rejects it. >> This is because the first instance ({0}) is *missing* the required olcDbURI >> attribute. In addition, it generates completely bogus attribute values (See >> ITS#8693) > > Maybe we just need to inherit objectclass: olcLdapDatabase somehow in > olcChainOverlay and keep these settings in the overlay entry, or specify > a bogus URI to be configured there. Whatever is most useable and still > allows for seamless expansion. Still thinking making the overlay objectclass inherit the attributes from olcLdapDatabase instead of creating a fake DB but that can't be done for 2.4 and I have no idea how to properly go about that yet anyway. For 2.4 at least it might make sense to just use the flags on the default backend to say it has no entry associated with it (yet) and: - clear that in ldap_chain_cfadd_apply so we know it can be replaced later - also create the entry if slapd is just starting up (How about cn=config replication though? Upgrades need to be planned) - maybe only let a default backend be added if there really is no other backend yet (including the temporary ones used during normal operation), since those will get some defaults from it -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9019) NSSDB + OpenLDAP
by quanah＠symas.com 07 May '19

07 May '19

--On Tuesday, May 07, 2019 10:35 AM +0000 vangelier(a)hotmail.com wrote: > Full_Name: Victor Angelier > Version: OpenLDAP: slapd 2.4.44 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.78.44.170) > > > When using OpenLDAP with NSS DB in HA setup you can not change the TLS > certificate name through LDIF with ldapmodify. Hello, The MozNSS implementation was done by RedHat. It has since been abandoned by RedHat, although they have left a MozNSS/OpenSSL bridge in place. Any issues with MozNSS and OpenLDAP or OpenLDAP and RedHat's OpenSSL to MozNSS bridge needs to be filed with RedHat as it is not an OpenLDAP issue. If you can reproduce the problem with an OpenLDAP build that is directly linked to OpenSSL without RedHat's MozNSS bridge, please follow up. This ITS will be closed until any such follow up is provided. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9019) NSSDB + OpenLDAP
by vangelier＠hotmail.com 07 May '19

07 May '19

Full_Name: Victor Angelier Version: OpenLDAP: slapd 2.4.44 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.78.44.170) When using OpenLDAP with NSS DB in HA setup you can not change the TLS certificate name through LDIF with ldapmodify. The only way to update the TLS certificate name is by editing the cn=config.ldif file with breaches the signature. This is especially with HA setup a serious issue. Reproduce. Install and setup OpenLDAP in HA (I have 2 nodes) Configure it so that it uses NSS DB cn=config.ldif cat /etc/openldap/slapd.d/cn\=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 13782a66 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSProtocolMin: 3.3 olcTLSCipherSuite: ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL:!SSLV3 olcTLSDHParamFile: /etc/openldap/ssl/dhparams structuralObjectClass: olcGlobal entryUUID: ef483c7c-da8d-1038-907a-df6f97fe6ec7 creatorsName: cn=config createTimestamp: 20190314101611Z olcTLSCACertificatePath: /etc/openldap/ssl olcTLSCACertificateFile: /etc/pki/tls/certs/ca-bundle.crt olcTLSCertificateFile: "Cyberdyne Security" olcTLSCertificateKeyFile: /etc/openldap/ssl/password olcTLSVerifyClient: allow olcServerID: 1 ldaps://ldap-n1.cyberdynesecurity.ae olcServerID: 2 ldaps://ldap-n2.cyberdynesecurity.ae olcLogFile: /var/log/slapd.log entryCSN: 20190507074650.989216Z#000000#001#000000 modifiersName: cn=Manager,dc=cyberdynesecurity,dc=ae modifyTimestamp: 20190507074650Z contextCSN: 20190507074650.989216Z#000000#001#000000 contextCSN: 20190402094130.452589Z#000000#002#000000 Now try change "olcTLSCertificateFile" through LDIF vi change.ldif dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: "new certificate name" ldapmodify -Y EXTERNAL -H ldapi:/// -f edit.ldif -v ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 replace olcTLSCertificateFile: "new certificate name" modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) If "olcTLSCertificateFile" is set to an existing file like /tmp/certificate.crt it works fine.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs