On 11/23/20 11:30 AM, Ivanov Andrey (M.) wrote:
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
When you switch between packages are you recreating the instance each
time and importing the certificates? 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.
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.
HTH,
Mark
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
--
389 Directory Server Development Team
_______________________________________________
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
