[389-users] secure replication failing

[Elizabeth Jones]

I rebuilt the cert on my ldap1 server to use the fully qualified name and
now replication is working. I hacked the setupssl2.sh script some, I don't
recall whether this was the original code or not but it was using
myhost=`hostname` for the server name.  I used this on all 4 of my servers
and none of them returned the fully qualified name for the certs, but only
one had a problem with it.  I changed it from hostname to the fully
qualified name in the script.

Elizabeth


>
> On 08/25/2014 10:21 AM, Elizabeth Jones wrote:
>>> 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:
> http://port389.org/wiki/Howto:CLEANRUV
>>
>> EJ
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>