我之前确实碰到过一模一样的情况，来跟你拆解下可能的根本原因，以及不用硬编码协议的未来兼容方案：

根本原因 #

• .NET Framework版本差异：这是最常见的原因。不同版本的.NET Framework对TLS协议的默认支持不一样：.NET Framework 4.5及以下版本默认启用的是TLS 1.0/1.1，而从.NET Framework 4.6开始，默认会优先使用系统支持的最新安全协议（包括TLS 1.2、甚至TLS 1.3）。你提到的另一个项目大概率用了更高版本的.NET Framework，所以默认走了TLS 1.2。
• 部署环境的配置差异：另一个项目的部署环境可能已经通过系统注册表配置，强制所有.NET应用默认使用强加密协议；而AWS环境里没做这个配置，导致你的应用沿用了框架的旧默认值。
• 应用配置文件的区别：另一个项目可能在web.config或app.config里添加了专门的配置节点，强制启用了TLS 1.2，而当前项目缺少这个配置。

无需硬编码的未来兼容解决方案 #

1. 升级.NET Framework版本（推荐长期方案） #

如果项目允许，直接把.NET Framework升级到4.6及以上版本。从这个版本开始，.NET会自动继承系统的默认TLS协议设置，不需要任何代码修改，后续系统支持TLS 1.3时也能自动适配，完全符合未来兼容的需求。

2. 修改应用配置文件（快速适配方案） #

如果暂时无法升级框架版本，可以在项目的web.config中添加如下配置，强制应用使用强加密协议：

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" />
  </runtime>
</configuration>

这个配置会让.NET 4.5+的应用跳过旧的默认协议，优先使用TLS 1.2及以上版本，而且不需要改任何代码。

3. 系统级注册表配置（适合批量部署场景） #

如果是在AWS的Windows服务器上部署，可以通过修改注册表来让所有.NET应用默认启用强加密协议：

• 针对32位应用：在HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319路径下，新建DWORD值SchUseStrongCrypto，设置值为1
• 针对64位应用：在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319路径下，新建DWORD值SchUseStrongCrypto，设置值为1
  这个设置是全局生效的，后续部署的.NET应用都会自动使用TLS 1.2+，适合统一管理的环境。

另外，如果你的项目有迁移到.NET Core/.NET 5+的计划，那更省心——这些新版本的.NET平台默认就支持TLS 1.2及以上协议，完全不会出现这种默认协议过时的问题。

内容的提问来源于stack exchange，提问作者Aleksandar Trajkov