Institutional Knowledge

Are your LDAPS connections from perl scripts suddenly broken and you’re stuck staring at a screen with a seemingly useless error message?

is only avaliable [sic] with the XS version at /usr/lib/perl5/site_perl/5.8.5/IO/Socket/SSL.pm, line 30

I say seemingly because you know you didn’t change anything about IO::Socket::SSL. A few Google searches will at least fill in the blank before the is and tell you that LDAPS is unhappy.

If you are running RHEL 4, you probably had to install IO::Socket::SSL from CPAN. RedHat updated Perl 5.8.5 and some modules that required the XS (interface to use compiled C libraries in modules) version of Scalar::List::Utils. I’m not sure exactly what broke, but the easiest fix is to update IO::Socket::SSL from CPAN and it will update Scalar::List::Utils and all will be well.

In an effort to further abstract the CAS Login portion of our Ruby on Rails applications, I’ve taken our CAS Login Module and turned that into a plugin that can be included in any past or present Rails applications and managed separate from the development of the applications themselves. You can read all about how the plugin works and how to use it in your application on the Developer Wiki.

This also marks the beginning of our public Subversion repository allowing other developers to access our code via SVN. Currently, the CASLogin plugin is the only source available and only Web Services has write permissions to the repository.

Links

• http://developer.csuchico.edu/wiki/ruby_on_rails:caslogin_plugin
• http://developer.csuhico.edu/svn

technorati tags:cas, wiki, plugin, rubyonrails

Preface: I am not an expert in encryption, SSL, or LDAP. Your install may be functioning just fine and you don’t need any of this information. You use this at your own risk as it may be completely wrong. That being said, it worked for me.

Making a secure (ldaps) connection in PHP (php-4.3.9-3.8) on Red Hat Enterprise Linux AS release 4 (Nahant Update 1) will fail if on ldap_connect (“Error -1: Can’t connect to LDAP server”) if the certificate cannot be verified. Due to the release of a new intermediate certificate from Verisign, it is likely that your install of openssl will not have access to that intermediate cert. Thus openssl will tell you that there is a self-signed certificate in the chain (“Error -19”). If you recently bought a certificate from Verisign you will not find much in the way of help for dealing with LDAP, PHP, or openssl.

The answer with web servers is generally well documented, and the intermediate certificate is made available to the server to send to the client. This is good because it means that 8 trillion web browsers don’t generally need to be updated to use SSL.

It should also be noted that it is probably best to “fix” this issue at the server level rather than the client because each and every client would need to be fixed as opposed to just fixing the server once. If you do not have access to the server to fix it, this should work for you.

1. Obtain a copy of the Verisign intermediate certificate. Save it as a text file on a system where you can run openssl binaries.

2. Convert from PEM to ca-bundle format (*Update:* There is a updated script for BSD sed if you are on OS X). Save this output as you may need to do the next few steps on multiple servers.

   PLAIN TEXT
   CODE:
   

   1. #!/bin/sh
   2. # Friendly Name
   3. openssl x509 -in $1 -text -noout | \
   4. sed -n -e ’/^[ ]\+Subject:/{s/^.*CN=\([^,]*\).*/\1/;p}’
   5. # Underline Friendly Name with equal signs
   6. openssl x509 -in $1 -text -noout | \
   7. sed -n -e ’/^[ ]\+Subject:/{s/^.*CN=\([^,]*\).*/\1/;p}’ | \
   8. sed -e ’s/./=/g’
   9. # Output Fingerprint and swap = for :
   10. openssl x509 -in $1 -noout -fingerprint | sed -e ’s/=/: /’
   11. # Output PEM Data:
   12. echo ‘PEM Data:’
   13. # Output Certificate
   14. openssl x509 -in $1
   15. # Output Cettificate text swapping Certificate with Certificate Ingredients
   16. openssl x509 -in $1 -text -noout | sed -e ’s/^Certificate:/Certificate Ingredients:/’
   
   

3. Locate and backup your ca-bundle.crt

   locate ca-bundle.crt should show you where on your system this file lives. On RHEL /usr/share/ssl/cert.pem is also symlinked to your ca-bundle.crt.

4. Append the converted intermediate certificate to your ca-bundle.crt file.

   You can now test using the openssl command:

   openssl s_client -host your.ldap.edu -port 636 -CAfile /usr/share/ssl/certs/ca-bundle.crt.

   A Verify return code: 0 (ok) is what you are looking for.

5. Configure OpenLDAP on the system that PHP is running on to use your ca-bundle.crt.

   Locate your ldap.conf for OpenLDAP. On RHEL it is /etc/openldap/ldap.conf.

   Add the following: TLS_CACERT /usr/share/ssl/cert.pem (which on RHEL is a symlink to ca-bundle.crt). Thanks to Rutgers for this tidbit.

6. Restart httpd.

PHP should now successfully connect securely to your LDAP server.

Errata

Added restart of httpd (2005-09-10 11:52:00)

We now have our LDAP servers running behind a virtual host maintained by a Cisco Systems content switch. This is a very good thing as it should allow us to do LDAP maintenance in the future with minimal to no interruptions. Secure, redundant, fail-over…ahhhh, how sweet it is.