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.
EJ