network.http.keep-alive and client certificate failure




7 years ago
7 years ago


(Reporter: John Middlemas, Unassigned)


5 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)




7 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

1. Download node.exe (Windows) from Put in /Node folder

2. Get free server cert, key, and client cert from

3. Put server cert and key in .pem files in /Node folder

4. Put client cert in FF5 (your certificates section)

5. Create /Node/server.js as follows:-

var  https = require('https'),
        fs = require('fs')

var options = {
    key: fs.readFileSync('serverKey.pem'),
    cert: fs.readFileSync('serverCert.pem'),
    requestCert: true

var server = https.createServer(options, function (req, res) {
        res.writeHead( 200, {'Content-Type': 'text/html'} )
        res.write('hello world')

6. Type 'node server.js' in windows terminal to start https server

7. In FF5 use about:config to set network.http.keep-alive false

8. Enter 'https://localhost/' in FF5 url box. Accept any security warnings, and select certificate.

9. Reload FF5

10. Open IE8 and enter 'https://localhost/' in url box. Accept any security warnings, and select certificate.

11. Reload IE8

12. Do similar to steps 8 and 9 in Chrome 12 and Opera 11.5

Actual results:

At step 8 'hello world' displays in FF5 window correctly

At step 9 I got 'The connection was reset' error.

Step 10 'hello world'

Step 11 'hello world' (no 'reset' error in IE8)

Opera 11.5 behaved the same as IE8. Chrome interestingly shows 'hello world' the first time but hangs on the reload.

Expected results:

Reloading FF5 should have shown 'hello world' as IE8 does. There is no reason the network.http.keep-alive setting should have any effect on the two browser displays since they are two separate server responses both with header Connection 'close'. Nothing is being kept alive.

This bug does not appear if the server is http type.

Also does not appear if 'requestCert: true' is removed and no certificate is involved in the requests.

If network.http.keep-alive is left as true (default) then a less obvious problem still occurs. If the reload happens more than 115 seconds after the first 'hello world' display then you get 'The connection was reset' error, otherwise not.

Basically, this behavious of firefox makes it impossible to use client certificates since the server is no good for requests separated by more than 115 seconds. After the first 'The connection was reset' error, FF5 never recovers, giving the same error repeatedly  and the server must be restarted.

IE8 on the other hand functions properly.

I am not sure if this behaviour would happen if the https server was on a real site rather than localhost.

I believe that unchecking TLS 1.0 in Options -> Advanced -> Encryption stops the '115 second' problem but not the 'network.http.keep-alive = false' problem

Very strange behaviour from FF5 since client certificates should have nothing to do with keep-alive behaviour.

Comment 1

7 years ago
Using the wireshark network protocol analyser and another PC on my LAN I was able to get some more details of what's happening.

The problem seems to be with the client and server hello handshaking.

Wireshark lists various types of protocol for client hello, e.g.

SSL client hello
SSLv2 client hello
TLSv1.0 client hello

For the first request (step 8) FF5 browser uses a TLSv1.0 client hello to which the nodejs server responds ok with a server hello. Everything fine and the browser page displays as it should.

If the nodejs server asked for a client certificate in the first request then FF5 uses an SSL client hello in the second request. If no client certificate was asked for then FF5 uses a TLSv1.0 client hello and all is ok.

The nodejs server does not respond with a server hello to a SSL client hello even though FF5 sends repeated ones until finally issuing "The connection was reset" error.

IE8 also issues an SSL client hello, but shortly after issues a SSLv2 client hello when the server did not respond to the SSL one. The server responds to the SSLv2 client hello with a server hello and all is well. This explains why IE8 (and presumably Opera) work ok on the second request.

Chrome issues two SSL client hellos and then gives up when the server does not respond with a server hello.

So it seems the IE8 behaviour is quite sensible and FF5 could be updated to mirror that.

However, the main problem may be the server for not responding to SSL client hellos. I have no idea why.

(I am no expert on SSL hanshaking and am just reporting what I saw in wireshark)


7 years ago
Summary: network.http.keep-alive causes client certificate failure → network.http.keep-alive and client certificate failure
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking

Comment 2

7 years ago
This bug was found to be a nodejs server issue. See
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.