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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users