Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

2023-01-19 Thread Sebastian Andrzej Siewior
On 2023-01-19 12:02:52 [-0800], Ryan Tandy wrote:
> Hello Jonathan and Sebastian.
Hi Ryan,

> In any case I believe the use of Recommends is Policy-compliant since there
> are myriad ways to specify the trusted CAs and the default ldap.conf setting
> is only for convenience.

It sounds reasonable. Thank you for the detailed explanation.

> thanks,
> Ryan

Sebastian



Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

2023-01-03 Thread Jonathan
Package: openssl
Version: 1.1.1k-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

After trying to update to bullseye, connecting to our LDAP server no longer 
works, both with pam_ldap package as well as using ldapsearch from ldap-utils.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
On Debian 9 or 10, or on Ubuntu 22.04, our configuration works and ldapsearch 
with the -ZZ flag works. 
On Debian 11, it does not. I've tried installing the version of the openssl 
package that Debian 10 uses on a Debian 11 system, but still it didn't work. 
Querying the server with the following command works perfectly:

openssl s_client -starttls ldap -connect :

The output of this command says amongst other things "SSL handshake has read 
4692 bytes and written 436 bytes. Verification: OK" and lists the full 
certificate chain. 
If adding the -showcerts flag, all certificates in the chain are shown 
succesfully.


   * What was the outcome of this action?
ldapsearch gives the following output: 

ldap_start_tls: Connect error (-11)
additional info: (unknown error code)


   * What outcome did you expect instead?

It should query the LDAP server and successfully return data.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.83-1-pve (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssl depends on:
ii  libc6  2.31-13
ii  libssl1.1  1.1.1k-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20210119

-- no debconf information



Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

2023-01-04 Thread Sebastian Andrzej Siewior
On 2023-01-03 20:21:57 [+], Jonathan wrote:
> Package: openssl
>* What led up to the situation?
> 
> After trying to update to bullseye, connecting to our LDAP server no longer 
> works, both with pam_ldap package as well as using ldapsearch from ldap-utils.

What happens with if you add "-d -1" to ldapsearch?

Sebastian



Bug#1027830: [ITB] Re: Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

2023-01-04 Thread Jonathan Rietveld
Dear Sebastian,

Thanks for your quick reply!

Adding "-d -1", the output informs that "TLS: peer cert is untrusted or revoked 
(0x42)", even though the certificate is not self-signed and hasn't expired. 
We've since found out that installing libldap-common resolves our issue, as 
others (https://github.com/wheelybird/ldap-user-manager/issues/172 and 
https://github.com/docker-mailserver/docker-mailserver/issues/2340) found out. 
This package is installed by default on buster (even before installing any 
ldap-related packages), but not on bullseye. 

Perhaps it might make sense to add libldap-common as a dependency for other 
packages like libnss-ldap, pam_ldap or ldap-utils on bullseye?

Either way, our issue is resolved, and I'll leave that decision to you.

Kind regards,

Jonathan

-Original Message-
From: Sebastian Andrzej Siewior  
Sent: 04 January 2023 10:55
To: Jonathan ; 1027...@bugs.debian.org
Subject: [ITB] Re: Bug#1027830: openssl: starttls fails on our LDAP server on 
bullseye, but it works on buster

On 2023-01-03 20:21:57 [+], Jonathan wrote:
> Package: openssl
>* What led up to the situation?
> 
> After trying to update to bullseye, connecting to our LDAP server no longer 
> works, both with pam_ldap package as well as using ldapsearch from ldap-utils.

What happens with if you add "-d -1" to ldapsearch?

Sebastian


Bug#1027830: [Pkg-openssl-devel] Bug#1027830: [ITB] Re: Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

2023-01-19 Thread Sebastian Andrzej Siewior
control: reassign -1 ldap-utils 2.4.57+dfsg-3

On 2023-01-04 13:50:53 [+], Jonathan Rietveld wrote:
> We've since found out that installing libldap-common resolves our
> issue, as others
> (https://github.com/wheelybird/ldap-user-manager/issues/172 and
> https://github.com/docker-mailserver/docker-mailserver/issues/2340)
> found out. This package is installed by default on buster (even before
> installing any ldap-related packages), but not on bullseye. 
> 
> Perhaps it might make sense to add libldap-common as a dependency for
> other packages like libnss-ldap, pam_ldap or ldap-utils on bullseye?

Based on Jonathan's investigation, I reasign the bug to
openldap/ldap-utils since it appears it has to depend on libldap-common
in order to get TLS to work with ceritificate validation. It has only
recommends via libldap-*.

This poped up on the openssl package but it appears to use gnutls stack
instead.

> Kind regards,
> 
> Jonathan

Sebastian