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