VDT logo
Search:

(Powered by Google)

Coping with frequent CRL updates

Summary

A recent VDT update, 2.0.0p5, increases the frequency that fetch-crl from once every 24 hours to once every 6 hours. This reduces the window of opportunity in which a revoked certificate can be abused. This new frequency is based on recommendations from the OSG Security Group.

This increase frequency will cause increased load on the CRL servers. The VDT does not want a sudden quadrupling of update requests to cause problems for these servers. Reducing this load will require participation from all VDT users. This document describes several techniques you can use to reduce your load on the servers as well as slightly reducing the internet bandwidth you use fetching updates.

If you have fetch-crl running automatically only on a small number of computers, typically the head node of your site, you don't need to do anything. The load you generate is not significant. You can follow this directions to lighten the load, but it is not essential.

If you have fetch-crl running automatically on a large number of computers, say on every node of your cluster, please review these directions and consider applying one of the recommendations.

Note: The directions below were written for VDT 2.0.0 and may need to be revised for other versions of the VDT.

Background

A number of VDT packages use certificates to authenticate and authorize users. These certificates are issued by trusted Certificate Authorities or CAs. Individual sites select CAs to trust, or often select groups of CAs, selected by the VDT, the OSG, or other organizations. When a site trusts a CA, they automatically authenticate (but not necessarily authorize) any users with certificates from that CA.

Occasionally it is necessary for a CA to revoke a certificate. A user's certificate might have been compromised, or upon review the certificate should not have been issued in the first place. The de-authenticate a certificate, CAs public Certificate Revocation Lists or CRLs, which are just lists of certificates which should no longer be authenticated. Individual installations need to regularly retrieve copies of the CRLs, which are then checked to ensure that revoked certificates are no longer authenticated.

There is a window between when a certificate is revoked and when an individual sites retrieves the updates CRL. During this window someone with the revoked certificate can still authenticate to the site. Updating the CRLs more often reduces this window and makes the site more secure, but uses more bandwidth and resources for the CRL server. There is a tradeoff.

The VDT provides the script fetch-crl to update local copes of the CRLs. The VDT can also set up this script to run automatically from cron. Previously the VDT would do this once per day. The VDT now checks once every six hours.

Choices

You have a number of choices for handling this change. The VDT supports four of them:

  1. Do nothing

    Run fetch-crl as documented.If you only run fetch-crl on a small number of computers, this is the recommended option.

  2. Use NFS

    You can share the certificates and CRLs on NFS or other shared file system, then only update them from a single computer. Read more about sharing the certificates and CRLs on NFS.

  3. Use Squid

    You can use the web proxy Squid to cache the CRLs. Read more about caching the CRLs with Squid.

  4. Update less often

    You can revert back to the old frequency of one update every day. Read more about updating the CRLs daily.

Other options that should work, but are not supported by the VDT include:

  1. Use a system configuration tool

    If you are already using a system configuration tool like cfengine, Bcfg2, or Puppet, you can have a single computer download the CRLs and use the configuration tool to push the updates out to individual computers. The guidelines for using NFS may be a helpful starting point for such a configuration.

Option 1: Do nothing

If you only run Fetch-CRL on a small number of computers, you can allow them to update four times as often.

  1. If you are running VDT 2.0.0p4 or earlier, update the Fetch-CRL package on all computers which have it installed.
  2. You are done!

Option 2: Use NFS

One option to reduce the load on the CRL servers is to have a single computer fetch the updates and use a shared file system like NFS to make them available to other computers. In this case we'll end up sharing both the CRLs and the CA certificates since they are in the same directory.

The example commands below assume a Bourne-compatible shell like sh or bash.

  1. Update the Fetch-CRL package on all computers which have it installed.
  2. Pick a computers to handle the CA certificates and CRL updates. We'll call this computers the Update Node.
  3. If you have not already done so, install CA-Certificates on all of the computers you want the CA certificates on, including the Update Node.
  4. Pick a shared filesystem accessible to your Update Node and the other nodes. We'll call this the SHAREDIR. The following directions assume that the SHAREDIR has the same path on all of the computers in question. Only the Update Node needs to be able to write into this directory. 
    # On both the Update Node and all other nodes.
SHAREDIR=/share
cd $VDT_LOCATION
. setup.sh
  5. On the Update Node, move the certificates to the shared directory. 
    mv globus/share/certificates-49-1/ $SHAREDIR #Update the directory as appropriate for your installation
rm globus/share/certificates
ln -s $SHAREDIR/certificates-49-1 globus/share/certificates
  6. On all of the remaining nodes, remove the certificates and link to the shared copy. 
    rm -r globus/share/certificates globus/share/certificates-49-1
ln -s $SHAREDIR/certificates-49-1 globus/share/certificates
  7. On the non-update nodes, disable vdt-update-certs and fetch-crl, if they are currently enabled. 
    vdt-control --off fetch-crl vdt-update-certs
vdt-control --disable fetch-crl vdt-update-certs

Option 3: Use Squid

You can use a centralized Squid web proxy to catch CRL requests for all of your computers.

  1. Update the Fetch-CRL package on all computers which have it installed. Note that CA-Certificates and Fetch-CRL are not required on the Squid Node unless you desire them there for your own purposes.
  2. Select a computer to run Squid. This computer will need internet access, and your other computers will need to be able to access it. We'll call this computer the Squid Node.
  3. On the Squid Node, install Squid. While you can install and maintain it yourself, these directions document using the VDT to do so. This directions also assume that these commands are run as root so that Squid can be automatically started via an init script.
    • If some of the VDT is already installed, you can reuse that installation. 
      cd $VDT_LOCATION
. setup.sh
pacman -get http://vdt.cs.wisc.edu/vdt_200_cache:Squid
    • If you do not have the VDT installed, or wish to use a separate install for Squid, you can do that as well. 
      # Create a directory for the install
mkdir vdt-squid
cd vdt-squid

# Install pacman
wget http://physics.bu.edu/pacman/sample_cache/tarballs/pacman-latest.tar.gz
tar xzf pacman-latest.tar.gz
cd pacman-*
. setup.sh
cd ..

# Install Squid
pacman -get http://vdt.cs.wisc.edu/vdt_200_cache:Squid

# Set up the environment
. setup.sh
  4. You will now need to configure Squid to allow all of your computers access. On your Squid Node you will need to edit the file $VDT_LOCATION/squid/etc/squid.conf. Search for "our_networks", which should look something like this: 
    acl our_networks src 127.0.0.0/24 127.0.0.1

    Append to that line a list of IP addresses or subnets containing all of your computers that run Fetch-CRL. For example, to add the entire private network 192.168.*, as well as the machine at 172.1.2.3, change the line to look like: 

    acl our_networks src 127.0.0.0/24 127.0.0.1 192.168.0.0/16 172.1.2.3
  5. On the Squid Node, enable Squid. 
    vdt-control --enable squid
vdt-control --on squid
  6. On any computer running the fetch-crl script, you will need to configure fetch-crl to use the Squid Node as a proxy. 
    # Replace 192.168.0.100 with the Squid Node's IP address.
# Port 3128 is the Squid default and does not need # to be 
# changed unless you have changed the Squid configuration. 
SQUID_IP=192.168.0.100:3128

cd $VDT_LOCATION
. setup.sh

# Make the local configuration directory
mkdir $VDT_LOCATION/fetch-crl/etc
mkdir $VDT_LOCATION/fetch-crl/etc/sysconfig

# Configure fetch-crl to use the Squid proxy.
FCRL_CONFIG=$VDT_LOCATION/fetch-crl/etc/sysconfig/fetch-crl
echo "http_proxy=http://$SQUID_IP" >> $FCRL_CONFIG
echo "export http_proxy" >> $FCRL_CONFIG
  7. You are done!

Option 4: Update less often

While less frequent updates increase the window during which a revoked certificate can be abused, this may be acceptable for some installations. For example, users may only be able to access nodes with less frequent updates after being authenticated by a head node or gatekeeper that does have the CRLs updated frequently. You also might be in strict control of which certificates are allowed on your computer and can quickly respond if one is compromised.

  1. If you are running VDT 2.0.0p4 or earlier, update the Fetch-CRL package on all computers which have it installed.
  2. On each computer that you wish to update less often, reconfigure fetch-crl to run only once every 24 hours. 
    $VDT_LOCATION/vdt/setup/configure_fetch_crl --interval 24
$VDT_LOCATION/vdt/sbin/vdt-control --on fetch-crl
  3. You are done!