Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.

Symptom

Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.

Apache die exakte Fehlermeldung entlocken

Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:

...
#LogLevel warn
LogLevel debug
...

Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:

...
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
...

Das Kernproblem

Eine Google-Suche führte mich auf die richtige Spur:

To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.

Quelle: Bug#620398: Apache LDAP/S Authentication Causes

Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?

Wer bürgt für die Verschlüsselung?

Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:

$ openssl s_client -connect ldap.domain.tld:636 -showcerts
depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld
  i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x
GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp
...

Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.

Gebt mir das Rootzertifikat!

Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.

Installation des Zertifikats auf dem Server

Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).

Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:

...
LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem
...

Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.