Hi William, thanks for your reply. Our managed by dsconf LDAP is signed by a commercial certificate, and both intermediate certificates are added to system bundles using "trust anchor" or "update-ca-trust" (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-shared-system-certificates_security-hardening). Otherwise ldapsearch and dsconf v1.4.2 would not work. Fiddling with /etc/openldap/ldap.conf does not change anything, it's the first thing i was trying to adjust. The only difference is actually removing one rpm and installing the other. If i go back from python3-lib389-1.4.3.13-1 to python3-lib389-1.4.2.16-1.module_el by uninstalling one rpm and installing the other dsconf works again: dnf -y module enable 389-directory-server:testing dnf -y install python3-lib389 dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass ... Error: Can't contact LDAP server - error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) <PROBLEM> dnf -y remove python3-lib389 dnf -y module disable 389-directory-server:testing dnf -y module enable 389-directory-server:stable dnf -y install python3-lib389 dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass ... ... <OK> So it seems it has something to do with how dsconf 1.4.3 vs 1.4.2 validates the server certificate chains.... It also breaks replication monitoring in cockpit UI since dsconf cannot connect by ldaps to otehr servers of replication config... Thanks for the hint about .dsrc file, i'll try it - my workaround today is not very elegant :) : sed -i -e 's/ldap.OPT_X_TLS_HARD/ldap.OPT_X_TLS_NEVER/' /usr/lib/python3.6/site-packages/lib389/__init__.py sed -i -e 's/ldap.OPT_X_TLS_HARD/ldap.OPT_X_TLS_NEVER/' /usr/lib/python3.6/site-packages/lib389/cli_base/dsrc.py >> DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', >> 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': >> None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': >> 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': >> 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory Manager'}} >> > > >> DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', >> 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': >> None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': >> 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': >> 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory manager'}} >> >> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'info': >> 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify >> failed (self signed certificate in certificate chain)'} >> ERROR: Error: Can't contact LDAP server - error:1416F086:SSL >> routines:tls_process_server_certificate:certificate verify failed (self signed >> certificate in certificate chain) > > I can't comment about the other environmental changes between those versions, > but tls_reqcert is 1 in both options, aka ldap.OPT_X_TLS_HARD which means your > ca cert must be in your LDAP ca store. You don't specify a tls_cacertdir or a > tls_cacert, so whatever you have in /etc/openldap/ldap.conf will be used for > this. > > Most likely there is a fault in this config, or they cacertdir is not hashed. > > If you use a cacertdir remember you need to run 'openssl rehash' in the > directory to setup the symlinks to the PEM files. > > If you use a cacert PEM file directly, ensure it's readable to your user etc. > > As a last resort you could set 'tls_reqcert = never' in .dsrc to disable ca > validity checking. > > Hope that helps, > > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > _______________________________________________ > 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 _______________________________________________ 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
