<div dir="ltr">On 26 Aug 2013, at 11:42:52 -0700, Paul B. Henson wrote: ... However, in OmniOS r151006 (omnios-b281e50) the ldapsearch test fails when using TLS (-Z or -ZZ switches used) with: ldap_simple_bind: Can't contact LDAP server It looks like Brian's problem might be that he has an MD5 cert on his ldap server, and the latest release of omnios includes nss 3.14.3, which has by default dropped support for md5 certs:<a href="https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14_release_notes">https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14_release_notes</a> This might be worth retroactively adding to the release notes as a compatibility change? [...] If the same workaround resolves the issue under omnios, then # svccfg -s network/ldap/client:default setenv NSS_HASH_ALG_SUPPORT +MD5 should make the ldap client work, I believe all ldap connections are routed through the cache manager. For the sake of the archives, setting the environment variable just for network/ldap/client did not work. However, setting it globally in /etc/default/init and rebooting did. Suffering from exactly the same problem (LDAP bind failing after upgrading from r151004 to r151006), I tried your recipe; my /etc/default/init now contains: TZ="Europe/Brussels" CMASK=022 NSS_HASH_ALG_SUPPORT=+MD5 but it did not make any difference after reboot, e.g.: # ldapsearch -h <a href="http://ldap.xxx.net">ldap.xxx.net</a> -p 636 -Z -v -P /var/ldap/cert8.db -D "cn=Directory Manager" -b "dc=xxx,dc=net" "cn=Thierry Bingen" ldapsearch: started Mon Sep 2 15:29:40 2013 ldap_init( <a href="http://ldap.xxx.net">ldap.xxx.net</a>, 636 ) ldap_simple_bind: Can't contact LDAP server while the exact same command given on an r151004 gives: ldapsearch: started Mon Sep 2 15:32:20 2013 ldap_init( <a href="http://ldap.xxx.net">ldap.xxx.net</a>, 636 ) filter pattern: cn=Thierry Bingen returning: ALL filter is: (cn=Thierry Bingen) version: 1 dn: cn=Thierry Bingen,ou=People,dc=xxx,dc=net uid: tbingen etc. The LDAP server has not changed for a (long) while. It is opends@2.2.0-0.111 running on oi_148. MD5 seems to be its prime (only?) choice... Any other advice? Thanks, T. </div>