tux0r - they'll be going out today. It looks like the regression testing was successful.

After an omios-extra PR gets merged the package should shwo up automatically right?

Well that's interesting

latest bloody has broken ldap/client it seems

logs nothing usful error wise

Hmm it seems the included openldap update now is not compatible with the illumos ldap client it fails on the TLS setup

andyf ^ known issue ?

Ugh yeah 2.6.8 has a ton of TLS "fixes"

I wonder why ldap/cliet now does not like it anymore

ldapclient now seems to fai lagainst 2.6.7 too

so It's something in ldap/client that changed... but what

I'm not seeing nay changes though since 20240717

Maybe the linked version of openssl/gnutls ?

I'm gonna revert for now, last bloody was from 0704 not 0717

Back on the 20240704 be and everything works again but given the ldap/client today bloody doesn't work against openldap's slapd 2.6.7 and 2.6.8 I don't think that minor bump is to blame.

It's definitely a TLS issue though

andyf IIRC ldapclient (ON) links against openssl right? Did that one get bumped or something recently?

Aside from completely displaying tls I can't get current bloody's ldap client to connect at all

Even when re-enabling TLS1.0 and weak ciphers

Does pointing 'openssl s_client' at the server say anything interesting? (That's my normal first step, remove any applications from the mix entirely and just see what the underlying TLS looks like.)

That works fine, if I pass the -starttls ldap flag

Settles on New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Which is more or less what I would have expected

ldap/client ofcourse logs nothing

Not that slapd logs anything useful except the TLS Negotation Failure

Since ldap/client is not working only wy I can access the box is via serial not making it any easier

It essentially logs the same: libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP server

rebooting now as I actually have stuff I need to do :(

But we've been here before and I think back then it was a gnutls vs openssl thingy

On the old BE slapd logs: TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384

Which seems to match what openssl s_client uses on both old and new be

That doesn't sound great. It's a while since I did anything with openldap but I can see if I can spin up a zone this evening and compare notes.

So with both slapd (openldap 2.6.8 and 2.6.7) ldap/client from bloody on 20240704 works fine, it seems to neg `TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384`

Currently bloody's ldap/client doesn't seem to be able to negotiate anything with either version of openldap

Resulting in slapd closing the connection and ldap/client logging the connection was closed but nothing else useful

And as per peter's suggestion using openssl s_client -connect server:ldap -starttls ldap or without startls but using the ldaps port, it works on both 20240704 and current bloody, the always seem to settle on TLS1.3 + TLS_AES_256_GCM_SHA384

Disabling the requirement for TLS in slapd does make ldap/client 'work'

That's as far as I. got

These are my current settings, but I also tried raising and lowering the TLS requirement and cipher set to just be ALL, no change `olcTLSProtocolMin: 3.2, olcTLSCipherSuite: EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH, olcSecurity: tls=1`

And i have `olcRequires: authc` set too, but since I am using a proxy user for the client that shouldn't matter

I think that's all the relavant bits

andyf: :) thx