Getting 413 errors on IIS with concurrent sessions using the same HTTPS client certificate

Question

I have the following problem.

I am hosting a WCF application on IIS 8 which accepts only HTTPS requests with client certificates. This service accepts POST messages which may vary in size (from a few bytes up to 1 GB) and are received parallel most of the time.

The clients are getting a 413 Request entity too large response in the following case:

• When multiple connections are opened with the same client certificate and many small files are uploaded. In this case one request succeeds and all others fail with 413 error.

The problem could be solved by setting the uploadReadAheadSize value to a larger value than the sum of all the parallel call sizes in the system.webServer/serverRuntime section of the configuration, but this causes the server to allocate the whole amount of memory for the read ahead buffer for each call which causes the server to run out of memory in case of many concurrent calls.

My configuration works if the calls are made with different client certificates or in case of uploading one big file.

I have read that with IIS 6 there was an option to set SSLAlwaysNegoClientCert in the configuration to fix a similar bug. I have tried workarounds to set this value, but did not succeed using IIS 8.0. I have also tried turning off SSL Client cache to disable SSL session resumption, but that did not solve my problem as well.

What may cause the 413 errors? Is there any way to enable multiple parallel uploads with a client certificate to the same server without using the whole memory of the server.

Answer 1

Just a guess:

If client renegotiation is requested, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions. However, if UploadReadAheadSize is smaller than the content length, an HTTP 413 error is returned, and the connection is closed to prevent deadlock. (Deadlock occurs because a client is waiting to complete sending a request entity, while the server is waiting for renegotiation to complete, but renegotiation requires that the client to be able to send data, which it cannot do).

(From the article Client cannot renegotiate request and returns an HTTP 413 error (IIS 6.0).)

Client renegotiation occurs when SSLAlwaysNegoClientCert is not set, so use OpenSSL to check if it is enabled (see this question). I have not used IIS 8, but on IIS 7.5, both ways of enabling SSLAlwaysNegoClientCert from the question you linked work for me.