> On 08/22/2014 10:34 AM, Elizabeth Jones wrote:
>>> On 08/20/2014 03:58 PM, Elizabeth Jones wrote:
>>>> additional info -
>>>> I increased logging on my supplier and see this error now -
>>>>
>>>> TLS: hostname does not match CN in peer certificate
>>>>
>>>> When I created the replication agreement, it is giving me a default
>>>> consumer, I don't know why. The default is ldap1.mycompany.com:389.
>>>>
>>>> The certificate from ldap1 has just ldap1 as the name. I entered
>>>> ldap1
>>>> and port 636 when I created the agreement, but after I do this it
>>>> becomes
>>>> ldap1.mycompany.com:636. Would this be why its failing, it wants the
>>>> certificate to have
ldap1.mycompany.com in it rather than ldap1?
>>> Correct, you need to use the fully qualified domain name for
>>> certificates.
>>>
>>> Regards,
>>> Mark
>> ok - what is confusing to me is that another server is able to replicate
>> successfully to this server using this cert. I used the same script to
>> generate the certs on all 4 servers, the setupssl2.sh script.
> Hmm not sure, maybe /etc/hosts is different on each machine? But, I
> know you need to use the fully qualified domain name when doing anything
> "SSL". Might have to redo the SSL setup and make sure setupSSL2.sh is
> using the fully qualified domain name.
I checked my second server that is replicating successfully using this
cert and that server is not supplying a default consumer. The server that
is failing is supplying a default consumer ldap1.mycompany.com:389 and
whether I try to use ldap1:636 or ldap1.mycompany.com:636 it forces the
consumer to be ldap1.mycompany.com:636. Any idea where the failing server
would be finding this default consumer name, in an ldif somewhere? I had
a replication agreement in place using this consumer
(ldap1.mycompany.com:389) but had deleted the agreement before creating
the new replication agreement.
First look through the dse.ldif
(/etc/dirsrv/slapd-INSTANCE/dse.ldif).
It could also be in the database RUV, you might want to try and
reinitialize the consumer once the agreement is correctly setup. You
might also need to run cleanruv/cleanallruv:
EJ
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users