Make OpenLDAP work with SSL/TLS

These instructions are for CentOS 7:

Many applications require the use of LDAP over TLS. This is also a best-practice.

However, the Linux / openldap libraries and clients now perform certificate validation.  Many private enterprises will not validate "out of the box".  This is how we assist it.

Take a company, "mycompany.com", with two Active Directory domain controllers, "dc1" and "dc2", and their own internal CA:

openssl s_client -host dc1.mycompany.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/
END CERTIFICATE-----/{print s}'> /etc/openldap/certs/DC1.MYCOMPANY.COM.crt

openssl s_client -host dc2.mycompany.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/
END CERTIFICATE-----/{print s}'> /etc/openldap/certs/DC2.MYCOMPANY.COM.crt

openssl s_client -showcerts -host dc1.mycompany.com -port 636
(copy the second certificate, between “BEGIN” and “END”, for the MyCompany CA into /etc/openldap/certs/MYCOMPANY_CA.crt)

cacertdir_rehash /etc/openldap/certs
This last command creates sym links named with the cert hash and pointing to the cert file for each cert in that directory.

CAVEAT EMPTOR: the certs will expire, and will (typically, in Active Directory) be automatically renewed; but your openldap clients/libraries will NOT be able to validate the renewed certs. You'll simply find that LDAP does not work anymore until you repeat this process to update the locally stored certs.

mod_authnz_ldap searching root of Active Directory

If you try to do as the docs say, and specify:

AuthLDAPURL "ldap://mydc.foo.com:389/DC=foo,DC=com?sAMAccountName?sub?(objectClass=user)"

...it won't work. You'll get a weird error:

[warn] [client 10.10.10.1] [14343] auth_ldap authenticate: user my-ldap-acct authentication failed; URI /repo-path [ldap_search_ext_s() for user failed][Operations error]

...and yet, binding or searching from the root works from openldap, Apache Directory Studio, and myriad other tools.

Appears to be a bug with mod_authnz_ldap.

The workaround? Make sure your DC's all have the Global Catalog role, and then search on port 3268 instead of port 389! ..or 3269 for SSL/TLS.

Works. (tested on mod_authnz_ldap v 2.2....)

Import an SSL cert from a URL

This info is from Capital City Consultants, plus some insight from this great page (http://gagravarr.org/writing/openssl-certs/others.shtml#selfsigned-openssl ), and it works:

You'll need the openssl program, from www.openssl.org

To save a cert from a web server:
openssl s_client -connect www.example.com:443

or, to save a cert from an LDAP server:
openssl s_client -host DC01.AD.example.com -port 636

..in either case, ctrl-C out of the openssl program, and copy and paste the certificate text
-----BEGIN CERTIFICATE-----
MIIBzTCCATasadfsd803tdsasdtadsa/XuDQwDQYJKoZIhvcNAQEFBQAwFDESMBAGA1UE
(snip)
zjl2l707W5pffEhKVvuG2W3ipuAtXrMgmfeWsrkQtg0e
-----END CERTIFICATE-----

into a file, e.g., www.example.com.cert .

To do that programmatically, try:
openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}'








You will find that the openssl s_client command hangs -- it is awaiting data on the established ssl connection.  You can address this programmatically by sending it the "quit" command, e.g.:

echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}'

Now, use your tool/application to import that certificate.

For Linux system openssl store:

First, get the hash of the cert:
echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' | openssl x509 -noout -hash

That will output a number like "a837f31d".

Next, save the real cert into a file by that name, plus ".0"
echo quit | openssl s_client -host DC01.AD.example.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' > /etc/pki/tls/certs/a837f31d.0

And last, create a sym-link to the hashed cert, so that you remember which is which, and so that you can update it more easily:
cd /etc/pki/tls/certs
ln -s a837f31d.0 DC01.AD.example.com.crt

For a java keystore:

keytool -importcert -keystore jssecacerts -alias www.example.com -file www.example.com.cert

Selinux tips

Here are some really good SElinux resources:

http://www.linuxsecurity.com/content/view/120567/49/
http://www.linuxsecurity.com/content/view/120622/49/
http://www.linuxsecurity.com/content/view/120700/49/
http://www.linuxsecurity.com/content/view/120837/169/
http://www.it-observer.com/articles.php?id=1013

Touch up a folder for apache to access (change file context labels recursively):
chcon -R -t httpd_sys_content_t

Touch up a folder for samba to access (change file context labels recursively):
chcon -R -t samba_share_t /backups


To reset the labels on all mounted filesystems:
restorecon -Rv /

If you need the filesystems to be relabeled on bootup, do this and then reboot:
touch /.autorelabel

To boot once with SELinux enforcement disabled, add the enforcing=0 flag to the kernel boot line.

To get the kernel's enforcement status:
getenforce

To change the kernel's enforcement status to "permissive" (aka log-only):
setenforce 0
To change the kernel's enforcement status to "Enforcing" (aka block access):
setenforce 1
(edit /etc/selinux/config to make the changes persistent across reboots)



Quickly create or request ssl certificate for Apache

#Create different directories for the different data (this is the path for RedHat derivatives)
cd /etc/httpd/conf
mkdir ssl.csr ssl.key ssl.crt
chmod 700 ssl.*

Self-Signed Certificate
# Create the cert request. Common Name (CN) should be the FQDN, e.g., myhost.foo.com
# 2048 bits is probably adequate these days. Expiration more than 5 years makes little sense.
# PEM passphrase is what the server process (or user) will have to type to use the cert; it
# can be bypassed if you want with the key file in the next step.  EDIT: current versions
# of openssl that ship with CentOS/RHEL do not let you bypass the PEM
# passphrase. Give it one, then create the key file if you want to eliminate the need for it.
openssl req -newkey rsa:2048 > ssl.csr/myhost.foo.com.csr

# create the key file, myhost.foo.com.key (careful! this makes it so that e.g. httpd will
# not prompt for the key on startup, but so that the cert is easily
# read if the host is compromised.)
openssl rsa -in privkey.pem -out ssl.key/myhost.foo.com.key

# self-sign/create the cert, myhost.foo.com.crt
openssl x509 -in ssl.csr/myhost.foo.com.csr -out ssl.crt/myhost.foo.com.crt -req -signkey ssl.key/myhost.foo.com.key

Externally signed certificate request
openssl req -newkey rsa:1024 -keyout ssl.key/myhost.foo.com.key -out ssl.csr/myhost.foo.com.csr

mail the myhost.foo.com.csr file to your ssl provider.
Make the key unencrypted if you want:
openssl rsa -in ssl.key/myhost.foo.com.key -out ssl.key/myhost.foo.com.key.unenc
...and reference the unenc file in your ssl host config file. This will prevent having to enter the encryption key passphrase every time the httpd is restarted, but it will mean your key could be compromised if the box is compromised.