>>
>> No problem. We've just merged the fix and backported it. I don't know when it
>> will ship in RHEL/CentOS, but I'm sure it will be soon in an upcoming update.
> Well i usually do not use rpms - we compile from git sources, i used them only
> to make a demo of the problem.
>
> Thanks for
Hi Willam,
>>
>> Thanks, here is the github ticket:
>> https://github.com/389ds/389-ds-base/issues/4460
>>
>
> No problem. We've just merged the fix and backported it. I don't know when it
> will ship in RHEL/CentOS, but I'm sure it will be soon in an upcoming update.
Well i usually do not
> On 26 Nov 2020, at 01:16, Ivanov Andrey (M.)
> wrote:
>
> Hi,
>
>
>>> But all in all i think i start to see where the problem comes from. dsconf
>>> version 1.4.2 uses /etc/openldap/ldap.conf (which in turn uses system pem
>>> bundle if no TLS_CACERT is specified) for certs/CA. Starting
> On 25 Nov 2020, at 20:13, Viktor Ashirov wrote:
>
>
>
> On Wed, Nov 25, 2020 at 1:16 AM William Brown wrote:
>
>
> > On 25 Nov 2020, at 01:08, Ivanov Andrey (M.)
> > wrote:
> >
> >
> > But all in all i think i start to see where the problem comes from. dsconf
> > version 1.4.2 uses
Hi,
>> But all in all i think i start to see where the problem comes from. dsconf
>> version 1.4.2 uses /etc/openldap/ldap.conf (which in turn uses system pem
>> bundle if no TLS_CACERT is specified) for certs/CA. Starting from 1.4.3
>> dsconf
>> ignores completely /etc/openldap/ldap.conf file
On Wed, Nov 25, 2020 at 1:16 AM William Brown wrote:
>
>
> > On 25 Nov 2020, at 01:08, Ivanov Andrey (M.) <
> andrey.iva...@polytechnique.fr> wrote:
> >
> >
> > But all in all i think i start to see where the problem comes from.
> dsconf version 1.4.2 uses /etc/openldap/ldap.conf (which in turn
> On 25 Nov 2020, at 01:08, Ivanov Andrey (M.)
> wrote:
>
>
> But all in all i think i start to see where the problem comes from. dsconf
> version 1.4.2 uses /etc/openldap/ldap.conf (which in turn uses system pem
> bundle if no TLS_CACERT is specified) for certs/CA. Starting from 1.4.3
>
Hi William,
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
> On 24 Nov 2020, at 05:07, Ivanov Andrey (M.)
> 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
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
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"
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"
> 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':
13 matches
Mail list logo
