Windows Server 2008 R2似乎支持TLS 1.1和1.2，但默认情况下它们是禁用的。
为什么他们默认禁用？
他们有什么缺点吗？
Server 2008 R2 / Windows 7引入了对Windows的TLS 1.1和TLS 1.2支持，并且是在TLS 1.0易受攻击之前发布的，所以它可能只是TLS 1.0的默认，因为它是使用最广泛的TLS版本当时Server 2008 R2发布（2009年7月）。
不知道你是怎么知道的，或者找出了“为什么”做出了一个devise决定，但是鉴于Windows 7和Server 2008 R2在Windows系列中引入了该function，而Windows Server 2012默认使用了TLS 1.2，似乎表明这是一个“事情已经完成”的问题。 TLS 1.0仍然“足够好”，所以它是默认的，但TLS 1.1和1.2支持前向支持和前向可操作性。
这位来自微软员工的technet博客build议启用TLS的新版本，并注意到（截至2011年10月）：
在Web服务器中，IIS 7.5是唯一支持TLS 1.1和TLS 1.2的服务器。 截至目前，Apache不支持这些协议，因为OPENSSL不包括对它们的支持。 希望他们能赶上行业的新标准。
这进一步支持这样的想法，即在Server 2008 R2中，默认情况下，新的TLS版本并未启用，原因很简单，因为它们较新，当时没有得到广泛支持或使用 – Apache和OpenSSL甚至不支持它们，更不用说了使用它们作为默认值。
有关如何启用和禁用各种SSL / TLS版本的详细信息，请参阅Microsoft知识库文章编号245030，标题为How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll 。 显然， Client密钥控制Internet Explorer， Server密钥覆盖IIS。
我在想自己…也许只是由于当时已知的兼容性问题…我发现这个MSDN博客条目（从2011年3月24日）：
它讨论了一些Web服务器在响应不支持的协议请求的方式上“行为不端”，导致客户端不能回退到受支持的协议，最终导致用户无法访问网站。
在这里引用部分博客条目：
服务器不应该以这种方式运行，而是希望仅仅使用它支持的最新的HTTPS协议版本（例如“3.1”又称为TLS 1.0）来回复。现在，如果服务器在这个时候正常closures连接， WinINET中的代码会回退并重新尝试连接，只提供TLS 1.0。WinINET包含代码，例如TLS1.1＆1.2回退到TLS1.0，然后回退到SSL3（如果启用），然后是SSL2（如果启用）。性能下降是性能 – 新的较低版本握手所需的额外往返通常会导致数十或数百毫秒的损失。
但是，该服务器使用TCP / IP RST中止连接，该连接将禁用WinINET中的回退代码，并导致整个连接顺序被放弃，导致用户使用“Internet Explorer无法显示网页”错误消息。