Today, I learned why my machine at work was becoming unbearably slow – especially when doing something with certificates – like sending or receiving signed and encrypted mail. I have my settings set to check the OCSP server if there is one, or, if not, to check the CRL to make sure certificates are valid and not revoked. Week by week, my system had been getting slower and slower. I figured it was because the CRL of one of our clients was growing above 4MB, and kind of let it be. This past month, sending an encrypted e-mail to someone took almost 5 minutes just to check the validity of the certificate! I actually started to search around and see what was up.

I knew it was something to do with certificates and CRLs based on when the slowdowns were happening, but my new Pro at home wasn’t having similar issues, and my keychains are synchronized between the two machines, so I’m dealing with the same certificates. I initially thought it was just a difference in processing power: 1.8GHz G5 3GB of RAM vs 2.0GHz dual Dual Core 3GB of RAM, and shrugged it off. Then I realized, I really shouldn’t be doing *anything* that can tax the G5 that much. I know I have 5 bajillion windows open at once, but most of it’s not actually using the processing power.

I did some Googling to see if Tiger was caching the CRLs – downloading 4MB each time seemed stupid, but possible. I found that Tiger does in fact cache CRLs in /var/db/crls/crlcache.db and certtool y k=/var/db/crls/crlcache.db will tell you all about the CRLs in the cache. I looked at my cache, and I noticed a CRL that had expired in June of 2005 (?!?!?). I also noticed that I had over 500 CRLs in the cache. It was definitely caching alright. It was also neglecting to remove expired CRLs! When you’re dealing with 4MB CRLs that are issued every 6 hours (expire in one week), that’s a *lot* of disk being used for nothing. I had found my problem – now to find the solution.

Tiger has this nifty command called crlrefresh – it manages the CRLs in the cache. It’s intended to be called from cron (or periodic), but on my machine, it wasn’t. So, I refreshed the cache and purged the old CRLs (crlrefresh r p) which took almost 3 hours, but left me with 8 CRLs. I now have a script running this command every week in periodic (put it in /etc/weekly.local), and will hopefully not have any more problems with it.

I also wrote an e-mail to a contact I have with Apple’s x509 group to see about getting it resolved in either a patch or at least Leopard.