Recently, I wrote about SSL renegotiation problems caused by large requests. Unfortunately, this doesn’t cover the whole problem, which re-surfaced with the dreaded “Re-negotiation handshake failed: Not accepted by client!?” message in Apache’s error log.
In our case, this error is not caused by expired certificates, self-signed certificates in the verification chain or some other “certificate setup”-related problem. Generally, access to the server works fine with right those certificates that under specific conditions cause the error reported here.
While I took network traces and got Wireshark to decode the recorded SSL stream (which is a story all by itself – the wireshark packages as distributed by OpenSUSE aren’t compiled against the required libraries, and you have to make sure your using a decipherable encryption in the first place…), the root cause still isn’t all that clear.
The most significant symptoms are
- The problem always occurs during SSL renegotiation.
- The connection is closed by the server, not the client.
- It does have to do with the size of the request that lead to the renegotiation.
- The SSL debug log lists the rather common “OpenSSL: I/O error, 5 bytes expected to read on BIO#” message.
We’d had this on the latest SLES11 SP2 RPM for Apache, which makes itself known as
Name : apache2 Relocations: (not relocatable)
Version : 2.2.12 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Release : 1.30.1 Build Date: Fri Feb 3 17:08:52 2012
Install Date: Mon Feb 20 04:00:24 2012 Build Host: gubaidulina
Group : Productivity/Networking/Web/Servers Source RPM: apache2-2.2.12-1.30.1.src.rpm
Size : 2422606 License: The Apache Software License
Signature : RSA/8, Fri Feb 3 17:09:16 2012, Key ID e3a5c360307e3d54
Packager : http://bugs.opensuse.org
URL : http://httpd.apache.org/
Summary : The Apache Web Server Version 2.2
So what can you do? As it is a bug, I doubt too much can be done about it, except having it fixed. Of course you might try to set up the server so it doesn’t re-negotiate in the first place, but that’s not always feasible. Or you may leave the path of formally supported SLES packages – we have installed a LAMP distribution (carrying Apache httpd 2.4.3 and libopenssl 1.0.1c) in parallel to the SLES packages, and found that combination to work flawlessly.
I’ve already raised a report with Novell, since it’s a package they deliver, and hope this gets fixed soon. On the other hand, SLES11 SP3 seems to be right around the corner (I’ve read about a release date of June 2013), so hopefully that will contain the latest code both for httpd and openssl. Once we get our hands on either SP3 or a fixed release, I’ll let you know.
