spoofed.org

I'm in the process of getting an internal CA off the ground, and on Thursday I found myself totally stumped for a good 6 hours with the Sourcefire systems.

I called support and asked if there was a proper, supported way to get a more official SSL certificate on the devices. To my surprise, there isn't. If you are stuck using a self-signed certificate from a CA you have no business trusting, its almost not even worth using SSL to protect the traffic on the web-based management interface. Since its just all Apache under the hood anyway, I asked if I could do it myself. After several minutes I was told that this is fine, but they could not support anything related to SSL after I went down that road.

Easy enough, I thought. Generate a large private key, generate a CSR, submit the CSR, sign the CSR and drop the new key and certificate on the Sourcefire device in /etc/ssl/server.key and /etc/ssl/server.crt, respectively. Restart apache.

To my total surprise this did not work. Re-copy the correct key and certificate, just to be sure. Same deal. Run the usual certificate and key verification:

openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

Sure enough, the MD5s are the same. What gives? Tweaking the log levels indicated that I had I definitely had the wrong key, but my commands above proved otherwise. I continued to get the following error message:

x509 certificate routines:X509_check_private_key:key values mismatch
unable to set private key

Lies.

What could it be? A private key that was too large? I tried 4096, 2048 and 1024, and oddly enough 1024 seemed to work. I was furious. Did Sourcefire really configure and ship a system that, for whatever reason, would only function with 1024 bit private keys? I took a coffee break, as I could not fathom how this was possible.

Freshly caffeinated, I took another stab at it. I put my original, 4096 bit key and corresponding certificate back in place and then started disabling the various SSL options that Sourcefire had enabled in Apache's config until I had more information. At one point I screwed up the gcache settings sufficiently enough to kill Apache. When I fixed that and started Apache, things mysteriously started working. This was the key clue. Looking at the init script that ships with Sourcefire, a 'restart' simply sends a HUP, whereas on most other systems it does a synced 'stop' followed by a 'start'.

I have not been able to prove this, but I imagine that either Apache or gcache is caching either the private key or the certificate from its last successful start, but not caching the other. The result is that, despite what you see on disk, the key and certificate that are being used do not match. Believe what you are eyes are showing you, but do not believe what Apache is telling you. A stop and a start are needed.

This is not a Sourcefire specific problem, so I hope someone stumbles upon this and it fixes their problem.