https://bugs.openldap.org/show_bug.cgi?id=10323
Issue ID: 10323
Summary: Starttls critical not working on lloadd
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: grichier(a)scaleway.com
Target Milestone: ---
Hello,
Looks like starttls critical not working on lloadd.
I have a backend with starttls configure but with bad CN.
When I direct query the backend using ldapsearch with option -ZZ, I have the
following error:
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
But when I query the lloadd, which use same backend with olcBkLloadStartTLS to
critical. It's work...
On a tcpdump I can see the communication between backend and lloadd is not
using starttls. (cleartext). But it shouldn't (critical option)
cn: {1}ldap://ldap01.example.com
olcBkLloadBackendUri: ldap://ldap01.example.com
olcBkLloadNumconns: 10
olcBkLloadBindconns: 5
olcBkLloadRetry: 5000
olcBkLloadMaxPendingOps: 50
olcBkLloadMaxPendingConns: 10
olcBkLloadWeight: 1
olcBkLloadStartTLS: critical
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10226
Issue ID: 10226
Summary: [PATCH] ldap.conf: some remarks and editorial fixes
for this man page
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: bjarniig(a)vortex.is
Target Milestone: ---
Created attachment 1020
--> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit
Remarks and editotiral fixes for the manual ldap.conf.5
Version 2.6.8 is not named on the webpage when entering an issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10327
Issue ID: 10327
Summary: Adding syncprov to cn=config can lock up server
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
As reported on openldap-technical[0], adding syncprov to a cn=config DB can
lock up the server. This happens when syncprov_db_otask is scheduled by
syncprov_db_open.
ITS#9045 has already dealt with this for config_back_entry_get, we can relax
this description and allow a config_back_search do the same. Even though it is
technically on a different thread than the main modification, AFAIK it is still
the only one running as the server is paused and the main modification is
paused waiting for it?
[0].
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10331
Issue ID: 10331
Summary: slap* tools should be a little more helpful as to
which command line option was invalid
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Also why where appropriate.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10270
Issue ID: 10270
Summary: Issues with pcache when refresh/persistPcache used
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Greetings, OpenLDAP-folk.
We've been running with the pcache overlay in 2.5.18
with both query refresh and pcachePersist for a bit
and have observed some oddities:
1.) Negative queries don't get refreshed
2.) Queries don't seem to be persisted
These behaviors are all exhibited from the current
git version as well - code/patches below for clarity
of communication:
Thanks!
Andy
commit c0b4fe92c8df746c0e6a777f93f1687135114eb9
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:43:47 2024 -0400
negative cache entries are not loaded when pcachePersist is on
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 9ef78fd6bf43..9fd72e6d7261 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -802,7 +802,11 @@ url2query(
goto error;
}
- cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 );
+ if (BER_BVISNULL( &uuid )) {
+ cq = add_query( op, qm, &query, qt, PC_NEGATIVE, 0 );
+ } else {
+ cq = add_query( op, qm, &query, qt, PC_POSITIVE, 0 );
+ }
if ( cq != NULL ) {
cq->expiry_time = expiry_time;
cq->refresh_time = refresh_time;
commit 8f7b50dfcec69fa01f8cf0a4b77f3dee8ef9f0f6
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:38:36 2024 -0400
queries with ttr/x-refresh are not loaded when pcachePersist is on
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 40c1f9673776..9ef78fd6bf43 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -749,7 +749,7 @@ url2query(
}
}
- if ( got != GOT_ALL ) {
+ if ( (got & GOT_ALL) != GOT_ALL) {
rc = 1;
goto error;
}
commit c7e52c90192a43876d40b9776a58db951d27937c
Author: Andrew Elble <aweits(a)rit.edu>
Date: Fri Oct 11 08:37:13 2024 -0400
ttr was not being applied to negatively cached entries
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 1d6e4ba4edcf..40c1f9673776 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -1580,6 +1580,8 @@ add_query(
case PC_NEGATIVE:
ttl = templ->negttl;
+ if ( templ->ttr )
+ ttr = now + templ->ttr;
break;
case PC_SIZELIMIT:
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9934
Issue ID: 9934
Summary: slapd-config(5) should document how to store
certificates for slapd usage
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Commit 7b41feed83b expanded the ability of cn=config to save the certificates
used for TLS by slapd directly in the config database. However the
documentation for the new parameters was never added to the slapd-config(5) man
page.
olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10332
Issue ID: 10332
Summary: Add support for SSLKEYLOGFILE environment variable to
export keys for Wireshark decryption
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
Please add support to do the following:
SSLKEYLOGFILE=keylog.txt ldapsearch -H ldaps://...
Other libraries and tools support it to decrypt the TLS traffic with Wireshark
for analysis purposes.
Curl has a simple, but complete implementation:
https://github.com/curl/curl/blob/e008f71f435a39875d86885a96b2eb8968a60fd4/…
Maybe it can be reused if license allows that?!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10321
Issue ID: 10321
Summary: slapd garbles userCertificate hex code
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: jnabasny(a)gmail.com
Target Milestone: ---
I discovered an issue with how slapd handles hex encoded userCertificate;binary
values while testing identical setups between FreeIPA and OpenLDAP. It seems to
partially decode the hex, causing any search to fail. This was discovered when
using SSSD, but is reproducible with ldapsearch. Essentially, you run a query
like this using the hex encoded value of the certificate:
ldapsearch -H ldap://10.10.0.94 -D cn=admin,dc=nabasny,dc=com -b
"dc=nabasny,dc=com" -W
'(&(userCertificate;binary=\30\82\04\85\30\82\02\ed\a0\03\02\01\02\02\01\0d\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\30\37\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1e\17\0d\32\35\30\33\32\30\31\35\34\35\32\36\5a\17\0d\32\37\30\33\32\31\31\35\34\35\32\36\5a\30\26\31\15\30\13\06\03\55\04\0a\0c\0c\46\52\45\45\49\50\41\2e\48\4f\4d\45\31\0d\30\0b\06\03\55\04\03\0c\04\6a\61\6b\65\30\82\01\22\30\0d\06\09\2a\86\48\86\f7\0d\01\01\01\05\00\03\82\01\0f\00\30\82\01\0a\02\82\01\01\00\b9\b2\3b\be\d1\20\bd\f2\ba\69\e6\b6\e5\2d\13\b0\77\a6\59\69\50\76\4c\07\71\ce\ee\8f\41\ef\04\20\1b\8e\a5\f7\8a\96\0d\f1\89\a5\84\cd\2f\be\ff\9c\2a\b2\bf\99\20\ca\ae\fc\a2\16\df\40\5b\d4\5e\7b\51\a5\b0\dd\bc\e9\c4\b1\e7\89\7c\25\f2\4b\b0\08\09\bd\60\58\c1\8f\af\fb\2a\5e\90\69\37\27\40\61\62\bb\7a\b8\76\18\11\96\2e\45\54\26\b0\c7\ec\92\3c\72\90\52\1a\44\0f\69\5c\b4\f1\98\53\4e\15\86\33\1a\81\ee\70\63\ae\e4\c7\32\7f\92\14\71\9d\58\c0\7d\a1\20\dc\f5\f6\47\29\45\56\bd\a2\dd\eb\4a\17\f2\2a\72\6f\fd\0f\a3\7e\a0\96\de\02\f3\b2\d9\ac\fc\af\38\c9\7a\21\c3\1b\19\4c\bc\d8\11\48\22\cf\18\ec\17\85\51\e9\51\22\49\aa\89\1a\73\2b\8d\40\e9\a9\3a\dd\e8\6e\9b\27\45\09\fd\a4\88\f5\7c\4e\96\b7\82\cd\f6\e2\1e\08\53\38\af\f9\4d\55\9c\79\0f\32\d8\bb\85\83\08\c0\b9\f3\39\7f\b9\7b\a9\02\03\01\00\01\a3\82\01\2b\30\82\01\27\30\1f\06\03\55\1d\23\04\18\30\16\80\14\0d\6b\b6\82\13\0c\a2\9d\91\01\40\e8\59\d6\2b\ec\87\1a\f0\36\30\3e\06\08\2b\06\01\05\05\07\01\01\04\32\30\30\30\2e\06\08\2b\06\01\05\05\07\30\01\86\22\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\63\61\2f\6f\63\73\70\30\0e\06\03\55\1d\0f\01\01\ff\04\04\03\02\04\f0\30\1c\06\03\55\1d\25\04\15\30\13\06\08\2b\06\01\05\05\07\03\01\06\07\2b\06\01\05\02\03\05\30\77\06\03\55\1d\1f\04\70\30\6e\30\6c\a0\34\a0\32\86\30\68\74\74\70\3a\2f\2f\69\70\61\2d\63\61\2e\66\72\65\65\69\70\61\2e\68\6f\6d\65\2f\69\70\61\2f\63\72\6c\2f\4d\61\73\74\65\72\43\52\4c\2e\62\69\6e\a2\34\a4\32\30\30\31\0e\30\0c\06\03\55\04\0a\0c\05\69\70\61\63\61\31\1e\30\1c\06\03\55\04\03\0c\15\43\65\72\74\69\66\69\63\61\74\65\20\41\75\74\68\6f\72\69\74\79\30\1d\06\03\55\1d\0e\04\16\04\14\e8\11\4b\36\86\c9\7c\a2\d7\4e\ff\7c\13\89\2b\38\8d\c4\ec\32\30\0d\06\09\2a\86\48\86\f7\0d\01\01\0b\05\00\03\82\01\81\00\58\af\2b\7e\fd\05\b9\46\8a\c7\b9\e4\96\42\47\2d\8f\17\01\8e\58\30\95\9c\be\e7\2d\a8\22\64\5e\fd\f5\ec\46\97\2d\88\bc\06\b0\e7\a3\77\a3\d0\b6\da\01\4f\73\f4\3d\c9\47\49\e2\d0\a0\e8\bd\a9\62\fd\6c\de\81\32\9a\33\d5\58\57\d8\c9\47\54\78\fa\69\20\49\11\c9\dc\4f\f4\bc\37\63\28\6a\fd\e2\f7\4b\0f\44\26\90\6c\22\c9\b8\ff\9a\36\05\a3\24\3c\58\73\6f\4b\17\2d\e3\22\30\aa\34\4e\2f\36\24\94\6a\24\9b\bf\ac\e5\23\33\f6\3f\cf\c7\dd\38\91\85\63\c0\61\55\5f\de\2b\e6\3d\13\4f\8c\6a\6a\1e\3b\0e\4a\8c\e9\c3\46\ef\02\bb\63\b7\09\9f\d8\5c\67\4c\c6\40\8f\1e\7e\c8\f0\89\4c\8f\f8\24\63\42\31\f9\5d\5b\2d\cb\78\c3\94\5f\3e\ca\b8\7b\68\9a\6a\09\0c\22\bd\da\39\9f\b7\0f\4f\20\a9\1a\de\d7\8a\31\af\a3\ac\14\d1\ba\90\b8\22\56\31\b1\52\78\73\6f\36\05\88\0b\56\31\fd\55\89\7d\55\8b\01\1d\58\0c\75\03\bd\7c\7b\05\c7\86\15\90\0c\f4\c6\91\d3\f6\73\e9\8f\1f\25\88\32\b2\cb\53\db\91\e4\8b\28\a1\22\7a\38\ac\f5\8b\32\51\d4\9e\d6\e1\15\0d\fb\8f\60\09\e5\0c\dd\d4\19\fe\f7\44\cd\ac\ff\82\94\16\f5\7d\19\57\30\79\96\4b\7b\61\d0\b8\c3\0c\1c\2f\89\7e\01\5e\a0\95\9a\aa\d3\e2\6d\d5\fa\2e\e8\57\5a\b3\45\23\17\40\c9\d3\92\9e\11\cc\c4\31\f2\e5\94\e3\8f\5e\d9\51\92\cd\46\77\33\c8\4b\50\84\73)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))'
And slapd logs the query as:
Mar 20 19:54:01 ldap slapd[457]: conn=1058 op=3 SRCH
base="ou=people,dc=nabasny,dc=com" scope=2 deref=0
filter="(&(?userCertificate;binary=0\82\04\850\82\02\ED\A0\03\02\01\02\02\01\0D0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00071\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\1E0\1C\06\03U\04\03\0C\15Certificate
Authority0\1E\17\0D250320154526Z\17\0D270321154526Z0&1\150\13\06\03U\04\0A\0C\0CFREEIPA.HOME1\0D0\0B\06\03U\04\03\0C\04jake0\82\01"0\0D\06\09\2A\86H\86\F7\0D\01\01\01\05\00\03\82\01\0F\000\82\01\0A\02\82\01\01\00\B9\B2;\BE\D1
\BD\F2\BAi\E6\B6\E5-\13\B0w\A6YiPvL\07q\CE\EE\8FA\EF\04
\1B\8E\A5\F7\8A\96\0D\F1\89\A5\84\CD/\BE\FF\9C\2A\B2\BF\99
\CA\AE\FC\A2\16\DF@[\D4^{Q\A5\B0\DD\BC\E9\C4\B1\E7\89|%\F2K\B0\08\09\BD`X\C1\8F\AF\FB\2A^\90i7'@ab\BBz\B8v\18\11\96.ET&\B0\C7\EC\92<r\90R\1AD\0Fi\5C\B4\F1\98SN\15\863\1A\81\EEpc\AE\E4\C72\7F\92\14q\9DX\C0}\A1
\DC\F5\F6G\29EV\BD\A2\DD\EBJ\17\F2\2Aro\FD\0F\A3~\A0\96\DE\02\F3\B2\D9\AC\FC\AF8\C9z!\C3\1B\19L\BC\D8\11H"\CF\18\EC\17\85Q\E9Q"I\AA\89\1As+\8D@\E9\A9:\DD\E8n\9B'E\09\FD\A4\88\F5|N\96\B7\82\CD\F6\E2\1E\08S8\AF\F9MU\9Cy\0F2\D8\BB\85\83\08\C0\B9\F39\7F\B9{\A9\02\03\01\00\01\A3\82\01+0\82\01'0\1F\06\03U\1D#\04\180\16\80\14\0Dk\B6\82\13\0C\A2\9D\91\01@\E8Y\D6+\EC\87\1A\F060>\06\08+\06\01\05\05\07\01\01\042000.\06\08+\06\01\05\05\070\01\86"http://ipa-ca.freeipa.home/ca/ocsp0\0E\06\03U\1D\0F\01\01\FF\04\04\03\02\04…
Authority0\1D\06\03U\1D\0E\04\16\04\14\E8\11K6\86\C9|\A2\D7N\FF|\13\89+8\8D\C4\EC20\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05\00\03\82\01\81\00X\AF+~\FD\05\B9F\8A\C7\B9\E4\96BG-\8F\17\01\8EX0\95\9C\BE\E7-\A8"d^\FD\F5\ECF\97-\88\BC\06\B0\E7\A3w\A3\D0\B6\DA\01Os\F4=\C9GI\E2\D0\A0\E8\BD\A9b\FDl\DE\812\9A3\D5XW\D8\C9GTx\FAi
I\11\C9\DCO\F4\BC7c\28j\FD\E2\F7K\0FD&\90l"\C9\B8\FF\9A6\05\A3$<XsoK\17-\E3"0\AA4N/6$\94j$\9B\BF\AC\E5#3\F6?\CF\C7\DD8\91\85c\C0aU_\DE+\E6=\13O\8Cjj\1E;\0EJ\8C\E9\C3F\EF\02\BBc\B7\09\9F\D8\5CgL\C6@\8F\1E~\C8\F0\89L\8F\F8$cB1\F9][-\CBx\C3\94_>\CA\B8{h\9Aj\09\0C"\BD\DA9\9F\B7\0FO
\A9\1A\DE\D7\8A1\AF\A3\AC\14\D1\BA\90\B8"V1\B1Rxso6\05\88\0BV1\FDU\89}U\8B\01\1DX\0Cu\03\BD|{\05\C7\86\15\90\0C\F4\C6\91\D3\F6s\E9\8F\1F%\882\B2\CBS\DB\91\E4\8B\28\A1"z8\AC\F5\8B2Q\D4\9E\D6\E1\15\0D\FB\8F`\09\E5\0C\DD\D4\19\FE\F7D\CD\AC\FF\82\94\16\F5}\19W0y\96K{a\D0\B8\C3\0C\1C/\89~\01^\A0\95\9A\AA\D3\E2m\D5\FA.\E8WZ\B3E#\17@\C9\D3\92\9E\11\CC\C41\F2\E5\94\E3\8F^\D9Q\92\CDFw3\C8KP\84s)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"
Some of the hex has been decoded into readable strings, which causes the search
to fail.
Running the same search on FreeIPA with an identical user entry returns the
entry correctly.
I'm happy to provide more logs/details if needed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10326
Issue ID: 10326
Summary: SNI passing requirements differ across TLS
implementations
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
mbedtls 3.6.3 has changed behaviour to correct a long standing issue where not
setting a hostname meant hostname checking was disabled completely
(CVE-2025-27809).
It seems that how we do SNI vs. basic certificate checking differs between TLS
implementations and our logic in ldap_int_tls_connect and ti_session_connect.
This is also the reason test067-tls started failing on mbedtls builds.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10163
Issue ID: 10163
Summary: Cleanup configure/test integration
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
The sed commandline configure uses to perform substitutions is getting unwieldy
and may be exceeding platform limits on various systems.
All of the BUILD_xxx substitutions for overlays are only used in tests/run.in.
They could be completely removed, and instead each of the enabled overlays
could be emitted into a separate file that just gets included by the test
scripts. There's no need for them to be part of the sed invocation at all.
There's also leftover BUILD_xxx cruft from backends that we've removed (e.g.
back-shell BUILD_SHELL) that nothing else in the tree references any more.
--
You are receiving this mail because:
You are on the CC list for the issue.