> Hi, thanks again for offering further help.
> this rehash thing.
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.
> gen.erated, as given in the conf file. Will rehash work properly with the
> certs in those paths (i.e. /etc/pki/CA/)?I
> 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
>
> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>>