Openldap guide wrong in terms of TLS

[larsemil]

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/

[Peter Matulis (petermatulis)]

Specifically state what is wrong in the guide.

[larsemil (emil-larsemil)]

The TLS part about certinfo.ldif

and also additional things to do after that.

it is stated in blog post i linked

[Peter Matulis (petermatulis)]

We need more specifics. We're not just going to copy from a blog. What, specifically, is wrong with certinfo.ldif and what are the "additional things"?

[Doug Smythies (dsmythies)]

Perhaps refer to the 14.04 serverguide for this report instead.
12.10 went EOL on May 16, and the web pages will be deleted as soon as I get around to it.
I.E.:
https://help.ubuntu.com/14.04/serverguide/openldap-server.html#openldap-tls

@Peter: We usually set the status to "incomplete" when more information is required, then it will just expire if not updated.

[larsemil (emil-larsemil)]

Ok cool.
I would like to change:

Create the filecertinfo.ldifwith the following contents (adjust
accordingly, our example assumes we created certs using
https://www.cacert.org):

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

To:

Create a suitable ssl.ldif file for importing into the configuration
database. It’s worth saying at this point that the ones I’ve seen online
have all had syntax errors in that have prevented them from working –
and they fail silently which makes you think they have worked!*Note
especially that the hyphens are syntactically important.*

|dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap-ca-cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap-ca-key.pem|

And after adding the record using sudo ldapmodify (where one could add
-v for some verbosity. Looks better and gives you an hint on wheter the
correct records where added. If it fails you could change /add /to
/change/ to change the records. .

I want to add:

/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|/

2014-06-07 00:25, Doug Smythies skrev:
> Perhaps refer to the 14.04 serverguide for this report instead.
> 12.10 went EOL on May 16, and the web pages will be deleted as soon as I get around to it.
> I.E.:
> https://help.ubuntu.com/14.04/serverguide/openldap-server.html#openldap-tls
>
> @Peter: We usually set the status to "incomplete" when more information
> is required, then it will just expire if not updated.
>
>
> ** Changed in: serverguide
> Status: New => Incomplete
>

[Launchpad Janitor (janitor)]

[Expired for Ubuntu Server Guide because there has been no activity for 60 days.]

[Gunnar Hjalmarsson (gunnarhj)]

larsemil provided additional info in comment #5.

[Techboy (techboy)]

Suggestions:
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.
3. (Off the topic) After install slapd, we should perform `dpkg-reconfigure slapd` as described in https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-a-basic-ldap-server-on-an-ubuntu-12-04-vps

[Peter Matulis (petermatulis)]

Don't set to 'Confirmed', and certainly not 'Triaged' if no one has confirmed the bug. I'll try to get some time this week.

[Gunnar Hjalmarsson (gunnarhj)]

Quote from https://wiki.ubuntu.com/Bugs/Bug%20statuses :

"Triaged:
- A member of UbuntuBugControl believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. (also see tip below)
- Use this when you are confident that it should be looked at by a developer and has enough information"

[Peter Matulis (petermatulis)]

That's entirely correct. The "developer" in this case is a documenter who knows enough to provide a fix. Right now that's not the case.

The bug is not even at the 'Confirmed' stage. That is, we don't even know if this is a genuine bug. All we have right now is text that the OP would like to appear. Someone now needs to go over that text, issue the commands described, do the same with those in the current guide, compare output, and *confirm* that it addresses a deficiency. Has anybody done this?

[Gunnar Hjalmarsson (gunnarhj)]

No, but the bug report contains enough info for someone with the sufficient skill to start doing that. Isn't that what the "Triaged" status is supposed to say?

[Peter Matulis (petermatulis)]

However non-intuitive, first a bug is confirmed and then it is triaged. A bug can be confirmed but still be missing enough information to be fixed. Triage is a stamp of approval that denotes "this is a confirmed bug and all the information that is needed to produce a fix is available".

[Gunnar Hjalmarsson (gunnarhj)]

@Peter: Please read the page I linked to again. "Confirmed" is set to denote that one or more other users but the bug reporter have met the same issue. That's useful to know, of course, but it's not a prerequisite to consider a bug report "Triaged".

[Peter Matulis (petermatulis)]

I will not fill this bug with more debate on bug triaging. I defer to the ubuntu-doc and ubuntu-bugs mailing lists. Gunnar, please continue the discussion there if you want.

[Peter Matulis (petermatulis)]

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.

[larsemil (emil-larsemil)]

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/132...