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