我们的经典的访问时运行 Windows Server 2012 R2 的 Azure VMwww.linked.com。
我们有一些应用程序在 IIS 上运行，并与 LinkedIn OAuth API 通信，这就是我们注意到问题的地方。但只是尝试访问www.linkedin.com在IE我们得到以下结果：
以下是我们在.NET 应用程序中遇到的错误：
我们浏览了很多与更改注册表项、应用更新等相关的互联网资源，但都没有找到。我们发现，在新型托管在同一区域的 Azure VM 完全没有问题。相同的注册表设置，相同的 IE 安全设置，但经典 VM 仍然拒绝打开该站点。
看起来经典 VM 上的某个组件无法正确解析网络请求。这个问题是最近几天才出现的，之前它运行得非常好。
其他启用 TLS 1.2 的网站（例如 Google 或 Office365）可以在任一虚拟机上顺利打开。
任何建议或想法——非常感谢。
尝试修复此问题的方法：
- 按照 IE 错误窗口中的说明进行操作。
- 用过的加密确认 TLS 设置。
- 建议更新/检查 Windows 注册表设置这里和这里（以及其他建议类似内容的网站）。
- 主要尝试使用 WireShark 和一些其他工具来查找网络请求发出时经典和新型 Azure 类型虚拟机之间的区别。
这是从新类型的 VM 发出的请求的 Wireshark 输出（其中 IE 可以毫无问题地打开 linkedin.com）（屏幕截图包括 ClientHello TLS 内容）。
以下是经典虚拟机中的相同请求
不能 100% 确定这告诉了我什么，但也许在分享他们的见解时会有所帮助。
答案1
首先，按照它提供的有关启用 TLS 1.2 的说明进行操作。LinkedIn 的网站现在需要 TLS 1.2，并且不接受旧版 TLS 或 SSL。
答案2
在对两个 Wireshark 捕获（一个来自工作服务器，另一个来自发生问题的地方）进行深入研究后，我发现在请求的 Client Hello 阶段发送了不同数量的密码，见截图这里（左侧为经典 VM，右侧为新 VM）。我使用加密工具来比较两台机器之间的密码选择，并且足够正确，匹配选择已经解决了这个问题。我还注意到多协议统一问候未针对服务器和客户端协议选择（见下面的屏幕截图）。这是否是问题的一部分还有待进一步测试和调查。
不完全确定这是怎么发生的，但其中一位同事认为 LinkedIn 方面的证书更改可能是导致此问题的原因。
更新日期：2020/07/16：
经过我的同事进一步挖掘毛里求斯中，他找到了缺失的确切密码，并且需要使用自定义 TLS 工具成功调用 LinkedIn 来显示 TLS 连接。
可以找到 TLS 工具这里其输出显示了调用 LinkedIn 时使用的密码（Diffie-Hellman 短暂 Aes256 Sha384-TLS_DHE_RSA_WITH_AES_256_GCM_SHA384）
答案3
使用经典部署模型在 Azure 中创建的 Windows 虚拟机 (VM) 可以通过专用网络通道自动与同一云服务或虚拟网络中的其他 VM 进行通信。但是，Internet 或其他虚拟网络上的计算机需要终结点将入站网络流量定向到 VM。
您需要检查端点和 ACL。以下是一些相关文档。
答案4
据我所知，对于 Classic VM 和 ARM VM，出站网络流量的工作方式相同：流量只是经过 NAT，没有代理或任何其他东西对其进行检查（除非您专门部署这样的解决方案）。
该错误似乎与 TLS 有关，因此确认您的 VM 实际上能够在网络级别访问 LinkedIn：它只是无法成功与其协商 TLS 会话。
我会再次检查受影响的虚拟机中的 TLS 设置，并仔细检查它是否可以成功访问需要 TLS 1.2 的其他网站（例如 Office 365 或 Azure 服务）。
另外，请注意，如果您部署新的Azure（ARM）中的 Windows Server 2012 R2 VM，它将使用较新的 OS 映像，该映像已包含 TLS 1.2 支持；对于在 Azure Classic 中运行了一段时间的旧 VM，情况可能并非如此。