Following the guide two times, failing to set it up is why i reported it.

The blogpost mentioned says why the guide needs fixing.

This is an example of aome kind of bureoucracy gone wrong.

Peter Matulis <email address hidden> skrev: (8 december 2014 02:13:48 CET)
>I still do not know what is wrong with the current configuration
>provided in the Guide.  After reading through this report I have
>concluded that this is not a bug (not 'Confirmed') and so I certainly
>cannot have any documenter spend time implementing a fix (not
>'Triaged').  I am setting this to 'Invalid'.
>
>Analysis of your recommendations:
>
>> olcTLSCipherSuite: NORMAL
>
>This configures what ciphers to use.  This is site-specific.  It
>depends
>on what ciphers are supported by the client and also what security
>policies are in place.
>
>> olcTLSCRLCheck: none
>
>This is the GnuTLS default, and GnuTLS is the default TLS library in
>Ubuntu.  There is nothing "wrong" in not specifying this.
>
>> olcTLSVerifyClient: never
>
>This directive is ignored with GnuTLS.  It's misleading to specify any
>value here because it will never be honoured.
>
>> You’d think we’d be done by now, but it turns out there is one
>configuration in another file that is really important. If you try to
>> connect now, using a command line that binds to the ldap server such
>as this:
>>
>> $ ldapsearch -d 9 -D “cn=admin,dc=mydomain,dc=com” -w adminpassword
>-b “dc=mydomain,dc=com” -H
>> “ldaps://mydomain.com” “objectClass=*”
>>
>> You will probably get:
>>
>> |TLS: peer cert untrusted or revoked (0x42)
>> TLS: can't connect: (unknown error code).
>> ldap_err2string
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>
>> To resolve this, edit the file /etc/ldap/ldap.conf (note that this is
>not the slapd.conf file – it can be a bit confusing) and add the
>> single line below to what is probably a completely commented out
>file:
>>
>> |TLS_REQCERT never|
>
>I don't believe this.  That's absolutely wrong.  Why use TLS at all
>when
>the client is set up to ignore it?
>
>The reason you needed to do that is because you failed to implement
>your
>CA certificate properly on the server and/or on the client.  Using
>'never' is only good for debugging.  For production use, TLS_REQCERT
>should be set to 'demand', which should be  the default anyway.
>
>Techboy says:
>> 1. For server: we need `SLAPD_SERVICES="ldaps:///"` in the file
>`/etc/default/slapd`
>> 2. For client: we need `TLS_REQCERT allow` in the file
>`/etc/ldap/ldap.conf` if we are using self-signed certificates.
>
>1. LDAP over TLS/SSL (ldaps) is deprecated in favour of StartTLS and
>that's what the Guide has chosen.  So, no, we do not need ldaps at all
>unless some ancient clients do not support StartTLS.
>
>2. Again, no.  Use 'demand' as explained above.  It doesn't matter if
>you use a self-signed certificate.  Get it known to your clients by
>either pointing to a local copy of it or by incorporating it into your
>client's trusted certificate store.
>
>** Changed in: serverguide
>       Status: New => Invalid
>
>-- 
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1327173
>
>Title:
>  Openldap guide wrong in terms of TLS
>
>Status in Ubuntu Server Guide:
>  Invalid
>
>Bug description:
>  The openldap server guide has a section about TLS that is wrong.
>https://help.ubuntu.com/12.10/serverguide/openldap-server.html#openldap-tls
>
>  Solution on how it should be is found here:
>  http://rogermoffatt.com/2011/08/24/ubuntu-openldap-with-ssltls/
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/serverguide/+bug/1327173/+subscriptions

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.