Welcome, Googlers
For the second time this millenium, I’ve had to persuade a server to trust the LDAP server
in the corner. The one with an SSL certificate written in crayon.
Eventually I found a fix – my own, from a few years back, on a mailing list archive (I never got round to restoring my old inbox after my mailserver died). As usual, I’m dumping it here for me and Google to find next time.
how do i brewed home
I use my own SSL Certificate Authority (CA) to sign server certificates. My SSL clients (browsers, JVMs, etc.) trust this CA certificate, so they automatically trust SSL certs it creates.
It’s a small improvement on self-signed certificates (that you have to load individually).
Exims LDAP lookup library (like lighttpds) doesn’t support homegrown CA certificates.
(Well, it does now, because I hacked in a fix and Ceri was good enough to polish it into something we could push upstream without being laughed at too loudly . But the point stands.)
documentation, you say? OpenLDAP set_tls_options() is confused.
If you try to bind over ldap:// (with startTLS) or ldaps:// against an LDAP server with a home-signed certificate, you’ll get the helpful LDAP error ‘-1′.
If you’re lucky, you can tell your client to load a custom CA cert.
Apache has the LDAPTrustedCA option, OpenLDAPs CLI tools read TLS_CACERT from ldap.conf, pam_ldap and nss_ldap use ‘tls_cacertfile’, etc.
If you’re unlucky, you need to patch your client.
This is easily fixed by throwing this into your C code somewhere:
ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, "/path/to/ca.crt");(note that first argument is NULL, not a specific LDAP connection)
This only works for OpenLDAP, and the hard bit (that I did for lighttpd and Ceri did in his exim patch) is turning that hardcoded path into support for a config file option.