Ladislav Mrnka's questions

I spend whole day by diagnosing issue with my test services using mutual HTTPS. Services are hosted in IIS 7 on a test server running Windows Server 2008 Enterprise edition.

Suddenly few weeks ago all test services stopped working and any request to these services ended with 403.7 "Client certificate required" issue. After a lot of searching I found this article describing similar issue with Windows Server 2003.

In short the issue is caused by too many trusted root CAs installed in local machine certificate store. Server during mutual HTTPS handshake sends "list" of trusted CAs to client and client can select certificate based on this list (unless the site in IIS is configured with CTL but that is for a different question). The problem is that list can have only 16KB so if there is more CAs, they are simply not send to the client. If the used client certificate is issued by one of such truncated CAs it is not send to the server.

After that I checked local machine's trusted root certificate store and I found that there is more than 200 trusted root CAs installed. What is even worse: we didn't install them! I somewhere found a bit of information (sorry can't find it again) that these CAs are installed automatically through Windows Update.

The question: How to turn off installing CA certificates to our computer without turning off windows update?

I have windows client application and windows service hosting a web service over HTTPS (on behind it uses standard http.sys). Everything is ok except the situation where user makes a mistake and uses HTTP with HTTPS port for accessing the service. For example service is exposed on: https://somehost:9000 but user incorrectly sets http://somehost:9000.

Normally if the endpoint is not available the client receives 404 Not found but in this case the endpoint is available but the host expects SSL\TLS handshake first. When the client calls the service with pure HTTP it hangs and client waits for timeouts. Moreover I found that this is some global behavior because web services exposed on IIS over HTTPS called through browser with HTTP behaves in the exactly same way. The timeout is always 130s. Keep-alive for connections on IIS is configured to 120s so it doesn't look correlated.

What kind of timeout is used in this case? Is it possible to change it (this question is little bit abstract because I yet don't know what I want to change)?

Are there any special permissions needed for domain service account running a windows service which receives messages over named pipes? Hosting environment is Windows Server 2008.

Background:

We have two processes communicating over named pipes. Our windows service exposes WCF service over named pipes binding and a IIS worker process running on the same machine calls that WCF service.

Everything works on our development machines and test server but when we deploy the soution to integration environment the client (IIS worker) is not able to call the service with exception that there is no endpoint listening on the address. The service is up and running and based on logs the service host is listening.

The server is controlled by group policy and low priviledges accounts are used so I think it can be some problem of insufficient permissions.

I want to reproduce some production issue. For this purpose I need to configure my test Windows Server 2008 R2 to reject TLS connections and accept only SSLv3 connections when exposing IIS hosted web services over HTTPS. How can I do that?