Re: Antw: need serious help ton repliIcation over ssl - getting do_syncrep1: rid 001 ldap_sasl_bind_s failed (-1)do

[wailok tam <wailoktam@yahoo.com>]

A deep bow.

You have helped me to conclude that I am having a ssl certs problem, rather than a ldap conf problem.keys 

I do openssl s_ client fr the master to the slave and vice versa. neither works.
 
Do you mind telling me roughly or pointing me  resources that explain what to do after i get an ok with openssl verify on the master?
What to do to get the master to let the slave to connect and perform the syncrepl task.
 
I have read some guides which tell me to concatenate the ca cert of the master to that of the slave. some others tell me to use the the ca cert of the
master for the slave. so what to do? do the certs and keys have to be shared in some way like setting up ssh? Thanks again in advance.





------------------------------order
On Wed, Dec 3, 2014 8:00 AM GMT Ulrich Windl wrote:

>>> wailok tam <wailoktam@yahoo.com> schrieb am 03.12.2014 um 07:13 in
>Nachricht
><174796963.2591360.1417587204114.JavaMail.yahoo@jws100175.mail.ne1.yahoo.com>:
>
>ªpHi, thanks for your reply.
>I move the ca cert on the slave, generate a hash of it 
>openssl x509 -noout -hash -in ca-certificate-file
>
>and create a symbolic link from the hash 
>ln -s my_ca.crt RESULT_OF_OPENSSL_X509-NOOUT-HASH
>
>Then I do an openssl verify -CApath and -CAfile on the slave. I get an okay.
>So I have done the rehash step you mentioned? I dont have a rehash program on
>my system. You don't have the c_rehash?
>
>For me it's part of openssl:
>% rpm -qf /usr/bin/c_rehash
>openssl-0.9.8j-0.66.1
>
>Another thing I do is to remove all the SSL relevant lines from the conf of
>both the master and the slave and it works. 
>So can I be certain that the problem is with the certs of the master which
>generates the following errors?
>openssl verify -CApath /usr/share/ssl/certs/nii-odca2.crt
>/usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt/usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt:
>/C=JP/L=Academe2/O=Hitotsubashi University/OU=Institute of Economic
>Research/CN=mail.ier.hit-u.ac.jperror 20 at 0 depth lookup:unable to get local
>issuer certificate
>
>"unable to get local issuer certificate" says it all: the certificate that
>signed your certificate cannot be found, and thus the certificate is considered
>invalid. If the issuer cert is there, make sure it's hashed (as above);
>otherwise openssl cannot use it.
>
>
>verify -CAfile /usr/share/ssl/certs/nii-odca2.crt
>/usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt/usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt:
>/C=JP/L=Academe2/O=National Institute of Informatics/OU=UPKI/OU=NII Open Domain
>CA - G2error 2 at 1 depth lookup:unable to get issuer certificate
>What do these error mean? 
>
>See above.
>
>I also find some strange behaviour on the master. When I ping the slave using
>its host name, it shows a different ip and it fails. When I ping the slave
>using its ip, it succeeds. Can this be relevant?
>
>Try "nslookup slave" to find out 
>
>Many thanks in advance.
>
>(Sorry, my mailer refused to quote your message correctly)
>
>
>
>
>      From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
> To: openldap-technical@openldap.org; wailoktam@yahoo.com 
> Sent: Monday, December 1, 2014 9:13 PM
> Subject: Re: Antw: need serious help on replication over ssl - getting
>do_syncrep1: rid 001 ldap_sasl_bind_s failed (-1)
>   
>>> wailok tam <wailoktam@yahoo.com> schrieb am 01.12.2014 um 12:48 in
>Nachricht
><1417434525.8955.BPMail_high_carrier@web122503.mail.ne1.yahoo.com>:
>
>> Hi, thanks again for offering further help.
>> 
>> Is what you suggesting, c_rehash, equivalent to updating the certificate 
>> database, just like what  the
>> update-ca-certificate script would do in debian- based distro? I  did not do
>
>> this rehash thing.
>
>c_rehash creates a symbolic link for each CA, like this:
>lrwxrwxrwx 1 root root 26 Jul  7 08:43 /etc/ssl/certs/a7605362.0 ->
>Sonera_Class_2_Root_CA.pem
>
>If no such link for your CA exists, openssl fails to find it (AFAIK).
>
>> In the master, I am using an old set of certs which I suppose to be working.
>
>
>Define "an old set of certs", please.
>
>> In the slave, I put all the certs in the directory they were first 
>> gen.erated, as given in the conf file. Will rehash work properly with the 
>> certs in those paths (i.e. /etc/pki/CA/)?I
>
>It seems you can give the directory as parameter:
>windl@rksapv04:~/src/C> c_rehash /tmp
>Doing /tmp
>
>
>
>> 
>>  So what to do with the output of openssl x509 -noout -text -in 
>> <your_certificate>?
>> 
>> I cannot try it now. I have tried sth similar a couple of hours ago that 
>> output the content of a cert in text. For the master, the issuer is an 
>> external orgaization which we bought the cert from. For the slave, the
>issuer 
>> is my orgaization since I generate it myself. I follow the guide in the link
>
>> to paste the master ca cert after the orig slave ca cert. Does that strange
>
>> instruction screw things up?I
>
>Repeat the openssl verify commands until they work!
>
>
>
>> 
>> Thanks again in advance.
>> 
>> 
>> ------------------------------
>> On Mon, Dec 1, 2014 11:05 AM GMT Ulrich Windl wrote:
>> 
>>> wailok tam <wailoktam@yahoo.com> schrieb am 01.12.2014 um 11:40 in
>Nachricht
>><1171333883.1885274.1417430400586.JavaMail.yahoo@jws100208.mail.ne1.yahoo.com>:
>>> Hi, thanks for your help. I am getting this on the master, no matter I put
>
>>> /usr/share/ssl/certs or /usr/share/ssl/certs/nii-odca2.crt for the first 
>>> argument after -CApath
>>> /usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt: 
>>> /C=JP/L=Academe2/O=Hitotsubashi University/OU=Institute of Economic 
>>> Research/CN=mail.ier.hit-u.ac.jperror 20 at 0 depth lookup:unable to get 
>>> local issuer certificateunable to load certificate12574:error:0906D06C:PEM
>
>>> routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED 
>>> CERTIFICATE
>>
>>So you have a problem with your issuer certificate: Did you use c_rehash 
>> after adding a CA certificate to /etc/ssl/certs? If so, dump your 
>> certificates (CA and server) like this
>>openssl x509 -noout -text -in <your_certificate>
>>and examine "Issuer" and "Subject" at least.
>>
>>Regards,
>>Ulrich
>>
>>> for slave, I am also getting:
>>> /etc/pki/tls/misc/newcert.pem: /C=JP/ST=Tokyo/L=Kunitachi/O=Hitotsubashi 
>>> Univ./OU=IER/CN=blade-s00.ier.hit-u.ac.jperror 20 at 0 depth lookup:unable
>to 
>>> get local issuer certificateunable to load 
>>> certificate25730:error:0906D06C:PEM routines:PEM_read_bio:no start 
>>> line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE
>>> no matter I put the /etc/pki/CA/ or /etc/pki/CA/cacert.pem for the first 
>>> argument after -CApath
>>> Any clue? Thanks again in advance. I did not do update-ca-certificates, as
>
>>> mentioned in some books,  on both the master and the slave. First, on the
>
>>> master, I need to use existing cert . So I suppose I dont need to update
>it. 
>> 
>>> Second, I dont know where this command is located on RH...Is that
>relevant?
>>> 
>>>      From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
>>>  To: openldap-technical@openldap.org; wailoktam@yahoo.com 
>>>  Sent: Monday, December 1, 2014 7:08 PM
>>>  Subject: Antw: need serious help on replication over ssl - getting 
>>> do_syncrep1: rid 001 ldap_sasl_bind_s failed (-1)
>>>    
>>> wailok tam <wailoktam@yahoo.com> schrieb am 01.12.2014 um 10:04 in
>Nachricht
>>> 
>>> 
>>>
><674598213.1863113.1417424697693.JavaMail.yahoo@jws10083.mail.ne1.yahoo.com>:
>>> Hi, I would really be grateful if a nice guy would appear and save me with
>
>>> this one. Simple bind replication over ldaps port does not work. I don't 
>>> have 
>>> a clue. There are very few guides on setting  up replication over ldaps on
>
>>> the  web or on prints. I am following this one as I am using RH:
>>> 
>>> Verifying your SSL certificates:
>>> Try this (preferrably as the same user that slapd uses):
>>> # openssl verify -CApath /etc/ssl/certs /etc/ssl/servercerts/slapd.pem
>>> /etc/ssl/servercerts/slapd.pem: OK
>>> 
>>> If (you are using openssl and) it works, your certificate should be OK; if
>
>>> not fix it and repeat the test.
>>> 
>>> [...]
>>> 
>>> I'd leave out the "tls_cert=" to switch to automatic cert selection; if
>that 
>> 
>>> soesn't work, something is wrong with your setup; if it works, you can try
>
>> to 
>>> use a fixed certificate.
>>> 
>>> Then you could try a manual remote TLS (not SSL) connect (e.g. ldapsearch)
>
>>> to your master; if it doesn't work, fix the config and repeat the test.
>Try  
>> 
>>> to retrieve the whole database; if it works, you are quite close, I
>guess.
>>> 
>>> Turn on logging for "config" and "sync" at least. Try some modification on
>
>>> the master and watch what happens...
>>> 
>>> Regards,
>>> Ulrich
>>> 
>>> 
>>> 
>>>  
>>
>>
>>
>>
>
>
>
>
>  
>