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@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
--
389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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/389-users@lists.fedoraproject.org
No comments:
Post a Comment