OpenLDAP certificates are signed with wrong CN

[tecoholic]

When working with replication issues in 3.0.1 I discovered that the OpenLDAP certificates are wrongly signed. The CN is supposed to be the domain name, but it is localhost. The other certificates are properly signed with domain names.

root@gluu:/etc/certs# openssl x509 -noout -subject -in openldap.crt
subject= /C=IN/ST=TN/L=Chennai/O=Test Organization/CN=localhost/[email protected]

root@gluu:/etc/certs# openssl x509 -noout -subject -in asimba.crt
subject= /C=IN/ST=TN/L=Chennai/O=Test Organization/CN=gluu.example.com/[email protected]
root@gluu:/etc/certs# openssl x509 -noout -subject -in idp-encryption.crt
subject= /C=IN/ST=TN/L=Chennai/O=Test Organization/CN=gluu.example.com/[email protected]
root@gluu:/etc/certs# openssl x509 -noout -subject -in shibIDP.crt
subject= /C=IN/ST=TN/L=Chennai/O=Test Organization/CN=gluu.example.com/[email protected]

[tecoholic]

I traced the issue to this line L1301 and the value of ldap_hostname = localhost

            self.gen_cert('openldap', self.openldapKeyPass, 'ldap', self.ldap_hostname)

I think this was done to restrict the ldap access to the localhost alone and prevent external access. But this is a restriction for the secure access of ldap servers during replication. Also clients can circumvent this by ignoring the certificates all together by setting the TLS Request to allow anything. I think it is better to sign the certificate with the domain name.

@yurem @nynymike I need inputs on this. How should we address this issue?

[tecoholic]

Also one common pattern to generate multiple certificates is to use a central CACert and sign all the application CSRs with that one cert. The CACert is distributed to the clients and any new applicaiton certificate is automatically trusted since it is signed by the same CACert.

setup.py is presently creating multiple self-signed certificates and importing all of them into the client trust store. Any change in application certificate involves deleting the old certificate from the various client trust stores and importing the new certificate.

Any reason why setup.py is not following the single CACert pattern?

[nynymike]

Most customers will replace the https cert anyway. So it's really just LDAP we're talking about?

[tecoholic]

Yes. The issue is really with LDAP. The OpenLDAP TLS page recommends using the CA cert way of doing it.

[tecoholic]

Since we are employing localhost only config for LDAP, the current system of certificate generation is fine as it is. If the LDAP server needs to be accessible over the internet via the hostname then the certificate needs to be changed. Since our setup default is localhost only, no changes are required. The sys-admin can make changes later when necessary.