Bug 1902303

Upstream ticket:

https://github.com/389ds/389-ds-base/issues/4460

You need to setup the .dsrc file for this to work.  See comment 6:  https://bugzilla.redhat.com/show_bug.cgi?id=1902303#c6

The problem is that when you use a LDAPURL with dsconf you are not specifying an instance.  So it has no idea if it the LDAP URL is local or not, and what slapd instance it is referring to.  So dsconf has no idea where to look for the certificate directory.  Setting up the .dsrc file sets these defaults so dsconf knows where to find the correct paths.  Moving back to ON_QA.

I think dsconf could be hardened to provide an error instead of crashing, but that would be a new bug.

Moving back to ASSIGNED.  We should respect the settings in ldap.conf if .dsrc is not set.

Build Tested: 389-ds-base-1.4.3.25-1.module+el8dsrv+12110+4144c5dd.x86_64

[root@localhost ~]# dsconf -v -D "cn=Directory Manager" -w password  ldaps://localhost:636 security certificate list
DEBUG: The 389 Directory Server Configuration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: dsrc path: /root/.dsrc
DEBUG: dsrc container path: /data/config/container.inf
DEBUG: dsrc instances: []
DEBUG: dsrc no such section: slapd-ldaps://localhost:636
DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='password', func=<function cert_list at 0x7fc6dc70aae8>, instance='ldaps://localhost:636', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True)
DEBUG: Instance details: {'uri': 'ldaps://localhost:636', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': None, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldaps://localhost:636', 'root-dn': 'cn=Directory Manager'}}
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://localhost:636
DEBUG: Allocate <class 'lib389.DirSrv'> with localhost:636
DEBUG: Allocate <class 'lib389.DirSrv'> with localhost:636
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://localhost:636
DEBUG: Allocate <class 'lib389.DirSrv'> with localhost:636
DEBUG: Allocate <class 'lib389.DirSrv'> with localhost:636
DEBUG: open(): Connecting to uri ldaps://localhost:636
DEBUG: Using /etc/openldap/ldap.conf certificate policy
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 2
DEBUG: open(): bound as cn=Directory Manager
DEBUG: Retrieving entry with [('',)]
DEBUG: Retrieved entry [dn: 
vendorVersion: 389-Directory/1.4.3.25 B2021.215.1707

]
DEBUG: Retrieving entry with [('cn=config',)]
DEBUG: Retrieved entry [dn: cn=config
nsslapd-certdir: /etc/dirsrv/slapd-localhost

]
DEBUG: display_cert_details cmd: /usr/bin/certutil -d /etc/dirsrv/slapd-localhost -n Server-Cert -L -f /etc/dirsrv/slapd-localhost/pwdfile.txt
INFO: Certificate Name: Server-Cert
INFO: Subject DN: CN=localhost.example.com,givenName=5b698ef3-da26-4191-abd8-f8d36e5e466b,O=testing,L=389ds,ST=Queensland,C=AU
INFO: Issuer DN: CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C=AU
INFO: Expires: 2023-08-19 12:46:20
INFO: Trust Flags: u,u,u

INFO: Command successful.

Settings in ldap.conf file is respected if .dsrc is not set.

Marking as VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: redhat-ds:11 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:3955

Will this fix also be added to the RHEL 8 389ds package?