BenV's notes

I had a few people complain about their favorite browser showing an error such as:
“Invalid OCSP signing certificate in OCSP response. (Error code: sec_error_ocsp_invalid_signing_cert)”

Or maybe like this:

Secure Connection Failed

An error occurred during a connection to notes.benv.junerules.com. Invalid OCSP signing certificate in OCSP response. Error code: SEC_ERROR_OCSP_INVALID_SIGNING_CERT

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

This was when they were going to a website that I host on my apache server that also serves this blog.
Knowing that my apache configuration is near perfect (*cough*) – at least, ssllabs.com gives this server at least an A rating – I wondered what was up with Firefox now.
At least, when testing the site in Google Chrome it worked fine.

Turns out that someone did the work for me:
Hanno Böck wrote a detailed post about the issue. Thanks Hanno, time to tweak some apache configuration and hope that Firefox steps up their game.
Thanks Hanno! 🙂

Those of you running Slackware 14 or current probably have noticed the move to the Apache httpd v2.4 already.
On my webservers I haven’t yet dared to upgrade from the stable 2.2 version, but I figured it might be a good time to test out an upgrade procedure.

Notable problems / changes

This new version of the Apache httpd brings a few things that you should really pay attention to before attempting to upgrade. Well, you could ignore it, but it would surprise me if you wouldn’t end up with a broken webserver 😉
So you might want to look into these things:

1. Configuration syntax changes
2. Handling the Pleuris-Hoeren-Paaltjes aka PHP disaster
3. Switching to the MPM-event module

Of course you’ve already done your homework and read upgrading to 2.4 from 2.2, right? 😉 (continue reading…)

Last week I upgraded our fileserver at work from Debian Lenny to Debian Squeeze.
Obviously a ton of stuff got ‘new’ (read: less ancient) versions, including Apache.
Apart from a reboot or two for new kernels and some config fixes everything went pretty smooth.

This week lotjuh ran into the problem that she couldn’t push to the mercurial repository from windows.
Strange, because everything worked fine from linux. Tested from both the windows 2008 server we have here and another windows 7 machine at home, the both broke with the same cryptic message:

c:\tmp> hg clone --insecure https://fileserver/repository
abort: error: _ssl.c:1325: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Huh. That’s weird.
Obviously google doesn’t help with this, you get some garbage results on how mercurial didn’t do jack with https certificates before version 1.7 and their struggle to implement it.

After some digging I found this in the apache logs:

[Thu Feb 17 12:10:51 2011] [error] [client 192.168.123.321] Re-negotiation request failed
[Thu Feb 17 12:10:51 2011] [error] SSL Library Error: 336068931 error:14080143:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled

Feh. Somewhere old SSL libraries are being used! Windows… .always the same.

Solution:
In your apache ssl configuration (mods-enabeld/ssl.conf on Debian), add this:

SSLInsecureRenegotiation on

Note that this obviously isn’t a great solution, but it’s the only way to get it to work on windows at the moment.

One of our customers has a website with some custom-made CMS made in php.
The customer asked us to fix some things, but since I hate touching pleuris-hoeren-product code, especially when the original coder is prutser and has never heard of templates (which is really weird, considering this is a CMS… maybe it’s just lazyness… then again, the echo "blabla\"escaping\"quotes\"is\"so\"much\"fun\n\n\n50 more lines here"; style really doesn’t show much intelligence…)

Anyway, I figured I might as well move the entire thing to an open CMS project that I’ve heard some good things about and already implements everything and more that the customer could ever want. That’s CmsMadeSimple.

Converting the old website to the new one was trivially easy. Copy/paste the stylesheet (first mistake), edit the basic template with a menu section, create the pages (copy/paste, copy/paste).
After fixing the html errors that were in the source the page looked like a pixel-perfect copy of the original.
Except for the places where the HTML errors were fixed that is. (the center class now actually worked for instance)

However, when adding the print links I ran into an interesting issue.
Adding print links is also a trivial thing, simply put {print} somewhere in the template, and possibly add some options to show an image instead of a text link etc.
However, the links were kinda broken, they gave empty pages. So I figured “duh, the print template still needs to be fixed”. However, as soon as I added the {content} tag to the template, I got a nice internal server error. WTF.

Checking the logs I could only find nice reports of this:

php-cgi[2530]: segfault at bf04b3f0 ip 08348d32 sp bf04b3f4 error 6 in php-cgi[8048000+6e9000]
php-cgi[2564]: segfault at bf639750 ip 08348d32 sp bf639754 error 6 in php-cgi[8048000+6e9000]
php-cgi[2804]: segfault at bf200230 ip 08348d32 sp bf200234 error 6 in php-cgi[8048000+6e9000]
php-cgi[2896]: segfault at bf00cbb0 ip 08348d32 sp bf00cbb4 error 6 in php-cgi[8048000+6e9000]

Well… .I expect nothing less from php. Pleuris-hoere-product. But how the heck… just because I added content to the print page? What’s so special about that?

After digging around (enabling logs etc) and enabling fopen for php (which I had disabled for security), I noticed this:

[Wed Jul 14 12:22:29 2010] [error] [client 123.611.204.37] PHP Warning: file_get_contents(http://some-site/oncmsmadesimple/) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required\r, referer: http://some-site/oncmsmadesimple/
[Wed Jul 14 12:22:29 2010] [error] [client 123.611.204.37] in /www/vhosts/some-site/cmsmadesimple/modules/Printing/Printing.module.php on line 96, referer: http://some-site/oncmsmadesimple/


AHA!. Apparently the printing module fetches the content (or at least, tries to) from the webserver, fails, and then segfaults php. Excellent code guys!
The reason for the failing is obvious from the logs here, I require authentication for the website since this is a test location that shouldn’t be public. Quick fix, allow the server to skip the login (vhost config):


AuthType Basic
AuthName "Testsite CmsMadeSimple"
AuthUserFile /lala/passwordfile
Require valid-user
Allow from 127.0.0.1
Allow from 192.168.1.1
Satisfy Any



Problem solved. (Hint Printing Module: render your own shit, don’t cheat with fopen/curl)

Oh yeah: CmsMadeSimple rocks for these simple websites where your customer wants to “change some texts and add a picture”. If they can handle word, you can make them handle this (but show them how!).
Give them permissions to add pages and nothing else, write a decent template for them, done.

As I love to tinker around with apache/php installations to get them to work as fast as possible while still keeping some security in tact, I found myself messing around with FastCGI today. But why?! Here’s why:
On this machine I previously installed suPhP to get php scripts to run as a normal unix user instead of user apache (so users have the ability to completely lock out their database settings etc for other users on that machine). However, to speed stuff up on a magento webshop I wanted to have a PHP opcode cache running (I tried out APC). (continue reading…)

It seems to be update day today….

I felt like updating my shit today. Somehow I enjoy updates so I do it whenever I see interesting stuff.
So glancing through the slackware changelog I noticed a new Apache2 version (2.2.12 with a bunch of security updates). Meh, not my favorite piece of garbage to upgrade, but local upgrades were easy enough and also the remote (slackware 11, custom builds) ones went without hickups. (continue reading…)

As usual this doesn’t work automagically (unless you’re lazy and put AllowOverride All in your vhost configs).
Wordpress wanted RewriteEngine on, but of course this disabled itself since apache didn’t like it with my default permissions.
So:

To allow Rewrite stuff in the .htaccess file, put ‘FileInfo’ and ‘FollowSymlinks’ (or SymLinksifOwnerMatch) in AllowOverride.

(of course putting the rewrite stuff in the vhost config is faster than the .htaccess stuff, but who cares)