> On 24 Nov 2020, at 05:07, Ivanov Andrey (M.) <[email protected]> > wrote: > > Hi Mark, > > > >>> >>> 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
You don't need to do this. You can set tls_reqcert = never in your dsrc file. You do not need to edit the lib389 source code. >> >> > > >> When you switch between packages are you recreating the instance each >> time and importing the certificates? > > No, the server installation is not modified or touched in any way - the LDAP > server (1.4.3) is installed on a separate server (called "ldap-model", CentOS > 8.2) and never restarted or reconfigured. The instance of LDAP is installed > only there and yes, i used during the installation the ds* utilities : > dsctl model tls import-server-key-cert model_cert.crt model_cert.key > dsconf model security ca-certificate add --file intermedite-1.crt --name > "CA-Intermediate-1" > dsconf model security ca-certificate set-trust-flags "CA-Intermediate-1" > --flags "CT,," > ... > The server is accessible with ldapsearch -H ldaps://..., SSL is installed > correctly - no problem at all. I do not touch it it all during the tests. Can you show us your /etc/openldap/ldap.conf please? > > > I install only the management tools (python3-lib389) on another server called > "ldap-centos8", and since it needs the file default.inf, so "389-ds-base" rpm > is installed too. But no 389 instances are started or configured. All the > necessary certificates (CA and 2 intermediates) are imported to system pem > bundles using this : > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-shared-system-certificates_security-hardening > (by "update-ca-trust" and/or "trust anchor path.to/certificate.crt"). The system pem bundles are NOT used by openldap which means that lib389 can't use them. You must configure the tls_cacertdir or tls_cacert is dsrc to point at your CA cert. > > ldapsearch and dsconf 1.4.2 work fine with ldaps://ldap-model... but dsconf > v.1.4.3 refuses to connect. > > The only difference i see in debug logging are the following lines present > during dsconf 1.4.3 connect attempt but absent in 1.4.2 connect debug (no 389 > instances installed on this server, as i mentioned before) : > DEBUG: open(): Connecting to uri ldaps://ldap-model.polytechnique.fr:636 > DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-{instance_name} > DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name} > DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name} > DEBUG: Using certificate policy 1 > DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1 > DEBUG: Cannot connect to 'ldaps://ldap-model.polytechnique.fr:636' > > > >> I'm asking because I'm looking at >> the lib389 code for 1.4.3 and 1.4.2 and there is not much of a >> difference except for importing certificates and how it calls the rehash >> function. >> >> In 1.4.2 we always do: >> >> /usr/bin/c_rehash <cert dir> >> >> in 1.4.3 we call two difference function depending on the system: >> >> /usr/bin/openssl rehash <cert dir> >> >> or >> >> /usr/bin/c_rehash <cert dir> >> >> >> Maybe try running "/usr/bin/c_rehash <your cert dir>" on the 1.4.3 >> installation and see if it makes a difference. > > I don't use crt dirs - i add the intermediate CAs to system bundles > (update-ca-trust or trust anchor path.to/certificate.crt) > > >> >> On my Fedora system (1.4.3) it uses the openssl function, which brings >> me to my next question. How are you importing the certificates? Are >> you using dsctl/dsconf? If you aren't, then you should, as they call >> the rehash functions for you when importing the certificates. > I used dsctl/dsconf on the server with 389 LDAP instance ("ldap-model") and > the server works fine, the problem is on another ("management") server > ("ldap-centos8") where changing rpms from 1.4.3 to 1.4.2 (or the other way) > switch me from working to non-working dsconf. > > > Thanks for trying to help ! :) > > > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
