10:14:31 tux0r - they'll be going out today. It looks like the regression testing was successful. 11:30:30 After an omios-extra PR gets merged the package should shwo up automatically right? 11:38:24 Well that's interesting 11:38:32 latest bloody has broken ldap/client it seems 11:38:39 logs nothing usful error wise 11:40:56 Hmm it seems the included openldap update now is not compatible with the illumos ldap client it fails on the TLS setup 11:41:05 andyf ^ known issue ? 11:42:59 Ugh yeah 2.6.8 has a ton of TLS "fixes" 11:43:10 I wonder why ldap/cliet now does not like it anymore 11:44:49 ldapclient now seems to fai lagainst 2.6.7 too 11:44:59 so It's something in ldap/client that changed... but what 11:46:19 I'm not seeing nay changes though since 20240717 11:46:33 Maybe the linked version of openssl/gnutls ? 11:48:36 I'm gonna revert for now, last bloody was from 0704 not 0717 11:53:26 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. 11:53:47 It's definitely a TLS issue though 11:54:07 andyf IIRC ldapclient (ON) links against openssl right? Did that one get bumped or something recently? 12:07:11 Aside from completely displaying tls I can't get current bloody's ldap client to connect at all 12:08:19 Even when re-enabling TLS1.0 and weak ciphers 12:13:28 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.) 12:20:20 That works fine, if I pass the -starttls ldap flag 12:20:48 Settles on New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 12:20:55 Which is more or less what I would have expected 12:21:27 ldap/client ofcourse logs nothing 12:21:57 Not that slapd logs anything useful except the TLS Negotation Failure 12:22:28 Since ldap/client is not working only wy I can access the box is via serial not making it any easier 12:23:20 It essentially logs the same: libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP server 12:23:42 rebooting now as I actually have stuff I need to do :( 12:23:57 But we've been here before and I think back then it was a gnutls vs openssl thingy 12:29:08 On the old BE slapd logs: TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 12:29:22 Which seems to match what openssl s_client uses on both old and new be 12:44:17 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. 12:48:31 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` 12:48:51 Currently bloody's ldap/client doesn't seem to be able to negotiate anything with either version of openldap 12:49:11 Resulting in slapd closing the connection and ldap/client logging the connection was closed but nothing else useful 12:50:18 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 12:50:38 Disabling the requirement for TLS in slapd does make ldap/client 'work' 12:51:11 That's as far as I. got 13:03:33 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` 13:04:31 And i have `olcRequires: authc` set too, but since I am using a proxy user for the client that shouldn't matter 13:04:43 I think that's all the relavant bits 22:00:39 andyf: :) thx