openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Where is "uid" defined in schema?
by Peng Yu 14 Mar '14

14 Mar '14

Hi, I'm not able to find where "uid" is defined. Could any expert point me where it is defined? Thanks. pengy@lithium:/etc/ldap/schema$ grep '\<uid\>' * core.ldif:# RFC 1274 (uid/dc) core.ldif:# NAME ( 'uid' 'userid' ) core.ldif: DESC 'RFC2377: uid object' core.ldif: SUP top AUXILIARY MUST uid ) core.schema:# RFC 1274 (uid/dc) core.schema:# NAME ( 'uid' 'userid' ) core.schema: DESC 'RFC2377: uid object' core.schema: SUP top AUXILIARY MUST uid ) cosine.schema:##attributetype ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) inetorgperson.ldif: $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ pre inetorgperson.schema: photo $ roomNumber $ secretary $ uid $ userCertificate $ nis.ldif: f an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNu nis.ldif: ttributes for shadow passwords' SUP top AUXILIARY MUST uid MAY ( userPassword nis.schema: MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) nis.schema: MUST uid openldap.ldif: MUST ( uid $ cn ) openldap.schema: MUST ( uid $ cn ) -- Regards, Peng

6 5

Cannot resolve group example to gid : not found (ldapadduser error)
by Peng Yu 13 Mar '14

13 Mar '14

Hi, https://help.ubuntu.com/13.10/serverguide/openldap-server.html#openldap-ser… I'm following the instructions on the following webpage, with the following sections skipped. - Modifying the slapd Configuration Database - Logging - Replication - Access Control - TLS - Replication and TLS Then I get the following errors when I try the following commands. I'm know that I might make simple mistakes but I have no clue how to figure it out. Could you help me on how to make the command work? Thanks. pengy@lithium:/etc/ldap/schema$ sudo ldapadduser george example Cannot resolve group example to gid : not found -- Regards, Peng

1 0

Basic Openldap Question
by Borresen, John - 0442 - MITLL 13 Mar '14

13 Mar '14

All, A question has popped up here about the "olcDatabase={-1}frontend" under cn=config. Besides replying that it is always there, I'm not really sure what it does or what its purpose is.in addition to what it states in the Admin Guide: ".is a special database that is used to hold database-level options that should be applied to all databases. Subsequent database definitions may also override some frontend settings." That's my question: What is the olcDatabase={-1}frontend dbase and what is its purpose? Thanks in advance, John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Email: john.borresen(a)ll.mit.edu

2 1

TLS with multiple LDAP servers
by Julien Courtès 13 Mar '14

13 Mar '14

Hi, I have two LDAP servers in master-slave ldap1.domain.com - master ldap2.domain.com - slave These servers got different ip addresses and are hosted on different servers But I want to enable TLS connection with clients. So can I create a unique certificate that I put on both servers and the client will use one unique certificate to connect to server "ldap1" or "ldap2" if the first one is down. If not, how should I do? I did a search and I found that I can use subjectAltNames or wildcard certificat. Thanks Julien Courtès

5 5

set syntax possible in search filter?
by Stephan Fabel 12 Mar '14

12 Mar '14

Hi, reading this: http://www.openldap.org/faq/data/cache/1133.html - do I read this correctly that the set syntax can also be employed in search filters? The reason I ask is because Mark is listing LDAP URIs and this sentence: "The LDAP search corresponding to the URI's DN, attributes, scope and filter is performed, and all the matching entries are dereferenced." I'm unsure because the Admin Guide for 2.4 only mentions sets in the context of ACLs, and slapd.access(5) states that it's "undocumented". Thanks for any clarification, Stephan

3 7

Kerberos issue running OpenLDAP on Mac OS X Mavericks
by Denis Ahearn 12 Mar '14

12 Mar '14

We have a Rails app that uses OpenLDAP in the local development environment on Mac OS X to authenticate and authorize users (we use Active Directory in production and staging). Up until now all development has been done on Macs running Mountain Lion, and OpenLDAP has worked fine. Recently a new developer joined our team who is using a Mac running Mavericks, however OpenLDAP is behaving differently on his Mac. On Mavericks, OpenLDAP is trying to do something with Kerberos, which is failing. We see the following in the slapd.log on Mavericks: 5319fc2c >>> dnPrettyNormal: <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com> 5319fc2c <<< dnPrettyNormal: <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com>, <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com> 5319fc2c do_bind: version=3 dn="cn=jdoe,ou=people,dc=bluewaterbrand,dc=com" method=128 5319fc2c bdb_dn2entry("cn=jdoe,ou=people,dc=bluewaterbrand,dc=com") 5319fc2c => bdb_search 5319fc2c bdb_dn2entry("cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com") 5319fc2c => bdb_dn2id("cn=config,dc=bluewaterbrand,dc=com") 5319fc2c <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 5319fc2c entry_decode: "dc=bluewaterbrand,dc=com" 5319fc2c <= entry_decode(dc=bluewaterbrand,dc=com) 5319fc2c send_ldap_result: conn=-1 op=0 p=0 5319fc2c Entry *odusers_copy_entry(Operation *): Unable to locate cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com (32) 5319fc2c odusers_copy_krbrealm: No entry associated with KerberosKDC cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com 5319fc2c odusers_krb_auth: could not retrieve krb realm while authing jdoe 5319fc2c int odusers_increment_failedlogin(struct berval *): Unable to retrieve description of loginFailedAttempts attribute5319fc2c bdb_bind: Error to increment failed login count for cn=jdoe,ou=people,dc=bluewaterbrand,dc=com5319fc2c send_ldap_result: conn=1003 op=0 p=3 Here's the same section of slapd.log from a Mac running Mountain Lion, which is working correctly: 531e25c9 >>> dnPrettyNormal: <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com> 531e25c9 <<< dnPrettyNormal: <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com>, <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com> 531e25c9 do_bind: version=3 dn="cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" method=128 531e25c9 bdb_dn2entry("cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com") 531e25c9 do_bind: v3 bind: "cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" to "cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" 531e25c9 send_ldap_result: conn=1003 op=0 p=3 531e25c9 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ 531e25c9 connection_get(14): got connid=1003 531e25c9 connection_read(14): checking for input on id=1003 ber_get_next ldap_read: want=8, got=0 We've spent a copule of days looking into this, and can't find any noticeable differences in the ldap.conf and slapd.conf files between Mavericks and Mountain Lion that would explain why Mavericks is doing a search on "cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com". Does anyone know why OpenLDAP on Mavericks is behaving the way that it is, and more importantly, what would be the correct way to resolve this issue? Our Rails app is using the devise and devise_ldap_authenticatable gems to handle user authentication, so it would seem that we don't want OpenLDAP to do anything with Kerberos at all. Can this be controlled via configuration, or is this an issue with how the OpenLDAP shipped with Mavericks was built? Thanks, Denis

2 1

tls question
by Borresen, John - 0442 - MITLL 12 Mar '14

12 Mar '14

All, Can the olcTLSCACertificateFile and olcTLSCertificateFile be the same file? Finding some "interesting" examples online (even on some openssl.org pages) and would like clarification. Thanks, John -----Original Message----- From: Dieter Klünter [mailto:dieter@dkluenter.de] Sent: Tuesday, March 11, 2014 2:17 PM To: Borresen, John - 0442 - MITLL Cc: openldap-technical(a)openldap.org Subject: Re: TLS QUESTION Am Tue, 11 Mar 2014 13:15:21 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Dieter; > > Now, receiving the following when attempting to sign the cert: > > Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase > for /usr/local/openldap/etc/openldap/CA_test/private/cakey.pem: Error > reading certificate request in /etc/openldap/CA_test/newreq.pem > 2729:error:0906D06C:PEM routines:PEM_read_bio:no start > line:pem_lib.c:647:Expecting: CERTIFICATE REQUEST Signed certificate > is in newcert.pem I would sys you delete all certificates and certificate database files and restart from scratch. If you are using the openssl CA tools in order to create certificates, /etc/ssl/openssl.cnf should be modified to meet your requirements (in particular FQDN). Run ./CA.pl -newca ./CA.pl -newreq ./CA.pl -sign openssl rsa -in nrewreq.pem -out myKey.pem mv newcert.pem host.pem ./CA.pl -verify host.pem -Dieter > > -----Original Message----- > From: Dieter Klünter [mailto:dieter@dkluenter.de] > Sent: Tuesday, March 11, 2014 9:31 AM > To: Borresen, John - 0442 - MITLL > Cc: openldap-technical(a)openldap.org > Subject: Re: TLS QUESTION > > Am Tue, 11 Mar 2014 09:19:15 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > Guten morgen Dieter; > > > > I ran the openssl commands indicated below. > > > > But, ran them against my cacert.pem -- both the original and new > > successfully (they failed with servercrt.pem). > > > > I re-ran the CA.sh script this morning, and receiving the following > > errors when creating a new CA: > > > > Certificate is to be certified until Mar 8 13:09:05 2024 GMT (3650 > > days) failed to update database > > TXT_DB error number 2 > > This is an error of your certificate database files index.txt and > serial. > > -Dieter > > > > > -----Original Message----- > > From: Dieter Klünter [mailto:dieter@dkluenter.de] > > Sent: Monday, March 10, 2014 5:12 PM > > To: Borresen, John - 0442 - MITLL > > Subject: Re: TLS QUESTION > > > > Am Mon, 10 Mar 2014 16:55:04 -0400 > > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > > > Vielen Danke Dieter; > > > > > > Originally my command to create the client.pem was: > > > > > > grep -A 100 CERTIFICATE cacert.pem > client.pem > > > > > > Then I scp'd that out to the clients. That worked when doing SSL > > > on port 636 (and not wild-card certificates), but it is not > > > working now on TLS over 389 to mm-server1 and mm-server3 with > > > wild-card certs. > > > > > > The cacert.pem and client.pem is on each client. > > > > > > Doing further reading...the client.pem since it was built off the > > > cacert.pem (the server certificate) it should work. > > > > > > Should I use the cacert.pem or the servercrt.pem to create the > > > client.pem? > > > > Test this on each host > > openssl verify -CAfile path/to/ca client.pem servercert.pem > > > > openssl x509 -in servercert.pem -noout -text check for Common Name > > > > -Dieter > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Dieter Klünter [mailto:dieter@dkluenter.de] > > > Sent: Monday, March 10, 2014 2:41 PM > > > To: Borresen, John - 0442 - MITLL > > > Subject: Re: TLS QUESTION > > > > > > Am Mon, 10 Mar 2014 13:33:53 -0400 schrieb "Borresen, John - 0442 > > > - MITLL" > > > <John.Borresen(a)ll.mit.edu>: > > > > > > > Thanks Dieter... > > > > > > > > As I stated I saw Howard Chu's response to an individual in > > > > 2005 with a similar issue and he stated then, " For the slapd > > > > server you use the corresponding TLSCACertificateFile directive. > > > > You must use these configuration directives if you want to > > > > accept a self-signed cert." > > > > > > > > I did add the olcTLSCACertificateFile attribute (just forgot to > > > > list it in my original post). Was not certain at the time if > > > > the "olcTLSCertificateFile" should be removed so I did not > > > > remove it. So, before I do remove it, the attribute should be > > > > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" > > > > (and this should be removed), correct? > > > > > > > > The CA directories on all three servers look like this: > > > > > > > > # ll > > > > total 28 > > > > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> > > > > cacert.pem --> client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 > > > > 12:15 cacert.pem --> Self-signed certificate -rw-r--r-- 1 ldap > > > > ldap 1090 Jan 17 12:07 cert.csr --> Certificate Signing Request > > > > -rw-r--r-- 1 ldap ldap 1757 Jan 17 12:23 client.pem --> Client > > > > Certificate PEM -rw-r--r-- 1 ldap ldap 0 Jan 14 16:20 > > > > index.txt drwxr-xr-x 2 ldap ldap 4096 Jan 14 16:18 newcerts > > > > (empty) drwxr-xr-x 2 ldap ldap 4096 Jan 17 12:06 private --> > > > > server private key directory (cakey.pem) -rw-r--r-- 1 ldap > > > > ldap 3 Jan 17 11:59 serial This may sound like a dumb > > > > question... > > > > > > > > I created the client.pem from the cacert.pem (as indicated on > > > > openssl.org) then copied that to each client. Is there a step I > > > > missed in there? > > > > > > Yes, you have to create a client certificate for each host, while > > > the Common Name must match the FQDN of this host. my blog entry > > > may be of help: > > > > > > https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509- > > > ce > > > rt > > > ificate-chains-part-i > > > > > > -Dieter > > > > > > > If so, where? > > > > > > > > Thanks in advance > > > > > > > > John > > > > -----Original Message----- > > > > From: openldap-technical-bounces(a)OpenLDAP.org > > > > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of > > > > Dieter Klünter Sent: Monday, March 10, 2014 12:58 PM To: > > > > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > > > > > > > Am Mon, 10 Mar 2014 11:18:14 -0400 schrieb "Borresen, John - > > > > 0442 > > > > - MITLL" > > > > <John.Borresen(a)ll.mit.edu>: > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > My set up consists of three servers each syncing with each > > > > > other. The host names are: > > > > > > > > > > 1) mm-server1.example.ldap > > > > > > > > > > 2) mm-server2.example.ldap > > > > > > > > > > 3) mm-server3.example.ldap > > > > > > > > > > > > > > > > > > > > Utilizing TLSv1, on all three I have: > > > > > > > > > > olcTLSCertificateFile: > > > > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > > > > > > > this should be opcTLSCAcertificateFile > > > > > > > > > > > > > > olcTLSCertificateKeyFile: > > > > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > > > > > > > you are misssing the host certificate, something like > > > > olcTLSCertificateFile > > > > /usr/local/openldap/etc/openldap/CA/host.pem > > > > > > > > > > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > > > > > > > > > > > > > Configured with self-signed wild-card certs, originally > > > > > configured (using openssl 0.9.8) on mm-server2 and exported to > > > > > the other servers. > > > > > > > > > > > > > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and > > > > > openssl s_client on mm-server1 or mm-server3 or any client > > > > > pointing back to mm-server1 or 3, I receive the following > > > > > error: > > > > > > > > > > > > > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > > > > > > > TLS: can't connect: error:14090086:SSL > > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > > (self signed certificate). > > > > > > > > > > ldap_start_tls: Connect error (-11) > > > > > > > > > > additional info: error:14090086:SSL > > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > > (self signed certificate) > > > > > > > > > > > > > > > > > > > > Running any of those to mm-server2, it works with no such > > > > > error. > > > > > > > > > > > > > > > > > > > > I am guessing, that since the certs were created on > > > > > mm-server2, originally, that is why it works this way. Also, > > > > > guessing I missed a step somewhere. > > > > > > > > > > > > > > > > > > > > I read online a post from 2005 with a good explanation of > > > > > self-signed from Howard Chu about a similar problem. > > > > > > > > > > > > > > > > > > > > What is the best procedure for creating wild-card certs and > > > > > sharing those out to other servers? The procedure that was > > > > > used was from openssl.org so it was not a fly-by-night weblog. > > > > > > > > > > > > > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John D. Borresen (Dave) > > > > > > > > > > Linux/Unix Systems Administrator > > > > > > > > > > MIT Lincoln Laboratory > > > > > > > > > > Surveillance Systems Group > > > > > > > > > > 244 Wood St > > > > > > > > > > Lexington, MA 02420 > > > > > > > > > > Ph: (781) 981-1609 > > > > > > > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Dieter Klünter | Systemberatung > > > > http://sys4.de > > > > GPG Key ID: E9ED159B > > > > 53°37'09,95"N > > > > 10°08'02,42"E > > > > > > > > > > > > > > > > -- > > > Dieter Klünter | Systemberatung > > > http://sys4.de > > > GPG Key ID: E9ED159B > > > 53°37'09,95"N > > > 10°08'02,42"E > > > > > > > > -- > > Dieter Klünter | Systemberatung > > http://sys4.de > > GPG Key ID: E9ED159B > > 53°37'09,95"N > > 10°08'02,42"E > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 2

OpenLdap provider-client replication error
by Seun Ojedeji 12 Mar '14

12 Mar '14

Hello, I am trying to setup a sync between 2 ldap instance, following the guide here<http://askubuntu.com/questions/360190/how-to-configure-master-slave-ldap-re…>. I ran the command below, but got the following error message. sudo ldapadd -x -W -D cn=admin,dc=acme,dc=come -f /root/enable_sync_prov.ldif Enter LDAP Password: *modifying entry "olcDatabase={1}hdb,cn=config"ldap_modify: Insufficient access (50)* How do i fix the insuffient access problem? I am using the admin that has full write access on ldap. Regards -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji(a)fuoye.edu.ng <seun.ojedeji(a)fuoye.edu.ng>*

2 8

Re: TLS QUESTION
by Dieter Klünter 12 Mar '14

12 Mar '14

Am Tue, 11 Mar 2014 09:19:15 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > Guten morgen Dieter; > > I ran the openssl commands indicated below. > > But, ran them against my cacert.pem -- both the original and new > successfully (they failed with servercrt.pem). > > I re-ran the CA.sh script this morning, and receiving the following > errors when creating a new CA: > > Certificate is to be certified until Mar 8 13:09:05 2024 GMT (3650 > days) failed to update database > TXT_DB error number 2 This is an error of your certificate database files index.txt and serial. -Dieter > -----Original Message----- > From: Dieter Klünter [mailto:dieter@dkluenter.de] > Sent: Monday, March 10, 2014 5:12 PM > To: Borresen, John - 0442 - MITLL > Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 16:55:04 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > Vielen Danke Dieter; > > > > Originally my command to create the client.pem was: > > > > grep -A 100 CERTIFICATE cacert.pem > client.pem > > > > Then I scp'd that out to the clients. That worked when doing SSL > > on port 636 (and not wild-card certificates), but it is not working > > now on TLS over 389 to mm-server1 and mm-server3 with wild-card > > certs. > > > > The cacert.pem and client.pem is on each client. > > > > Doing further reading...the client.pem since it was built off the > > cacert.pem (the server certificate) it should work. > > > > Should I use the cacert.pem or the servercrt.pem to create the > > client.pem? > > Test this on each host > openssl verify -CAfile path/to/ca client.pem servercert.pem > > openssl x509 -in servercert.pem -noout -text check for Common Name > > -Dieter > > > > > > > > > > > > > -----Original Message----- > > From: Dieter Klünter [mailto:dieter@dkluenter.de] > > Sent: Monday, March 10, 2014 2:41 PM > > To: Borresen, John - 0442 - MITLL > > Subject: Re: TLS QUESTION > > > > Am Mon, 10 Mar 2014 13:33:53 -0400 > > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu>: > > > > > Thanks Dieter... > > > > > > As I stated I saw Howard Chu's response to an individual in 2005 > > > with a similar issue and he stated then, " For the slapd server > > > you use the corresponding TLSCACertificateFile directive. You > > > must use these configuration directives if you want to accept a > > > self-signed cert." > > > > > > I did add the olcTLSCACertificateFile attribute (just forgot to > > > list it in my original post). Was not certain at the time if the > > > "olcTLSCertificateFile" should be removed so I did not remove it. > > > So, before I do remove it, the attribute should be > > > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and > > > this should be removed), correct? > > > > > > The CA directories on all three servers look like this: > > > > > > # ll > > > total 28 > > > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem > > > --> client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 > > > cacert.pem --> Self-signed certificate -rw-r--r-- 1 ldap ldap > > > 1090 Jan 17 12:07 cert.csr --> Certificate Signing Request > > > -rw-r--r-- 1 ldap ldap 1757 Jan 17 12:23 client.pem --> Client > > > Certificate PEM -rw-r--r-- 1 ldap ldap 0 Jan 14 16:20 > > > index.txt drwxr-xr-x 2 ldap ldap 4096 Jan 14 16:18 newcerts > > > (empty) drwxr-xr-x 2 ldap ldap 4096 Jan 17 12:06 private --> > > > server private key directory (cakey.pem) -rw-r--r-- 1 ldap > > > ldap 3 Jan 17 11:59 serial This may sound like a dumb > > > question... > > > > > > I created the client.pem from the cacert.pem (as indicated on > > > openssl.org) then copied that to each client. Is there a step I > > > missed in there? > > > > Yes, you have to create a client certificate for each host, while > > the Common Name must match the FQDN of this host. my blog entry may > > be of help: > > > > https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-cert > > ificate-chains-part-i > > > > -Dieter > > > > > If so, where? > > > > > > Thanks in advance > > > > > > John > > > -----Original Message----- > > > From: openldap-technical-bounces(a)OpenLDAP.org > > > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of > > > Dieter Klünter Sent: Monday, March 10, 2014 12:58 PM To: > > > openldap-technical(a)openldap.org Subject: Re: TLS QUESTION > > > > > > Am Mon, 10 Mar 2014 11:18:14 -0400 > > > schrieb "Borresen, John - 0442 - MITLL" > > > <John.Borresen(a)ll.mit.edu>: > > > > > > > All, > > > > > > > > > > > > > > > > My set up consists of three servers each syncing with each > > > > other. The host names are: > > > > > > > > 1) mm-server1.example.ldap > > > > > > > > 2) mm-server2.example.ldap > > > > > > > > 3) mm-server3.example.ldap > > > > > > > > > > > > > > > > Utilizing TLSv1, on all three I have: > > > > > > > > olcTLSCertificateFile: > > > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > > > > > this should be opcTLSCAcertificateFile > > > > > > > > > > > olcTLSCertificateKeyFile: > > > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > > > > > you are misssing the host certificate, something like > > > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > > > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > > > > > > > > > Configured with self-signed wild-card certs, originally > > > > configured (using openssl 0.9.8) on mm-server2 and exported to > > > > the other servers. > > > > > > > > > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and > > > > openssl s_client on mm-server1 or mm-server3 or any client > > > > pointing back to mm-server1 or 3, I receive the following error: > > > > > > > > > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > > > > > TLS: can't connect: error:14090086:SSL > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > (self signed certificate). > > > > > > > > ldap_start_tls: Connect error (-11) > > > > > > > > additional info: error:14090086:SSL > > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > > (self signed certificate) > > > > > > > > > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > > > originally, that is why it works this way. Also, guessing I > > > > missed a step somewhere. > > > > > > > > > > > > > > > > I read online a post from 2005 with a good explanation of > > > > self-signed from Howard Chu about a similar problem. > > > > > > > > > > > > > > > > What is the best procedure for creating wild-card certs and > > > > sharing those out to other servers? The procedure that was > > > > used was from openssl.org so it was not a fly-by-night weblog. > > > > > > > > > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > > > > > > > John D. Borresen (Dave) > > > > > > > > Linux/Unix Systems Administrator > > > > > > > > MIT Lincoln Laboratory > > > > > > > > Surveillance Systems Group > > > > > > > > 244 Wood St > > > > > > > > Lexington, MA 02420 > > > > > > > > Ph: (781) 981-1609 > > > > > > > > Email: john.borresen(a)ll.mit.edu > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Dieter Klünter | Systemberatung > > > http://sys4.de > > > GPG Key ID: E9ED159B > > > 53°37'09,95"N > > > 10°08'02,42"E > > > > > > > > > > > -- > > Dieter Klünter | Systemberatung > > http://sys4.de > > GPG Key ID: E9ED159B > > 53°37'09,95"N > > 10°08'02,42"E > > > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 8

LMDB test assertion failures on Linux/MIPS
by Martin Lucina 11 Mar '14

11 Mar '14

Hi, I've recently started using LMDB in a new project targeted to MIPS (and later also ARM) architectures. While developing my storage code I found that test cases which execute perfectly on x86 were failing with assertions inside LMDB on mips and mipsel devices. Investigating further, I've found that the "mtest" test program included with LMDB also fails. Specifically, the failures I'm seeing are any of the following: mdb.c:2635: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save() or mdb.c:5100: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() or mdb.c:5176: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() or mdb.c:1713: Assertion 'rc == 0' failed in mdb_page_dirty() etc. The failures are intermittent in that there's about a 50% chance mtest will complete successfully. The line numbers are against LMDB 0.9.11 source. Target devices and toolchain combinations I have tried (all fail): - mips-sf-linux-musl cross compilers from musl.codu.org, musl libc 0.9.15. Atheros AR9344 cpu, OpenWRT trunk (Linux 3.10.28). - mipsel-sf-linux-musl cross compilers from musl.codu.org, musl libc 0.9.15, Broadcom BCM4706, Tomato firmware by "shibby" (Linux 2.6.22.x based on ASUS SDK). In all cases the code fails both with and without optimization, and is compiled as a static executable. Consulting with a friend who is also developing on MIPS devices he said he ran into similar problems when trying LMDB. He suggested that I check for problems with unaligned memory accesses; indeed compiling LMDB with -Wcast-align produces many warnings regarding such accesses. My knowledge of LMDB and MIPS internals is not up to debugging this but it seems like unaligned accesses may(?) be the underlying cause. What is the status of LMDB on MIPS? Has anyone tried it? Any help would be much appreciated. Martin

4 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical