Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
by hyc＠symas.com
andrew.findlay(a)skills-1st.co.uk wrote:
> Full_Name: Andrew Findlay
> Version: 2.4.24
> OS: OpenSuSE 11.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (88.97.25.132)
>
>
> For various test and teaching purposes I have a set of OpenLDAP configs that run
> small servers intended for local access only. As I run these on a wide variety
> of machines and also give them to students to run on their own machines, all the
> LDAP clients are set up to access the servers via the loopback interface:
> typically ldap://localhost:1389/
>
> Some of the configs use TLS. I have a local CA which issues simple server certs,
> usually with 'CN=localhost' as part of the subject name. Since upgrading the OS
> and OpenLDAP version of my main test environment I find that TLS connections are
> failing:
> My client scripts used to work: I think this was purely because earlier versions
> of the TLS client code were less careful about checking certificates.
> Specifically, the 'self signed certificate in certificate chain' error was not
> even reported unless client-side debugging was turned on.
Used to work - since when, what release, what else has changed since then?
I'll note that I just tested some localhost certs a few days ago and they were
fine, and the cert verification code hasn't changed in quite a long time.
(E.g., ITS#6711 the test setup there uses localhost with no problem.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months
(ITS#6838) TLS client will not accept certificate for 'localhost'
by andrew.findlay＠skills-1st.co.uk
Full_Name: Andrew Findlay
Version: 2.4.24
OS: OpenSuSE 11.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.97.25.132)
For various test and teaching purposes I have a set of OpenLDAP configs that run
small servers intended for local access only. As I run these on a wide variety
of machines and also give them to students to run on their own machines, all the
LDAP clients are set up to access the servers via the loopback interface:
typically ldap://localhost:1389/
Some of the configs use TLS. I have a local CA which issues simple server certs,
usually with 'CN=localhost' as part of the subject name. Since upgrading the OS
and OpenLDAP version of my main test environment I find that TLS connections are
failing:
> ldapsearch -d 768 -x -ZZ -H ldap://localhost:1389/ -b dc=example,dc=org
sn=trott
TLS: hostname (slab.skills-1st.co.uk) does not match common name in certificate
(localhost).
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
slab.skills-1st.co.uk is indeed the name of the machine, but I asked to connect
to 'localhost' so that is the name that should be checked against the
certificate.
If I put in any other alias for localhost in /etc/hosts and issue a certificate
for that, the connection is OK so the problem is specific to the string
'localhost', not to the use of the loopback interface in general.
I think the problem is in tlso_session_chkhost() in tls_o.c:
if( ldap_int_hostname &&
( !name_in || !strcasecmp( name_in, "localhost" ) ) )
{
name = ldap_int_hostname;
} else {
name = name_in;
}
If I understand this correctly, the intention appears to be to allow a
certificate issued for the FQDN of the machine to be accepted when it is
presented on the loopback interface. This may be a reasonable thing to do, but
the current implementation prevents the use of a certificate issued specifically
for 'localhost'.
My client scripts used to work: I think this was purely because earlier versions
of the TLS client code were less careful about checking certificates.
Specifically, the 'self signed certificate in certificate chain' error was not
even reported unless client-side debugging was turned on.
12 years, 9 months
(ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: RE24, HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.243.151)
After adding the following LDIF to cn=config (via ldapadd), slapd does not start
anymore:
------------------------------------
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectclass: olcChainConfig
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectclass: olcLDAPConfig
objectclass: olcChainDatabase
olcDbUri: ldap://ldap.server
olcDatbase: {0}ldap
------------------------------------
To add some fun. Everything works as expected if I reorder the "objectClass"
Values so that "olcLDAPConfig" appears after "olcChainDatabase".
Additionally the error messages I get in the log when slapd fails to start with
the above config seem to be completely unrelated:
------
olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix
config error processing olcDatabase={0}config,cn=config: <olcRootPW> can only be
set when rootdn is under suffix
------
The underlying problem seems to be that, when the "olcLDAPConfig" objectclass
appears first slapd seems to choose the wrong ConfigTable for the olcDatabase
attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as
defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the
LDAP Database as if it were in "normal" database, including adding it to the
backendDB list. As I configured the chain overlay as a global overlay this
back-ldap database is put to the front of the backendDB list leading to problems
when initializing the cn=config database itself, because the code assumes that
the config database is always the first one, which will than lead to the strange
error message above.
(... that's how far I got with analyzing the problem, I have no idea yet how to
fix it though. Suggestions are welcome.)
12 years, 9 months
Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com
I believe this may be the same issue as in #6217, given this behavior with two users which have the same objectclasses,
same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on):
The initial query, where one entry doesn't get returned as it should:
=====================================================================
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))'
uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))'
uid
If I reverse the filter, I get the expected results:
=====================================================================
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))'
uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))'
uid
dn: uid=jdoe2,ou=Users,dc=example,dc=com
uid: jdoe2
Furthermore, if I now try the first query again, it too works:
=====================================================================
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))'
uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))'
uid
dn: uid=jdoe2,ou=Users,dc=example,dc=com
uid: jdoe2
I already have the patch for ITS#5756 applied in all the versions I've tested (2.4.17, 2.4.21,
and 2.4.23). I can provide a sample database which exhibits this behavior if needed, as I am working on providing a
self-contained sanitized example already. If the developers agree that the issue described in these two ITS's are one
and the same, I'm fine with marking this bug as a duplicate of ITS#6217 to avoid fragmentation of debugging efforts.
12 years, 9 months
Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com
hyc(a)symas.com wrote:
>
> ryans(a)aweber.com wrote:
> > I am experiencing what appears to be the same issue, and opened a
> > ticket - http://www.openldap.org/its/index.cgi?findid=6831 -
> > because this one did not pop up when I searched for existing ITS's
> > (perhaps my search terms did not match or I just overlooked it).
> > As I mentioned in the ticket I opened, this is not a schema issue;
> > all the schema match on every server, and if that were the problem,
> > none of the users would be served properly. What I found is that
> > the keys that proxycache was looking for did not exist in the bdb
> > it was searching. Why exactly that is, I'm not sure. Hopefully
> > the information I provided in that ITS (or, perhaps some additional
> > debugging information - gdb output or copies of databases exhibiting
> > the problem) will help shed some light. If it is indeed the same
> > issue, I'm all for coalescing the two. I have tested this all the
> > way up through 2.4.23, and there are no commits to pcache.c or
> > back-ldap/search.c since 2.4.23 was released that addresses this problem.
>
> Since you are not having the objectclass-related problem described in this
> ticket it is not the same issue.
Actually, having just tested that theory, I think my problem is actually objectclass-related, because it seems that it
only happens when the objectClass attribute is included in the filter, and I can get different results by swapping the
order of the filter components. Consider these two users, who have the same objectclasses, same attributes, and differ
only in the attribute values (e.g., their name, phone number, and so on):
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid
So, one entry doesn't get returned when it should. If I reverse the filter, I get the expected results:
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid
dn: uid=jdoe2,ou=Users,dc=example,dc=com
uid: jdoe2
Furthermore, if I now try the first query again, it too works:
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid
dn: uid=jdoe1,ou=Users,dc=example,dc=com
uid: jdoe1
bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com
'(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid
dn: uid=jdoe2,ou=Users,dc=example,dc=com
uid: jdoe2
And, like Jim, I already have the patch for ITS#5756 applied in 2.4.17, 2.4.21, and 2.4.23. I can give you an example
database exhibiting this behavior, if you like?
12 years, 9 months
Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no
Howard Chu writes:
> Agreed. I'm fine with dropping this configure switch and unifdef'ing it so
> that librewrite is always used.
Built unless --disable-slapd, I think. It is not installed, and the
other libraries do not use it.
--
Hallvard
12 years, 9 months
(ITS#6836) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk
Full_Name: Andrew Findlay
Version: 2.4.24
OS: OpenSuSE 11.3
URL: ftp://ftp.openldap.org/incoming/afindlay-slapdconf2.sdf.20110216.diff
Submission from: (NULL) (88.97.25.132)
Admin Guide Section 5.4. "Converting old style slapd.conf(5) file to cn=config
format" suggests that it is enough to run a slapd tool with both -f and -F
options to perform this conversion. While strictly true, this will almost
certainly result in an un-manageable server because there is no rootPW set for
cn=config.
The attached patch provides guidance to avoid this trap.
12 years, 9 months
Re: (ITS#6834) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk
On Wed, Feb 16, 2011 at 03:44:28PM -0800, Howard Chu wrote:
> >It would also be useful to copy the config database clause from
> >slapd-config(5) into the example in the Admin Guide:
> >
> > # set a rootpw for the config database so we can bind.
> > # deny access to everyone else.
> > dn: olcDatabase=config,cn=config
> > objectClass: olcDatabaseConfig
> > olcDatabase: config
> > olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
> > olcAccess: to * by * none
>
> That ACL is already the default. In an isolated example there's no
> need to specify it. (It is present in the slapd-config(5) example to
> ensure that it takes precedence over the olcFrontendConfig ACLs
> immediately above it.)
I was suggesting the inclusion of this entry mainly because of the
olcRootPW, but as it would go into the config example in section 5.3 at
about line 20, surely the ACL should be present for the same reason that
it is in the manpage example?
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
12 years, 9 months
