Hi,
Some reason to smile I think.
After writing the previous mail, I just took a wild guess and recreated the
certificates and I got rid of the errors shown :)
Now ldapsearch -Z and ldapsearch -ZZ are no more throwing errors but are
asking for some password (with TLS_REQCERT demand in /etc/ldap/ldap.conf)
But again, to my surprise, it doesn't accept the password and shows the the
following error.
*res_errno: 49, res_error: <SASL(-13): user not found: no secret in
database>, res_matched: <>*
/var/log/debug shows the following :
*Jul 20 13:14:03 ubuntu slapd[2354]: SASL [conn=32] Error: unable to open
Berkeley db /etc/sasldb2: No such file or directory
Jul 20 13:14:03 ubuntu last message repeated 3 times
Jul 20 13:14:03 ubuntu slapd[2354]: SASL [conn=32] Failure: no secret in
database*
Please suggest.
-Asimananda
On Mon, Jul 20, 2009 at 11:51 AM, Asimananda Mohanty <
asimananda.mohanty(a)gmail.com> wrote:
Hi,
I ran the following command on my setup and found some error.
openssl s_client -connect ldap-company.com:636 -showcerts -CAfile
/etc/ssl/certs/ca-cert.pem
Some of the errors that I saw were :
verify error:num=20:unable to get local issuer certificate
verify return:1
verify error:num=27:certificate not trusted
verify return:1
verify error:num=21:unable to verify the first certificate
verify return:1
But eventually, I got connected with the last few lines as :
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
52B3C73421E31E563441A84F8149AB5EB7A92D62FB28F3E01CE73707164265A0
Session-ID-ctx:
Master-Key:
B56391251B286C25A411BDD77DA61299BBC6E9F8899972EB02CB2E82FAE7F3708473B832CECD16D64A64EC1BEAB6DF6D
Key-Arg : None
Start Time: 1248069588
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
Is it normal?
If it is normal, then Can I consider that my certificates are Ok and the
problem lies somewhere else?
Please suggest.
-Asimananda
On Wed, Jul 15, 2009 at 11:06 AM, Asimananda Mohanty <
asimananda.mohanty(a)gmail.com> wrote:
> Hi Matt,
>
> Thank you very much for your kind support so as to resolve the issue that
> I was facing for so long.
>
> Here is what I did as per Matt's suggestion and it worked.
>
> 1. I used certtools to generate the key and certificate files.
> 2. I used them instead of the old ones that were supposed to be generated
> by gnutls.
> 3. Change the ownership and permission of private dire to root:ssl-cert
> and 755
> 4. Restart slapd
>
> and slapd restarted without any issues.
>
> I am able to search ldap using ldaps now instead of ldaps.
>
> But I have one issue remaining :
>
> I have the following entry in ldap.conf
>
> TLS_REQCERT allow
>
> The moment I change it to
>
> TLS_REQCERT demand
>
> the search starts throwing error :
>
> ---------------------------------------------------------
> # ldapsearch -d5 -x -H
ldaps://ldap-comany.com -b dc=ldap-comany,dc=com
> ldap_url_parse_ext(ldaps://ldap-comany.com)
> ldap_create
> ldap_url_parse_ext(ldaps://ldap-comany.com:636/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap-comany.com:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 127.0.1.1:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> ---------------------------------------------------------
>
> The port 636 is listening :
>
> ---------------------------------------------------------
> tcp 0 0 0.0.0.0:636 0.0.0.0:*
> LISTEN
> tcp6 0 0 :::10636 :::* LISTEN
> tcp6 0 0 :::636 :::* LISTEN
> ---------------------------------------------------------
>
> Is there anything else that I need to do further?
>
> Thanks again.
>
> -Asimananda
>
>
> On Tue, Jul 14, 2009 at 10:52 AM, Asimananda Mohanty <
> asimananda.mohanty(a)gmail.com> wrote:
>
>> Hi Matt,
>>
>> openldap user is already a part of ssl-cert group.
>>
>> Regarding apparmor, I am very much new to this. But I did some research
>> on this and did some changes like :
>>
>> 1. moving the /usr/sbin/slapd profile to complain mode and
>> 2. changing the following lines in /etc/apparmor.d/usr.sbin.slapd from :
>>
>> /etc/ssl/private/ r,
>> /etc/ssl/private/* r,
>>
>> to
>>
>> /etc/ssl/private/ mixr,
>> /etc/ssl/private/* mixr,
>>
>> After the changes, I did the following :
>>
>> /etc/init.d/apparmor stop*
>> * update-rc.d -f apparmor remove*
>>
>> */etc/init.d/apparmor start
>> update-rc.d apparmor defaults
>>
>> But it yields no positive result.
>>
>> Is there anything else that I need to do?
>>
>> Please let me know.
>>
>> Thank you very much for the reply.
>>
>> -Asimananda
>>
>>
>>
>> On Mon, Jul 13, 2009 at 8:29 PM, Matt Kassawara
<battery(a)writeme.com>wrote:
>>
>>> Make sure slapd can read the certs and private key. In addition to
>>> typical ownership and permissions, the openldap user should belong to the
>>> ssl-cert group and the slapd AppArmor profile must allow access to the
>>> directories containing your certs.
>>>
>>>
>>> On Mon, Jul 13, 2009 at 5:22 AM, Asimananda Mohanty <
>>> asimananda.mohanty(a)gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I ran the command "slapd -d 16383" and attached is the output
of the
>>>> same in case it may prove to be useful.
>>>>
>>>> In this output, ldap-company.com.crt is server.crt as defined in in my
>>>> earlier mails. I have changed it to try some luck, but it was
>>>> fruitless.
>>>>
>>>> -Asimananda
>>>>
>>>> On Mon, Jul 13, 2009 at 10:55 AM, Asimananda Mohanty <
>>>> asimananda.mohanty(a)gmail.com> wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> I created the certificates following the procedure defined in
>>>>>
https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html
>>>>>
>>>>> I created a CA and signed the certificate as defined the steps.
>>>>>
>>>>> The ownership is of openldap:openldap for cacert.pem and server.crt
>>>>> and openldap:ssl-cert for server.key.
>>>>>
>>>>> rwx permission is 644 for all the three.
>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>> -Asimananda
>>>>>
>>>>>
>>>>> On Fri, Jul 10, 2009 at 7:47 PM, Matt Kassawara
<battery(a)writeme.com>wrote:
>>>>>
>>>>>> How did you create the certificates? Can slapd read them?
>>>>>>
>>>>>> On Fri, Jul 10, 2009 at 5:00 AM, Asimananda Mohanty <
>>>>>> asimananda.mohanty(a)gmail.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I am currently busy configuring OpenLdap on my newly
installed
>>>>>>> Ubuntu 9.04.
>>>>>>>
>>>>>>> Here is what I have done till now.
>>>>>>>
>>>>>>> I followed the steps defined in
>>>>>>>
https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html and
>>>>>>> installation was successful. I installed PhpLdapAdmin also.
>>>>>>>
>>>>>>> After I created certificate, key etc, I created a .ldif file
>>>>>>> (enable-ca.ldif) with the following content :
>>>>>>>
>>>>>>> *dn: cn=config
>>>>>>> add: olcTLSCACertificateFile
>>>>>>> olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
>>>>>>> -
>>>>>>> add: olcTLSCertificateFile
>>>>>>> olcTLSCertificateFile: /etc/ssl/certs/server.crt
>>>>>>> -
>>>>>>> add: olcTLSCertificateKeyFile
>>>>>>> olcTLSCertificateKeyFile: /etc/ssl/private/server.key*
>>>>>>>
>>>>>>> Then I executed the command :
>>>>>>>
>>>>>>> *ldapmodify -D "cn=admin,cn=config" -x -w 12345678
-f
>>>>>>> enable-ca.ldif*
>>>>>>>
>>>>>>> and it was a success.
>>>>>>>
>>>>>>> But after this, when I tried to restart slapd, I got errors
like the
>>>>>>> following :
>>>>>>>
>>>>>>> *main: TLS init def ctx failed: -1*
>>>>>>>
>>>>>>> I noticed that after I executed "ldapmodify -D
"cn=admin,cn=config"
>>>>>>> -x -w 12345678 -f enable-ca.ldif", 3 lines are added to
>>>>>>> /etc/ldap/slapd.d/cn=config.ldif and when I commented the
last two
>>>>>>> lines like the following, slapd started successfully.
>>>>>>>
>>>>>>> *olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
>>>>>>> #olcTLSCertificateFile: /etc/ssl/certs/server.crt
>>>>>>> #olcTLSCertificateKeyFile: /etc/ssl/private/server.key*
>>>>>>>
>>>>>>> This looks quite strange.
>>>>>>>
>>>>>>> Please help me resolving the same.
>>>>>>>
>>>>>>> -Asimananda
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>