Using Bugzilla with X509 client certificates

Doing x509 authentication

Previously, we had a custom Bugzilla authentication module to do X509 client certificate checking. We now use the inbuilt Auth::WWW:Env checking, which requires the following configuration

  • auth_env_id REMOTE_USER
  • auth_env_email SSL_CLIENT_S_DN_Email
  • auth_env_realname SSL_CLIENT_S_DN_CN

Note that this also requires that mod_auth_ssl be running on the server, with the following configuration:

AuthSSLEnable on
AuthSSLDNComponent SSL_CLIENT_S_DN_UID
AuthSSLIssuer "/C=GB/ST=Scotland/O=School of Informatics, University of Edinburgh/OU=Ephemeral Key Certification Agency/CN=kx509 CA"

We do this so that only certificates signed by our kx509 CA will be trusted. Otherwise, it would appear that any client certificate signed by any of the certificates in the kx509 CA's chain would be permitted.

Upgrading

Some notes on how to upgrade the LCFG-ized bugzilla installation. Note that as of 2.19.2 we're no longer running with any local patches to the Bugzilla source. The custom X509 fixes we were using are now replaced by the new Auth::WWW::Env module in the Bugzilla source tree

  • Build a new RPM Use the existing spec file as a guide. Make sure that any files that Bugzilla changes during operation are listed as %config.
  • Mark Bugzilla as being offline Go to https://bugzilla.inf.ed.ac.uk/editparams.cgi and put a suitable message into the 'shutdownhtml' field
  • Backup the database Take a database dump with om mysql backup /root/bugzilla.dump (Note that this command only works correctly with versions of lcfg_mysql > 1.1.5)
  • Backup bugzilla's configuration The key files here are localconfig, localconfig.js and the contents of the data directory. For safeties sake, though, take a copy of the entire /var/www/html/bugzilla directory.
  • Submit the RPM
  • Manually install the RPM Rather than have the upgrade take place unattended, manually install the RPM from the command line, using rpm -Uvh /path/to/rpm. This will automatically run checkconfig.pl to update the configuration files for the new version. checkconfig may report dependency errors that weren't trapped by rpm. If so, fix them.
  • Change the hardcoded version in LCFG
  • Run checkconfig checkconfig needs to be run again, to make any database changes that are necessary for the upgrade. cd /var/www/html/bugzilla; ./checkconfig
  • Re-enable bugzilla Edit var/www/html/bugzilla/data/params and remove the text from the shutdownhtml entry
  • Run the sanity checks Go to https://bugzilla.inf.ed.ac.uk/sanitycheck.cgi
  • Test things

... and you're done. It's not pretty, but it works. I'm not sure how much of the above could be automated in some way - the problem is that bugzilla has such an incestuous releationship between its data and executables.

Gotchas this time

Because we were changing authentication methods, a load of stuff had to be set up manually, so it was actually possible to log in again. To change parameters by hand, edit the /var/www/html/bugzilla/data/params file. The defparams.pl file in the Bugzilla distribution gives an idea of the options that are required. In this case, we had to change the login methods, and setup auth_env as described above.

-- SimonWilkinson - 16 Apr 2005

Topic revision: r1 - 16 Apr 2005 - 12:57:38 - SimonWilkinson
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies