TeamCity首次执行PowerShell调用SOAP服务时SSL/TLS通道创建失败

这种在CI/CD环境里碰到的“首次跑失败、手动跑正常”的问题，我之前帮不少开发者排查过，核心其实是TeamCity的执行上下文和你本地手动运行的环境差异在搞鬼，下面拆解几个最可能的原因：

1. 账户权限与证书存储的差异 #

当你手动运行PowerShell时，用的是当前登录用户的身份，系统会加载这个用户证书存储里的所有配置——包括你可能手动信任过的根CA证书，或者系统默认的信任链。但TeamCity的agent默认是用服务账户（比如Local System或者专门创建的服务账号）运行的，这个账户的证书存储和你的个人账户完全独立：

• 哪怕你写了信任所有证书的代码，某些底层SSL/TLS握手环节还是会依赖账户的证书存储，首次执行时服务账户的存储里可能缺少必要的信任条目，直接导致握手失败。
• 另外，服务账户可能没有足够权限访问系统级的证书存储，或者读取加密相关的系统资源，首次执行时的权限校验会触发SSL通道创建失败。

2. TLS协议设置的生效时机问题 #

你脚本里设置了[System.Net.ServicePointManager]::SecurityProtocol，但这个设置是进程级别的，只对后续创建的请求生效。如果你的SOAP客户端是在这段配置代码之前初始化的（比如脚本先加载了SOAP代理类，再设置协议版本），那首次执行时SOAP客户端还是会用旧的协议版本，和服务端的TLS要求不兼容。

• 手动运行时，要么之前的PowerShell进程已经有过协议设置，要么你无意识调整了代码顺序；但TeamCity每次执行脚本都是启动全新的PowerShell进程，首次执行时的顺序问题就直接暴露了。

3. TeamCity Agent的环境变量隔离 #

TeamCity agent运行时的环境变量和你桌面登录的环境完全不一样：比如USERPROFILE、APPDATA这些路径指向的是服务账户的目录，某些和SSL/TLS相关的配置缓存（比如.NET的安全策略缓存）在首次执行时可能还没正确加载。

• 另外，系统级的TLS配置（比如Schannel的注册表设置）对服务账户和普通用户的应用逻辑可能有差异，首次执行时服务账户的Schannel配置还没完成初始化，导致协议协商失败。

4. PowerShell执行的上下文隔离 #

TeamCity的PowerShell runner默认会启用-NoProfile参数，也就是不加载用户配置文件；但你手动运行PowerShell时，会自动加载个人的PowerShell profile——如果你的profile里已经隐式设置过SSL/TLS相关配置（比如提前指定了SecurityProtocol），手动运行时就自动生效了，但TeamCity里是干净环境，首次执行时设置时机不对就会出问题。

验证与解决建议 #

• 切换Agent运行账户：把TeamCity agent的运行账户改成你手动运行脚本的用户，如果之后执行正常，就坐实了是账户权限/证书存储的问题。
• 调整脚本顺序：把设置SecurityProtocol和CertificatePolicy的代码放在SOAP客户端初始化的最前面——比如在加载SOAP Web引用、创建SoapHttpClientProtocol实例之前，先执行这些配置。
• 修改TeamCity Runner设置：在PowerShell runner的配置里，禁用-NoProfile参数（如果启用的话），或者把必要的配置都写到脚本开头，不要依赖用户profile。
• 检查系统TLS注册表：确认系统已经启用了TLS 1.2/1.3，并且Schannel的相关配置（比如禁用SSL3、TLS1.0这些旧协议）对所有账户生效，避免服务账户使用被禁用的协议。

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