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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
