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/...).
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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
--
389 Directory Server Development Team