Dear Maintainer,

   * What led up to the situation?

Upgrading (apt dist-upgrade) to trixie from bookworm

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

New version of slapd switched SSL backend to OpenSSL from GNUtls as documented
in libldap2 NEWS file.

   * What was the outcome of this action?

But how to actually update the values in a way that will fix the issue is not
documented.

   * What outcome did you expect instead?

The exact steps to have a successful upgrade should be documented.

Here is the error in log,

main: TLS init def ctx failed: -1 error:0A0000B9:SSL routines::no cipher match

In bookworm the value that works is,

olcTLSCipherSuite: NORMAL

But it will not work in trixie. Removing this entry did not fix the issue.

# cat delete-ciphers.ldif
dn: cn=config
changetype: modify
delete: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL

ldapmodify -Y EXTERNAL -H ldapi:/// -f ./delete-ciphers.ldif

This just removes the error message, but slapd does not start after the
upgrade.

2026-02-18T11:14:57.877705-08:00 comms-staging slapd[15509]: @(#) $OpenLDAP:
slapd 2.6.10+dfsg-1 (May 29 2025 23:41:48) $#012#011Debian OpenLDAP Maintainers
<pkg-openldap-devel@lists.alioth.debian.org>
2026-02-18T11:14:57.937406-08:00 comms-staging slapd[15510]: slapd starting
2026-02-18T11:14:57.938339-08:00 comms-staging slapd[15510]: daemon: shutdown
requested and initiated.
2026-02-18T11:14:57.938506-08:00 comms-staging slapd[15510]: slapd shutdown:
waiting for 0 operations/tasks to finish
2026-02-18T11:14:57.939951-08:00 comms-staging slapd[15510]: slapd stopped.

publicai.co suggested some values like but none of the suggested values works
with gnutls

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256

# cat OpenSSL.ldif
dn: cn=config
changetype: modify
delete: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
-
add: olcTLSCipherSuite
olcTLSCipherSuite: DHE-RSA-AES256-GCM-SHA384

# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./OpenSSL.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

Good morning,
like you said, can't see any errors here, however some library messages
are not sent to syslog so you might get more details about the error
from stderr. You should probably run slaptest with the appropriate debug
flags enabled (`-d flag,flag,...`, should probably include at least
`config`) to check that it's happy with the rest of the configuration
and see whether anything else comes up.

Other than that, yes, you can generally remove the attribute before
upgrade and either leave it to whatever OpenSSL considers default or add
whatever is appropriate for your environment after you've switched. Same
with any other attributes you might come across this way.

Regards,

Nothing turned up with slaptest -d config

# slaptest -d config
loaded module back_mdb
module back_mdb: null module registered
index objectClass 0x0004
index cn 0x0004
index uid 0x0004
index uidNumber 0x0004
index gidNumber 0x0004
index member 0x0004
index memberUid 0x0004
index email 0x0004
index mail 0x0004
mdb_monitor_db_open: monitoring disabled; configure monitor datab
ase to enable
config file testing succeeded

With slaptest not giving any errors, I wonder which other attribute is
problematic.

These are the other options we set,

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSProtocolMin
olcTLSProtocolMin: 3.3

I will try deleting these one by one as well (deleting olcTLSCipherSuite
was tried already).

Same results after removing these options as well. slapd won't start
after the upgrade and no other clue in the log other than just stopping
after it tries to start.

It could be related to actual (TLS?) startup which doesn't happen for
slap* tool setup. If you start slapd by hand with `-d config` (or `-d
any` if you want full output) does anything new show up on stderr? If it
does start up just fine, then I'd look the way of how it's started
(selinux/apparmor/... interference) as well but let's start from the
bottom.

Regards,

Interestingly running slapd manually seems to work.

These are the steps I did,

1. delete olcTLSCipherSuite: NORMAL
2. Set olcSecurity: tls=0
3. Remove ldaps:/// from slapd -h in systemd service file
4. Update source.list and install slapd from trixie
4. start with slapd -d config -h "ldap:/// ldapi:///"
5. Add olcTLSCipherSuite: HIGH
6. Remove olcSecurity: tls=0

Still systemctl start slapd fails, but systemd still cannot start.

Manually running this same command (after creating the directories and
adjusting permissions) works fine, but somehow systemd is failing to
start it.

# cat /etc/systemd/system/slapd.service.d/override.conf
[Service]
ExecStart=
ExecStartPre=/bin/mkdir -p /var/run/slapd
ExecStartPre=/bin/chown openldap:openldap /var/run/slapd
ExecStart=/usr/sbin/slapd -h "ldap:/// ldapi:///" -F /etc/ldap/slapd.d
-u openldap -g openldap

If it starts up from the shell, then it definitely sounds like an issue
with how systemd sets up the environment. Likely sandboxing or something
similar. Add -d to the ExecStart invocation (and potentially olcLogFile:
<path> to cn=config if you can't/don't want to read stderr) and see
where you get.

What does systemctl cat slapd.service say? Is there anything in the
kernel audit logs to indicate apparmor issues (and what does aa-status
say about slapd?)

Regards,

ExecStart=sh -c 'mkdir -p /run/slapd; \
         chown "$SLAPD_USER":"$SLAPD_GROUP" /run/slapd; \
         [ -d "$SLAPD_CONF" ] && confflag=-F || confflag=-f; \
         exec /usr/sbin/slapd -d0 \
                 ${SLAPD_SERVICES:+-h "$SLAPD_SERVICES"} \
                 ${SLAPD_USER:+-u "$SLAPD_USER"} \
                 ${SLAPD_GROUP:+-g "$SLAPD_GROUP"} \
                 ${SLAPD_CONF:+$confflag "$SLAPD_CONF"} \
                 $SLAPD_OPTIONS'

I think /run/slapd vs /var/run/slapd in override file was conflicting.

After removing the override, slapd is starting now.

I think we still need to document how to actually do the migration if
someone has set a value for olcTLSCipherSuites.

My draft for this document (I think this should be included in trixie in
a stable update and referenced in release notes:

Since cipher suite names are not compatible between GNUtls and OpenSSL,
if you have set any value for this variable, you will need to delete
this variable before the upgrade, and set a suitable value after the
upgrade is completed.

If you don't remove any incompatible options, you will see this error in
slapd logs after the upgrade and slapd service will fail to start.

main: TLS init def ctx failed: -1 error:0A0000B9:SSL routines::no cipher
match

You can run this command to see if any value is set,

ldapsearch -Y EXTERNAL
  -H ldapi:/// -b cn=config -s base|grep olcTLSCipherSuite

For example, if you have set this to NORMAL, you need to create an ldif file

# cat delete-ciphersuite.ldif
dn: cn=config
changetype: modify
delete: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL

and run
ldapmodify -Y EXTERNAL -H ldapi:/// -f ./delete-ciphersuite.ldif

You can set a suitable value compatible with OpenSSL after the upgrade.

# cat add-ciphersuite.ldif
dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: HIGH

ldapmodify -Y EXTERNAL -H ldapi:/// -f ./add-ciphersuite.ldif

You might want to remove
/etc/systemd/system/slapd.service.d/override.conf as runtime directories
are now handled correctly in the systemd service file.

there is no way to recover it after it is upgraded (except may be
modifying the db directly) as slapd won't start.

If this is detected, we should show a warning and give the migration
steps documentation reference and ask for explicit confirmation before
proceeding with upgrade.

I just tried with olcSecurity: tls=0 before upgrade, but I'm not able to
start it with just "ldap:/// and ldapi:///" options. Is there another
way to disable TLS completely to repair an broken upgrade?

Hi Praveen,

The text I originally submitted for the release notes specifically
called out the cipher suite option, however the editors removed it since
it duplicated the same info from debian/NEWS.

https://salsa.debian.org/openldap-team/openldap/-/raw/2.6.10+dfsg-1/debian/NEWS

slapd's README.Debian has a section (at the bottom) about the 2.6
upgrade, and steps for recovering after the upgrade, when the service
won't start:

https://salsa.debian.org/openldap-team/openldap/-/raw/2.6.10+dfsg-1/debian/slapd.README.Debian

You're right that I could have done better by providing steps to avoid
breaking the service in the first place.

I don't know what this file is. The slapd package has never installed or
created it. Something local on your end?

libldap2 package's NEWS has

"For more information about the slapd(8) configuration, see
   /usr/share/doc/slapd/README.Debian.gz."

This did not give a hint that upgrade issues would also be covered
there. May be make an explicit reference to this file.

"For more information about the slapd(8) configuration and GNUtls to
OpenSSL backend migration issues, see
   /usr/share/doc/slapd/README.Debian.gz."

I think we can still do it as many people would still benefit from a
clearer documentation.
This was probably a local change. Not sure if earlier versions correctly
handled creating the run directories using systemd services.