Hi William, > Can you send in your certmap.conf and any of the relevant parts of dse.ldif so I can have > a look at what you configured? dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed CACertExtractFile: /etc/dirsrv/slapd-hostname1_local/ca.pem numSubordinates: 1 dn: cn=RSA,cn=encryption,cn=config objectClass: top objectClass: nsEncryptionModule cn: RSA nsSSLPersonalitySSL: hostname1.domain.com nsSSLActivation: on nsSSLToken: internal (software) dn: cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=domain,dc=com nsDS5ReplicaId: 12 nsDS5ReplicaType: 3 nsDS5Flags: 1 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaName: b38325b1-e0f011e9-9cdcc130-abdc2534 numSubordinates: 1 dn: cn=hostname1,cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsds5ReplicationAgreement nsDS5ReplicaHost: hostname2.domain.com nsDS5ReplicaPort: 389 nsDS5ReplicaTransportInfo: TLS nsDS5ReplicaBindMethod: SSLCLIENTAUTH nsDS5ReplicaRoot: dc=domain,dc=com description: Agreement between hostname2 and hostname1 cn: hostname1 Don't know if this extract contains what you need to know... > Also 1.4.1 *should* have lib389, so I'm curious what distro and platform you are > using? It should be present .... Problem is, we currently use a 389ds version that is higher than the one "included" in our distro, which is SLE 12 SP3. We need to clarify on our side if the mix of packages (389ds, console, etc.) is consistent... Would you recommend, as I understood Mark Reynolds, to use a "replication manager" entry on both servers and put the very same certificate to it with a appropriate subjectDN like "cn=replication manager"? Currently I use, as stated in my other mail, a setup as recommended in the admin guide of redhat ds 10, which is a supplier DN with the "cn=<fq-serverhostname>" on the consumer, and to which the certificate of the supplier server is put. But the supplier does not send any certificate to the consumer in the TLS handshake. So I don't this the certmap is involved, since it is used on the receiver of the certificate to decide to which entry the certificate should be bound, but the problem occurs already on the sender side. Anyway, the certmap: certmap default default default:DNComps default:FilterComps cn default:verifycert off Adding "default:CmapLdapAttr nsCertSubjectDN" didn't change anything. Regards, Eugen _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
