Replication with SSLCLIENTAUTH: server sent no certificate

[Eugen Lamers]

I'm trying to setup a replication with a certificate based authentication between
supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the
very same CA with which the respective server certificates in the certdbs have been
signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
The replication (on the supplier) has been setup such that TLS and certificate based
authentication is used, see extract from the replication agreement object:

objectclass: nsds5ReplicationAgreement
nsds5replicahost: <consumer-hostname>
nsds5replicaport: 389
nsds5replicatransportinfo: TLS
nsds5replicabindmethod: SSLCLIENTAUTH

Trying to initialize the consumer raises this error in the error-log of the supplier (the
host sending the starttls connection request):
  Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication)
(missing client certificate)

The certificate that the server should have sent can, however, be used with the ldap
commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the
client sends the certificate during the TLS handshake, while in the above case it
doesn't. 
The TLS handshake defines that the client has to send an "empty certificate" if
it does not have a certificate that has been issued by a CA offered by the server during
the handshake. I can't see a reason for the client to think the condition isn't
met. The certificate with which the server (supplier) is setup is the only one available.

Is it possible that the server does not know which certificate it has to use for
authentication with the consumer server? And if so, how do I make the server know?

The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with
1.4.0.3.

Thanks,
Eugen

[Mark Reynolds]

On 9/25/19 10:43 AM, Eugen Lamers wrote:
>  I'm trying to setup a replication with a certificate based
> authentication between supplier and consumer. The certificates in the certdb at
> /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server
> certificates in the certdbs have been signed. The certificates all have the 'u'
> flag, and the CA has the C and T flag.
>  The replication (on the supplier) has been setup such that TLS and certificate based
> authentication is used, see extract from the replication agreement object:
>
>  objectclass: nsds5ReplicationAgreement
>  nsds5replicahost: <consumer-hostname>
>  nsds5replicaport: 389
>  nsds5replicatransportinfo: TLS
>  nsds5replicabindmethod: SSLCLIENTAUTH
>
>  Trying to initialize the consumer raises this error in the error-log of the supplier (the
> host sending the starttls connection request):
>     Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate
> authentication) (missing client certificate) 
Replication does not use the server's certificate for SSL Client 
Authentication.  It uses the client certificate in the "Replication 
Manager" entry.  Sounds like you did not add a user certificate to this 
entry.

Look at this for help with adding a client certificate to a user entry:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...

Note - the client certificate you use in the replication manager but be 
issued by the same CA that the all the replicas are using.

HTH,

Mark


>  The certificate that the server should have sent can, however, be used with the ldap
> commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the
> client sends the certificate during the TLS handshake, while in the above case it
> doesn't.
>  The TLS handshake defines that the client has to send an "empty certificate" if
> it does not have a certificate that has been issued by a CA offered by the server during
> the handshake. I can't see a reason for the client to think the condition isn't
> met. The certificate with which the server (supplier) is setup is the only one available.
>  Is it possible that the server does not know which certificate it has to use for
> authentication with the consumer server? And if so, how do I make the server know?
>
>  The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with
> 1.4.0.3.
>
>  Thanks,
>  Eugen
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  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/[e-mail]... 
-- 

389 Directory Server Development Team

[William Brown]

>  On 26 Sep 2019, at 00:58, Mark Reynolds <mreynolds(a)redhat.com&gt;
> wrote:
>  
>  
>  On 9/25/19 10:43 AM, Eugen Lamers wrote:
> > I'm trying to setup a replication with a certificate based authentication between
> supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the
> very same CA with which the respective server certificates in the certdbs have been
> signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
> > The replication (on the supplier) has been setup such that TLS and certificate based
> authentication is used, see extract from the replication agreement object:
> > 
> > objectclass: nsds5ReplicationAgreement
> > nsds5replicahost: <consumer-hostname>
> > nsds5replicaport: 389
> > nsds5replicatransportinfo: TLS
> > nsds5replicabindmethod: SSLCLIENTAUTH
> > 
> > Trying to initialize the consumer raises this error in the error-log of the supplier
> (the host sending the starttls connection request):
> >   Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate
> authentication) (missing client certificate)
>  
>  Replication does not use the server's certificate for SSL Client Authentication.  It
> uses the client certificate in the "Replication Manager" entry.  Sounds like you
> did not add a user certificate to this entry.
>  
>  Look at this for help with adding a client certificate to a user entry:
>  
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>  
>  Note - the client certificate you use in the replication manager but be issued by the
> same CA that the all the replicas are using. 
I think there is also a test case somewhere in the server that uses TLS auth for the
replication manager

https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/repl...

It might help give you some ideas on how this works,

>  
>  HTH,
>  
>  Mark
>  
>  
> > 
> > The certificate that the server should have sent can, however, be used with the ldap
> commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the
> client sends the certificate during the TLS handshake, while in the above case it
> doesn't.
> > The TLS handshake defines that the client has to send an "empty
> certificate" if it does not have a certificate that has been issued by a CA offered
> by the server during the handshake. I can't see a reason for the client to think the
> condition isn't met. The certificate with which the server (supplier) is setup is the
> only one available.
> > Is it possible that the server does not know which certificate it has to use for
> authentication with the consumer server? And if so, how do I make the server know?
> > 
> > The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same
> with 1.4.0.3.
> > 
> > Thanks,
> > Eugen
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> > 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/[e-mail]...
>  
>  -- 
>  
>  389 Directory Server Development Team
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Eugen Lamers]

Hi Mark,

>  Replication does not use the server's certificate for SSL Client
>
>  Authentication.  It uses the client certificate in the "Replication 
>  Manager" entry.  Sounds like you did not add a user certificate to this 
>  entry. 
Your hint seems to clarify something. Thanx for that.
First this lead me to the chapter in the documentation which I didn't step over
before:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
From there I understand that there needs to be an account entry on the supplier
corresponding to the supplier's hostname, and that I need to add a client certificate
to that entry. It says "Both servers will later use these accounts and certificates
to authenticate when they establish a replication connection to each other." So I did
that and put the server certificate (issued by the same CA, 'u' flag set) to the
account entry. Furthermore as shown in the chapter I put the account entries to a group
which is referenced (nsds5replicabinddngroup) in the replica entry on the supplier. 
I skipped the steps with the temporary replication manager account (with password) and
agreement, because I setup the two servers in parallel so I make sure the accounts with
the certificates on the consumer do already exist when initializing the replication.

Result for now: Still doesn't work. The supplier doesn't send the certificate in
the account entry at "cn=supplierhost,dc=..." of the supplier's database. It
doesn't send any certificate.

This brings me to another question to you: The replication manager entry is the entry on
the consumer server from the perspective of the supplier that starts the replication. From
where does the supplier take the certificate in a single master scenario where there is no
replication manager account on its side? 
Somehow there is still a missing link between the supplier's hostname and the place
for the supplier to get the certificate from to use it in the TLS handshake with the
consumer.

Regards,
Eugen

[Eugen Lamers]

Hi William,

>  I think there is also a test case somewhere in the server that uses
> TLS auth for the
>  replication manager
>  
>  https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/repl... 
unfortunately we updated to the 1.4.1er 389ds which doesn't have the lib389 python
module any longer. What I tried to extract from the source code is the setting of
"default:CmapLdapAttr nsCertSubjectDN" in the certmap.conf. It didn't help
either.

Regards,
Eugen

[William Brown]

>  On 26 Sep 2019, at 19:30, Eugen Lamers
> <eugen.lamers(a)br-automation.com&gt; wrote:
>  
>  Hi William,
>  
> > I think there is also a test case somewhere in the server that uses TLS auth for the
> > replication manager
> > 
> > https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/repl...
>  
>  unfortunately we updated to the 1.4.1er 389ds which doesn't have the lib389 python
> module any longer. What I tried to extract from the source code is the setting of
> "default:CmapLdapAttr nsCertSubjectDN" in the certmap.conf. It didn't help
> either. 
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? 

Also 1.4.1 *should* have lib389, so I'm curious what distro and platform you are
using? It should be present .... 

>  
>  Regards,
>  Eugen
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Eugen Lamers]

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

[William Brown]

>  On 27 Sep 2019, at 17:42, Eugen Lamers
> <eugen.lamers(a)br-automation.com&gt; wrote:
>  
>  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... 
That shouldn't be a problem I think .... 

>  
>  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.
I think you need the replication manager entries. So to explain. When the TLS connection
is made by hostname1 to hostname2, on hostname2 the SASL mech of EXTERNAL is provided, so
the bind code looks at other possible authentication factors. The client certificate
provided is then inspected. 

The hostname1 client certificate must be signed by a CA that is accepted and trusted for
client auth in the nssdb on hostname2. You can check this with certutil

{root@ldapkdc 9:48} /data/config I0> certutil -L -d .

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Self-Signed-CA                                               CT,,
Server-Cert                                                  u,u,u

Notice the "CT,,". That means it's trusted as a server and client CA. You
can see the trust flags from -A:

{root@ldapkdc 9:49} /data/config I0> certutil -A --help
...
   -t trustargs      Set the certificate trust attributes:
                          trustargs is of the form x,y,z where x is for SSL, y is for
S/MIME,
                          and z is for code signing. Use ,, for no explicit trust.
                          p 	 prohibited (explicitly distrusted)
                          P 	 trusted peer
                          c 	 valid CA
                          T 	 trusted CA to issue client certs (implies c)
                          C 	 trusted CA to issue server certs (implies c)
                          u 	 user cert
                          w 	 send warning
                          g 	 make step-up cert

And then modify them with -M:

{root@ldapkdc 9:48} /data/config I0> certutil -M --help
-M              Modify trust attributes of certificate
   -n cert-name      The nickname of the cert to modify
   -t trustargs      Set the certificate trust attributes (see -A above)
   -d certdir        Cert database directory (default is ~/.netscape)
   -P dbprefix       Cert & Key database prefix


So back to TLS processing - now the server has validated the client cert, we head into the
certmap code - we *only* have the certificate so we need to be able to look up that
certificate to a user somehow. Certmap.conf is processed in a specific order  (that I
can't remember right now :) ). One of the simplest methods is "DNComp",
where the DN of the cert must match and be in order of the DN in the directory.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...

But if you set certmap to look like:

certmap default         default
default:CmapLdapAttr nsCertSubjectDN

So this means: when an incomming SASL external is found, and you have TLS, take the
certificate subjectDN and do an ldapsearch for it in each available backend.

This has a specific implication though. You need an entry that looks like:

dn: cn=hostname1,cn=config
cn: hostname1
nsCertSubjectDN: <subject of hostname1 cert>


Each server will need these entries for all possible incoming servers.

You can also make these entries in your main database such as:

cn=hostname1,ou=replicationmanagers,dc=example,dc=com
cn: hostname1
nsCertSubjectDN: <subject of hostname1 cert>


The benefit of this is you have the replication managers in "one place" and they
are literally replicated, so you don't need so much per-server configuration. The
issue is a chicken-and-egg bootstrap where you can't start replication until ... you
start replication. So youcan bootstrap either with PW auth on the repl manager, or you can
do a db2ldif -r on the first master, and import that on the second so the replication
metadata is available. 


I hope this helps: in general I think TLS auth on replication is really hard to setup and
do properly. I did it as part of lib389 to automate the tests and it was a challenging
process to setup, and that's coming from someone who is literally a developer on the
project. It's also super dense/hard to debug when it goes wrong. 

I prefer to either have the simple replication manager  + pw setup, or have the per-host
replication manager in the maindb but with pw again. 

Anyway, hope that helps give you advice on what you may be missing :) 


>  
>  Regards,
>  Eugen
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Eugen Lamers]

Hello William,

>  I think you need the replication manager entries. So to explain. When
> the TLS connection
>  is made by hostname1 to hostname2, on hostname2 the SASL mech of EXTERNAL is provided,
> so
>  the bind code looks at other possible authentication factors. The client certificate
>  provided is then inspected.  
This obviously is my main problem: The client (supplier in this case) does not provide a
certificate. wireshark confirms this. What I wonder is how to tell the supplier which
certificate to use or where to find it.

>  The hostname1 client certificate must be signed by a CA that is
> accepted and trusted for
>  client auth in the nssdb on hostname2. You can check this with certutil
>  
>  {root@ldapkdc 9:48} /data/config I0> certutil -L -d .
>  
>  Certificate Nickname                                         Trust Attributes
>                                                               SSL,S/MIME,JAR/XPI
>  
>  Self-Signed-CA                                               CT,,
>  Server-Cert                                                  u,u,u
>  
>  Notice the "CT,,". That means it's trusted as a server and client CA. You
>  can see the trust flags from -A:
>  
>  {root@ldapkdc 9:49} /data/config I0> certutil -A --help
>  ...
>     -t trustargs      Set the certificate trust attributes:
>                            trustargs is of the form x,y,z where x is for SSL, y is for
>  S/MIME,
>                            and z is for code signing. Use ,, for no explicit trust.
>                            p 	 prohibited (explicitly distrusted)
>                            P 	 trusted peer
>                            c 	 valid CA
>                            T 	 trusted CA to issue client certs (implies c)
>                            C 	 trusted CA to issue server certs (implies c)
>                            u 	 user cert
>                            w 	 send warning
>                            g 	 make step-up cert
>  
>  And then modify them with -M:
>  
>  {root@ldapkdc 9:48} /data/config I0> certutil -M --help
>  -M              Modify trust attributes of certificate
>     -n cert-name      The nickname of the cert to modify
>     -t trustargs      Set the certificate trust attributes (see -A above)
>     -d certdir        Cert database directory (default is ~/.netscape)
>     -P dbprefix       Cert & Key database prefix 
All these conditions are met already. 

>  So back to TLS processing - now the server has validated the client
> cert, we head into the
>  certmap code - we *only* have the certificate so we need to be able to look up that
>  certificate to a user somehow. Certmap.conf is processed in a specific order  (that I
>  can't remember right now :) ). One of the simplest methods is "DNComp",
>  where the DN of the cert must match and be in order of the DN in the directory.
>  
>  https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>  
>  But if you set certmap to look like:
>  
>  certmap default         default
>  default:CmapLdapAttr nsCertSubjectDN
>  
>  So this means: when an incomming SASL external is found, and you have TLS, take the
>  certificate subjectDN and do an ldapsearch for it in each available backend.
>  
>  This has a specific implication though. You need an entry that looks like:
>  
>  dn: cn=hostname1,cn=config
>  cn: hostname1
>  nsCertSubjectDN: <subject of hostname1 cert>
>  
>  
>  Each server will need these entries for all possible incoming servers.
>  
>  You can also make these entries in your main database such as:
>  
>  cn=hostname1,ou=replicationmanagers,dc=example,dc=com
>  cn: hostname1
>  nsCertSubjectDN: <subject of hostname1 cert>
>  
>  
>  The benefit of this is you have the replication managers in "one place" and
> they
>  are literally replicated, so you don't need so much per-server configuration. The
>  issue is a chicken-and-egg bootstrap where you can't start replication until ... you
>  start replication. So youcan bootstrap either with PW auth on the repl manager, or you
> can
>  do a db2ldif -r on the first master, and import that on the second so the replication
>  metadata is available.  
It shouldn't be a problem to create these entries in the db of the consumer, but since
the consumer doesn't see a certificate coming from the supplier, there is nothing to
be mapped or bound. 

>  I hope this helps: in general I think TLS auth on replication is
> really hard to setup and
>  do properly. I did it as part of lib389 to automate the tests and it was a challenging
>  process to setup, and that's coming from someone who is literally a developer on the
>  project. It's also super dense/hard to debug when it goes wrong. 
>  
>  I prefer to either have the simple replication manager  + pw setup, or have the per-host
>  replication manager in the maindb but with pw again.  
I will take your advice into consideration, even if I'm somehow going to be successful
with the challenge. Is there any way to avoid plaintext passwords for the replication
manager entries in LDIF files or the setup.inf for the setup-ds(-admin).pl scripts, I mean
other than entering the passwords within the 389-console?

Thanx for you effort. Best,
Eugen

[William Brown]

>  On 30 Sep 2019, at 16:48, Eugen Lamers
> <eugen.lamers(a)br-automation.com&gt; wrote:
>  
>  Hello William,
>  
> > I think you need the replication manager entries. So to explain. When the TLS
> connection
> > is made by hostname1 to hostname2, on hostname2 the SASL mech of EXTERNAL is
> provided, so
> > the bind code looks at other possible authentication factors. The client certificate
> > provided is then inspected. 
>  
>  This obviously is my main problem: The client (supplier in this case) does not provide a
> certificate. wireshark confirms this. What I wonder is how to tell the supplier which
> certificate to use or where to find it. 
Is your Server-Cert marked with trust flags u? see:

>  
> > The hostname1 client certificate must be signed by a CA that is accepted and trusted
> for
> > client auth in the nssdb on hostname2. You can check this with certutil
> > 
> > {root@ldapkdc 9:48} /data/config I0> certutil -L -d .
> > 
> > Certificate Nickname                                         Trust Attributes
> >                                                             SSL,S/MIME,JAR/XPI
> > 
> > Self-Signed-CA                                               CT,,
> > Server-Cert                                                  u,u,u 

^ here. Server-Cert needs u,, at least (I think the u,u,u may be incorrect actually).

> > 
> > Notice the "CT,,". That means it's trusted as a server and client CA.
> You
> > can see the trust flags from -A:
> > 
> > {root@ldapkdc 9:49} /data/config I0> certutil -A --help
> > ...
> >   -t trustargs      Set the certificate trust attributes:
> >                          trustargs is of the form x,y,z where x is for SSL, y is for
> > S/MIME,
> >                          and z is for code signing. Use ,, for no explicit trust.
> >                          p 	 prohibited (explicitly distrusted)
> >                          P 	 trusted peer
> >                          c 	 valid CA
> >                          T 	 trusted CA to issue client certs (implies c)
> >                          C 	 trusted CA to issue server certs (implies c)
> >                          u 	 user cert
> >                          w 	 send warning
> >                          g 	 make step-up cert
> > 
> > And then modify them with -M:
> > 
> > {root@ldapkdc 9:48} /data/config I0> certutil -M --help
> > -M              Modify trust attributes of certificate
> >   -n cert-name      The nickname of the cert to modify
> >   -t trustargs      Set the certificate trust attributes (see -A above)
> >   -d certdir        Cert database directory (default is ~/.netscape)
> >   -P dbprefix       Cert & Key database prefix
>  
>  All these conditions are met already. 
>  
> > So back to TLS processing - now the server has validated the client cert, we head
> into the
> > certmap code - we *only* have the certificate so we need to be able to look up that
> > certificate to a user somehow. Certmap.conf is processed in a specific order  (that
> I
> > can't remember right now :) ). One of the simplest methods is
> "DNComp",
> > where the DN of the cert must match and be in order of the DN in the directory.
> > 
> > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
> > 
> > But if you set certmap to look like:
> > 
> > certmap default         default
> > default:CmapLdapAttr nsCertSubjectDN
> > 
> > So this means: when an incomming SASL external is found, and you have TLS, take the
> > certificate subjectDN and do an ldapsearch for it in each available backend.
> > 
> > This has a specific implication though. You need an entry that looks like:
> > 
> > dn: cn=hostname1,cn=config
> > cn: hostname1
> > nsCertSubjectDN: <subject of hostname1 cert>
> > 
> > 
> > Each server will need these entries for all possible incoming servers.
> > 
> > You can also make these entries in your main database such as:
> > 
> > cn=hostname1,ou=replicationmanagers,dc=example,dc=com
> > cn: hostname1
> > nsCertSubjectDN: <subject of hostname1 cert>
> > 
> > 
> > The benefit of this is you have the replication managers in "one place" and
> they
> > are literally replicated, so you don't need so much per-server configuration.
> The
> > issue is a chicken-and-egg bootstrap where you can't start replication until ...
> you
> > start replication. So youcan bootstrap either with PW auth on the repl manager, or
> you can
> > do a db2ldif -r on the first master, and import that on the second so the
> replication
> > metadata is available. 
>  
>  It shouldn't be a problem to create these entries in the db of the consumer, but
> since the consumer doesn't see a certificate coming from the supplier, there is
> nothing to be mapped or bound.  
Yep. See above.

>  
> > I hope this helps: in general I think TLS auth on replication is really hard to setup
> and
> > do properly. I did it as part of lib389 to automate the tests and it was a
> challenging
> > process to setup, and that's coming from someone who is literally a developer on
> the
> > project. It's also super dense/hard to debug when it goes wrong. 
> > 
> > I prefer to either have the simple replication manager  + pw setup, or have the
> per-host
> > replication manager in the maindb but with pw again. 
>  
>  I will take your advice into consideration, even if I'm somehow going to be
> successful with the challenge. Is there any way to avoid plaintext passwords for the
> replication manager entries in LDIF files or the setup.inf for the setup-ds(-admin).pl
> scripts, I mean other than entering the passwords within the 389-console? 
Well, they all end up in dse.ldif anyway. Because of the replication manager's nature
it well ... has to be reversible to the process. We need to get the plaintext password
somehow to initiate the bind. Additionally, any DN listed in a replication agreement as a
replication manager has ACI's not evaluated in many cases due to needing a high level
of access to perform it's function. 

Saying this you need to say what's your threat model - if someone has access to
dse.ldif and the content within in they can easily change the ldapi-autobind flag, then
change directory content anyway. They may also have access to pin.txt and the nss certdb
so they have your private key you're using for auth for replication anyway .... so is
cert really more secure than a pw in dse.ldif? The threat is "someone has access to
the machine and /etc as root/dirsrv". Once someone has access to one master in a
replication topoolgy, they also can add entries which would give you root
access/persistence on other hosts, so attacking replication is a low value target.
You'd just put another user into the administrators group in the directory so you can
ssh to whatever you want. 

If you are worried about MITM, TLS already protects you here as does the proper CA
verification which replication will already be doing for you. 

I think that will give you some more to thing about in you decision making and risk
assessment process. Very happy to discuss what your risks and threats are so we can work
out what's going to be practical.


>  
>  Thanx for you effort. Best,
>  Eugen 
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Eugen Lamers]

Hi William,
it's an old thread, but it's mine, so I will give an update to the situation and a
follow-up question.
We changed from StartTLS on 389 to SSL on 636 some time ago. Trying to reconsider the
topic we found that there is no plaintext password sent via network between the
replicants, which was the case in the StartTLS on 389 scenario. This would reduce the
problem with plaintext password for the replication manager to the storage, mainly the
dse.ldif, I think. 
We would be glad if you could confirm this thought. It would save us from trying again the
use of client auth for replication which hadn't been successful yet.
Kind regards,
Eugen

[William Brown]

>  On 1 Feb 2021, at 23:35, Eugen Lamers
> <eugen.lamers(a)br-automation.com&gt; wrote:
>  
>  Hi William,
>  it's an old thread, but it's mine, so I will give an update to the situation and
> a follow-up question.
>  We changed from StartTLS on 389 to SSL on 636 some time ago. Trying to reconsider the
> topic we found that there is no plaintext password sent via network between the
> replicants, which was the case in the StartTLS on 389 scenario. This would reduce the
> problem with plaintext password for the replication manager to the storage, mainly the
> dse.ldif, I think.  
To be sure, I'd need to see your configured replication agreement to understand how
it's been configured to authenticate.

Provided you are using SSL (LDAPS) and simple bind, then the password *is* sent to the
other server, but it's inside of TLS so it is secure. 

>  We would be glad if you could confirm this thought. It would save us
> from trying again the use of client auth for replication which hadn't been successful
> yet.
>  Kind regards, 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia