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 -- [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]
_______________________________________________
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]
