openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

ITS#6576
by marco.pizzoli＠gmail.com 15 Jul '10

15 Jul '10

--0016e6de0432b2d346048b6a8223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use of grep. My initial request is motivated by a heavy trafficated deployment in which access log files are rotated every 3h and the information about the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a daemon (secldapclntd) which creates a *permanent* pool of connections againts all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integration and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have to follow many files and correlate many informations (conn=3D<number>) For my purposes it would be sufficient an extension to slapo-accesslog permitting me to define a filter on the binddn of the activity. Thanks Marco --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016e6de0432b2d346048b6a8223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use = of grep. My initial request is motivated by a heavy trafficated depl= oyment in which access log files are rotated every 3h and the information a= bout the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a dae= mon (secldapclntd) which creates a *permanent* pool of connections againts = all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integrat= ion and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have = to follow many files and correlate many informations (conn=3D<number>= ) For my purposes it would be sufficient an extension to slapo-acces= slog permitting me to define a filter on the binddn of the activity. Thanks =A0=A0=A0 Marco -- _________= ________________________________ Non =E8 forte chi non cade, ma chi cade= ndo ha la forza di rialzarsi. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ji= m Morrison <div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_pop= up"></div><style type=3D"text/css">#avg_ls_inline_popup { position:absolut= e; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; = width: 240px; overflow: hidden; word-wrap: break-word; color: black; fo= nt-size: 10px; text-align: left; line-height: 13px;}</style> --0016e6de0432b2d346048b6a8223--

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> Rich Megginson wrote: >>>> Howard Chu wrote: >>>>> rmeggins(a)redhat.com wrote: >>>>>> Full_Name: Rich Megginson >>>>>> Version: 2.4.23 >>>>>> OS: Fedora >>>>>> URL: >>>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>>> >>>>>> >>>>>> >>>>>> Submission from: (NULL) (76.113.111.209) >>>>>> >>>>>> >>>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>>> case >>>>>> so, see if the cert and issuer are the same cert, and allow the >>>>>> use of it (with a warning) >>>>> >>>>> If you checked to see if the issuer is already trusted, I guess the >>>>> patch is OK. >>>>> >>>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>>> documentation says to use explicit CA certs, separate from the server >>>>> cert. Is it really a good idea to break this validation check? >>>> Probably not, but openssl seems to allow it. This provides parity >>>> with >>>> the openssl implementation. >>>> >>>> This issue came up when testing openldap with NSS support in Fedora. >>>> The Fedora package creates a self signed CA cert using openssl req >>>> -x509. This works with openldap+openssl, but fails with >>>> openldap+moznss. >>> >>> In the OpenSSL case, it only succeeds if the cert is configured as >>> both a CA cert and a server cert. I.e., the client must have been >>> configured to trust the cert already. I believe for your patch, it >>> should fail when CERT_FindCertIssuer() returns NULL. No? >> You are correct. I've uploaded a new patch. > > OK, committed. Thanks for the patch. And thank you for your help. > >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> >> >> >> Here is the diff between the two patches: >> 32,34c32 >> < + /* no issuer - warn and >> allow */ >> < + status = SECSuccess; >> < + rc = 0; >> --- >> > + /* no issuer - fail */ >> 36c34 >> < + "TLS: warning: the >> server certificate %s has no issuer - " >> --- >> > + "TLS: error: the >> server certificate %s has no issuer - " >> >>> >>>>> Also, where does this check occur in the main sequence of >>>>> verification >>>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>>> been checked successfully? >>>> Yes. This check occurs in the cert chain processing, which is done >>>> last. >>> >>> OK. >>> >> >> > >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> Rich Megginson wrote: >>> Howard Chu wrote: >>>> rmeggins(a)redhat.com wrote: >>>>> Full_Name: Rich Megginson >>>>> Version: 2.4.23 >>>>> OS: Fedora >>>>> URL: >>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>> >>>>> >>>>> Submission from: (NULL) (76.113.111.209) >>>>> >>>>> >>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>> case >>>>> so, see if the cert and issuer are the same cert, and allow the >>>>> use of it (with a warning) >>>> >>>> If you checked to see if the issuer is already trusted, I guess the >>>> patch is OK. >>>> >>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>> documentation says to use explicit CA certs, separate from the server >>>> cert. Is it really a good idea to break this validation check? >>> Probably not, but openssl seems to allow it. This provides parity with >>> the openssl implementation. >>> >>> This issue came up when testing openldap with NSS support in Fedora. >>> The Fedora package creates a self signed CA cert using openssl req >>> -x509. This works with openldap+openssl, but fails with >>> openldap+moznss. >> >> In the OpenSSL case, it only succeeds if the cert is configured as >> both a CA cert and a server cert. I.e., the client must have been >> configured to trust the cert already. I believe for your patch, it >> should fail when CERT_FindCertIssuer() returns NULL. No? > You are correct. I've uploaded a new patch. OK, committed. Thanks for the patch. > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> > > Here is the diff between the two patches: > 32,34c32 > < + /* no issuer - warn and allow */ > < + status = SECSuccess; > < + rc = 0; > --- > > + /* no issuer - fail */ > 36c34 > < + "TLS: warning: the > server certificate %s has no issuer - " > --- > > + "TLS: error: the > server certificate %s has no issuer - " > >> >>>> Also, where does this check occur in the main sequence of verification >>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>> been checked successfully? >>> Yes. This check occurs in the cert chain processing, which is done >>> last. >> >> OK. >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 >>>> OS: Fedora >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>> >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> MozNSS doesn't like self-signed CA certs that are also used for >>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>> case >>>> so, see if the cert and issuer are the same cert, and allow the >>>> use of it (with a warning) >>> >>> If you checked to see if the issuer is already trusted, I guess the >>> patch is OK. >>> >>> But that aside, MozNSS's behavior sounds correct to me, and our >>> documentation says to use explicit CA certs, separate from the server >>> cert. Is it really a good idea to break this validation check? >> Probably not, but openssl seems to allow it. This provides parity with >> the openssl implementation. >> >> This issue came up when testing openldap with NSS support in Fedora. >> The Fedora package creates a self signed CA cert using openssl req >> -x509. This works with openldap+openssl, but fails with >> openldap+moznss. > > In the OpenSSL case, it only succeeds if the cert is configured as > both a CA cert and a server cert. I.e., the client must have been > configured to trust the cert already. I believe for your patch, it > should fail when CERT_FindCertIssuer() returns NULL. No? You are correct. I've uploaded a new patch. URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2… <ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> Here is the diff between the two patches: 32,34c32 < + /* no issuer - warn and allow */ < + status = SECSuccess; < + rc = 0; --- > + /* no issuer - fail */ 36c34 < + "TLS: warning: the server certificate %s has no issuer - " --- > + "TLS: error: the server certificate %s has no issuer - " > >>> Also, where does this check occur in the main sequence of verification >>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>> been checked successfully? >> Yes. This check occurs in the cert chain processing, which is done >> last. > > OK. >

1 0

ITS#6570 published: SECURITY: Two OpenLDAP preauth vulnerabilities
by openldap-its＠OpenLDAP.org 14 Jul '10

14 Jul '10

Private ITS#6570 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6570

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 >>> OS: Fedora >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>> >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> MozNSS doesn't like self-signed CA certs that are also used for >>> TLS/SSL server certs (such as generated by openssl req -x509) >>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>> case >>> so, see if the cert and issuer are the same cert, and allow the >>> use of it (with a warning) >> >> If you checked to see if the issuer is already trusted, I guess the >> patch is OK. >> >> But that aside, MozNSS's behavior sounds correct to me, and our >> documentation says to use explicit CA certs, separate from the server >> cert. Is it really a good idea to break this validation check? > Probably not, but openssl seems to allow it. This provides parity with > the openssl implementation. > > This issue came up when testing openldap with NSS support in Fedora. > The Fedora package creates a self signed CA cert using openssl req > -x509. This works with openldap+openssl, but fails with openldap+moznss. In the OpenSSL case, it only succeeds if the cert is configured as both a CA cert and a server cert. I.e., the client must have been configured to trust the cert already. I believe for your patch, it should fail when CERT_FindCertIssuer() returns NULL. No? >> Also, where does this check occur in the main sequence of verification >> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >> been checked successfully? > Yes. This check occurs in the cert chain processing, which is done last. OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >> >> Submission from: (NULL) (76.113.111.209) >> >> >> MozNSS doesn't like self-signed CA certs that are also used for >> TLS/SSL server certs (such as generated by openssl req -x509) >> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >> case >> so, see if the cert and issuer are the same cert, and allow the >> use of it (with a warning) > > If you checked to see if the issuer is already trusted, I guess the > patch is OK. > > But that aside, MozNSS's behavior sounds correct to me, and our > documentation says to use explicit CA certs, separate from the server > cert. Is it really a good idea to break this validation check? Probably not, but openssl seems to allow it. This provides parity with the openssl implementation. This issue came up when testing openldap with NSS support in Fedora. The Fedora package creates a self signed CA cert using openssl req -x509. This works with openldap+openssl, but fails with openldap+moznss. > > Also, where does this check occur in the main sequence of verification > - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already > been checked successfully? Yes. This check occurs in the cert chain processing, which is done last. > >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… > Submission from: (NULL) (76.113.111.209) > > > MozNSS doesn't like self-signed CA certs that are also used for > TLS/SSL server certs (such as generated by openssl req -x509) > CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case > so, see if the cert and issuer are the same cert, and allow the > use of it (with a warning) If you checked to see if the issuer is already trusted, I guess the patch is OK. But that aside, MozNSS's behavior sounds correct to me, and our documentation says to use explicit CA certs, separate from the server cert. Is it really a good idea to break this validation check? Also, where does this check occur in the main sequence of verification - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already been checked successfully? > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Full_Name: Rich Megginson Version: 2.4.23 OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… Submission from: (NULL) (76.113.111.209) MozNSS doesn't like self-signed CA certs that are also used for TLS/SSL server certs (such as generated by openssl req -x509) CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case so, see if the cert and issuer are the same cert, and allow the use of it (with a warning) This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6588) Change log not up to date on www.openldap.org
by Kurt＠OpenLDAP.org 13 Jul '10

13 Jul '10

On Jul 13, 2010, at 2:39 AM, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: 2.4.23 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.14.151.50) >=20 >=20 > The page at http://www.openldap.org/software/release/changes.html only = lists > changes for the 2.4.22 release, although 2.4.23 is now released. Fixed. -- Kurt

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