本地IIS部署.NET6应用时Azure应用注册证书存放位置问题

针对你部署到Windows Server 2019 + IIS 10环境遇到的证书存储相关问题，解答如下：

关于保留CurrentUser存储配置的相关说明 #

你的推测完全正确：当应用程序池使用默认的ApplicationPoolIdentity身份运行时，代码中StoreLocation.CurrentUser对应的上下文就是该应用池专属的虚拟安全主体，格式为IIS AppPool\<你的应用程序池名称>。

这个账号是系统自动生成的本地虚拟账号，没有交互式登录权限，没法通过常规切换账号登录系统的方式导入证书，要给该账号的个人证书存储区导入认证证书，可按以下步骤操作：

• 使用PsExec命令行运维工具，以管理员身份打开命令提示符，执行以下命令，将命令中你的应用池名称替换为实际使用的IIS应用池名：

  psexec -i -u "IIS AppPool\你的应用池名称" certmgr.msc
  

• 执行命令后会自动弹出证书管理器窗口，这个窗口运行的上下文就是对应应用池的虚拟账号，此时把你的认证pfx证书导入到「个人」存储路径下即可，导入时注意根据需要选择是否允许私钥导出，牢记导入时设置的证书密码。
• 导入完成后重启对应IIS应用池，应用就能正常从CurrentUser存储区读到证书了。

关于改用LocalMachine存储配置的弊端说明 #

把代码里的StoreLocation.CurrentUser改成StoreLocation.LocalMachine，将证书安装到本地计算机存储区，是IIS生产环境非常常用的部署方案，本身没有功能性问题，但确实存在几个需要注意的安全层面的弊端：

• 访问权限范围过宽：本地计算机存储区的证书对本机所有获得私钥读取授权的账号开放，如果服务器上同时运行了多个不同业务、不同信任等级的应用/服务，一旦其他应用的运行账号被入侵，攻击者有可能直接拿到该认证证书，冒用你的应用身份访问Key Vault，造成密钥泄露。
• 私钥权限管控成本高：本地计算机存储内的证书，默认会给本地管理员组、System系统账号授予私钥的全控制权限，如果运维过程中误操作修改了权限配置，要么会导致应用读不到私钥启动失败，要么会进一步扩大证书的可访问范围，带来安全隐患。
• 多环境易混淆：如果同一台服务器上同时部署测试、预发、生产多套环境的应用，所有证书都存在LocalMachine存储区，很容易出现配置时填错证书指纹，拿错环境证书访问对应Key Vault的问题，排障成本很高。

实操建议：如果这台服务器是专属服务器，只运行你当前这一个.NET 6应用，完全可以用LocalMachine存储的方案，只需要在证书导入完成后，右键点击证书选择「所有任务-管理私钥」，删掉所有不必要的账号权限，仅给对应应用池的IIS AppPool\应用池名账号授予私钥的读取权限即可，安全性足够满足绝大多数生产场景要求；如果服务器上混合部署了多个信任等级不同的业务，再考虑使用CurrentUser存储的方案做权限隔离。

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