做Dynamics CRM本地部署运维的老哥应该都有过半夜被证书搞醒的经历。证书这东西平时存在感很低一旦到了快过期或者需要更换的节点能把整个IFD登录流程弄得七零八落——用户要么连不上crm.contoso.com要么在AD FS跳转一圈之后又弹回一个401和看不懂的错误页。今天这篇就把Dynamics CRM证书更换这条线完整捋一遍从证书在环境里的作用范围到替换前要准备什么再到具体的IIS、AD FS、CRM三层更新步骤最后把常见的坑也一并列出来。不敢说能覆盖所有版本的所有细节但只要你的环境是“Dynamics CRM/365本地部署 IFD AD FS”的经典架构照着这个思路走证书更换基本不会翻车。1. 证书在Dynamics CRM环境里到底扮演什么角色1.1 一张证书牵动了哪些组件很多第一次做证书更换的同学以为“换证书”就是把新证书导进服务器然后去IIS里把站点绑定点一下。这个理解放在普通网站没问题但在Dynamics CRM的IFD架构里证书不是一个孤立的东西它同时挂在三四条信任链上任何一环没跟上登录流程就断。先说最直观的HTTPS加密层。CRM的Front End站点、VDir站点、还有诊断相关站点都绑在IIS的443端口上浏览器和CRM服务器之间的大多数流量靠这份证书做TLS加密。用户访问crm.contoso.com或者SDK接口第一步就是校验这张证书。这个没换对用户连页面都打不开。第二环是AD FS侧。AD FS自己也有两个层面的证书一个是AD FS网站本身的SSL证书也就是用户浏览器走到https://sts.contoso.com时校验的那张另一个是令牌签名证书AD FS用它的私钥对SAML令牌做签名CRM用它的公钥验证这个令牌是不是真的来自受信任的AD FS。后者一旦更换CRM那边的配置如果不跟着改登录流程就会在“AD FS认证成功、跳转回CRM”的时候断掉。第三环是CRM部署级别的配置。在Deployment Manager里有一块Claims-Based Settings里面存了AD FS的联邦元数据地址、联合标识符以及用于验证令牌的证书信息。这份配置实际上落到了MSCRM_CONFIG数据库的FederationProvider表里。所以你看同一个“证书更换”动作实际要改的是三四处不同位置不是IIS一个地方能搞定的。另外补充一句如果你的环境里还用了Server-to-Server认证、Webhook、外部自定义服务等场景那可能还会涉及额外的应用证书。这类证书和IFD登录链路无关别混为一谈。咱们这篇文章先聚焦经典的IFD AD FS登录链路。1.2 怎么判断你的环境需不需要换证书判断时机其实没那么玄乎常见的信号有这么几类第一类是证书即将到期。证书有效期在Windows服务器上一般会有事件日志警告通常在到期前60天或者30天开始出现。你可以打开事件查看器翻到System和Application日志搜Crypto、Certificate、AD FS相关的警告。还有更直接的办法去certlm.msc里看一眼NotAfter字段。第二类是用户已经开始报错。比如浏览器访问crm.contoso.com提示“连接不是私密连接”或者在AD FS登录成功后跳回CRM时报401、403、证书验证失败之类的错误。这种报错未必都是证书到期也可能是私钥权限、证书链不全、SAN不匹配导致的但无论如何都该去查证书状态。第三类是主动变更需求。比如公司换了根CA、内部证书要改成商业证书、SAN清单里要加新的访问域名、或者原来证书是单域名证书要升级成通配符证书。这种主动变更反倒是最好的时机因为你可以提前规划维护窗口而不是等化了再救火。我个人的习惯是不管有没有收到警告每季度用PowerShell把CRM相关服务器的证书状态刷一遍看一遍NotAfter和SAN列表比什么都安心。尤其是证书链里的中间CA证书经常被忽略出了问题很难一眼定位。2. 证书更换前必须做好的准备2.1 证书申请与SAN命名清单换证书的第一步不是去服务器上导入证书而是先把SAN清单理清楚。证书的Subject Alternative NameSAN决定了它能为哪些域名做加密少一个域名用户访问特定地址就会报证书不匹配。以一套经典的CRM IFD环境为例通常要覆盖这些地址CRM主入口https://crm.contoso.com如果有多个组织可能有对应的组织入口比如https://dev.contoso.com、https://test.contoso.comAD FS的入口https://sts.contoso.com注意很多时候CRM和AD FS用的是同一张证书也可能是两张不同的证书。如果你们环境里STS是个单独的域名那就需要确认你准备申请的这张证书把sts.contoso.com也覆盖进去了否则只改CRM侧AD FS那一段还是会报证书错误。申请证书之前我建议先把现有证书的SAN列表导出来做对照$oldCert Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -eq 旧证书指纹 } $oldCert.DnsNameList | ForEach-Object { $_.Unicode }拿到当前SAN清单之后检查一下有没有需要新增的域名确认没问题再去走证书申请流程。一定要记住新证书的SAN清单必须完全覆盖旧证书的SAN清单除非你确认某个域名确实已经不再使用。漏掉一个域名你就等于给自己埋了一个后期必现的故障。另外如果你的证书来自内部CA要确认证书模板支持SAN自定义一般的Web Server模板都可以但在证书申请请求里要正确配置。如果来自商业CA申请时也要把SAN清单填完整商业CA对这个字段查得很严。2.2 备份、快照与回滚方案证书更换这件事最怕的不是操作不熟而是出了问题没有回头路。所以动手之前必须做四件事。第一件备份IIS的配置。IIS的站点绑定信息都在applicationHost.config里稳妥的做法是交给IIS自带的备份机制%windir%\system32\inetsrv\appcmd.exe add backup PreCRM2024CertChange这个命令会把IIS的配置快照存到系统目录下想回滚的时候用appcmd restore backup就能恢复。第二件导出旧证书的PFX。就算你是“正常到期替换”旧证书的私钥备份也建议保留一份存到加密的U盘或者密码保险库里。万一新证书导入后立即出问题把旧证书绑回去就能快速恢复。第三件记录AD FS当前状态。在AD FS服务器上跑一遍下面的命令留个截图或者文本记录Get-AdfsCertificate -CertificateType Token-Signing | Format-List Thumbprint, IsPrimary, IsSecondary Get-AdfsCertificate -CertificateType Token-Decryption | Format-List Thumbprint, IsPrimary, IsSecondary Get-AdfsProperties | Select-Object AutoCertificateRollover记录的目的是让你在最后清理阶段知道哪张证书是旧的哪张是新的别一不留神把新证书删了。第四件确认CRM部署配置里的当前值。打开Deployment Manager进入Claims-Based Settings相关的页面把当前显示的AD FS地址和证书指纹记录下来。有条件的话给MSCRM_CONFIG数据库做一个备份虽然一般用不到但这是最保险的回滚依据。维护窗口也要提前定。整个切换动作正常来说可以控制在半小时以内但验证时间、回滚时间都要留出来。我建议至少预留两小时并且通知业务方在这个时间段内不要做数据批量导入、不要跑关键报表。3. 证书替换实操全流程3.1 第一步IIS站点绑定更新先说CRM侧。把新证书导入到CRM服务器本地计算机的个人证书存储这步在certlm.msc里做就行路径是“本地计算机 → 个人 → 证书”导入PFX时记得把“导出私钥”勾上。如果证书是内部CA发的还得确认根证书和中间证书也在这个环境里否则IIS绑定和客户端校验都会出问题。然后确认新证书的SAN对不对$newCert Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -eq AA11BB22CC33DD44EE55FF66778899AABBCCDD } $newCert.DnsNameList | ForEach-Object { $_.Unicode }接下来更新站点的HTTPS绑定。我用的是PowerShell批量更新避免漏掉站点Import-Module WebAdministration $thumb AA11BB22CC33DD44EE55FF66778899AABBCCDD $newCert Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Thumbprint -eq $thumb } $sites (Microsoft Dynamics CRM Front End, Microsoft Dynamics CRM VDir) foreach ($siteName in $sites) { $bindings Get-WebBinding -Name $siteName -Protocol https foreach ($b in $bindings) { $b.AddSslCertificate($newCert.GetCertHash(), My) Write-Host $siteName 绑定的证书已更新为 $thumb } }这里要特别强调一下VDir站点很容易被漏掉。有些运维只改了Front End站点的绑定结果SDK接口、Web Services地址还是旧证书用户正常网页能开但Outlook客户端、数据导入服务这类走接口的工具就会报证书错误。所以批量脚本一定要把VDir也带上。改完绑定之后检查一下所有HTTPS绑定是不是都已经指向新证书Get-WebBinding | Where-Object { $_.Protocol -eq https } | Format-Table Site, HostHeader, CertificateHash如果某个绑定还是旧指纹单独再处理。这里我踩过的坑是有的环境里同一个站点可能有多个HTTPS绑定分别绑定不同主机头如果你只改其中一个其他绑定依然是旧证书。务必用上面的命令全量扫一遍。3.2 第二步AD FS证书轮换AD FS这边涉及两类证书先说SSL证书。AD FS网站的HTTPS绑定也要换成新证书操作和在CRM服务器上一样去AD FS服务器上更新对应IIS站点的443绑定。AD FS站点多数情况下是“Default Web Site”但也可能改过名实际以你的IIS为准(Get-WebBinding -Name Default Web Site -Protocol https).AddSslCertificate($newCert.GetCertHash(), My)ACE完了SSL绑定接下来是整个证书更换里最关键的一步令牌签名证书的轮换。AD FS允许同时存在主证书和次要证书官方推荐的做法是先把新证书添加为次要证书确认一切正常后再把它升为主证书旧证书自动降为次要最后再清理。在AD FS服务器上执行# 查看当前令牌签名证书 Get-AdfsCertificate -CertificateType Token-Signing | Select-Object Thumbprint, IsPrimary, IsSecondary # 添加新证书为次要证书 Add-AdfsCertificate -CertificateType Token-Signing -Thumbprint AA11BB22CC33DD44EE55FF66778899AABBCCDD # 再确认状态新证书应该是 IsSecondaryTrue Get-AdfsCertificate -CertificateType Token-Signing | Select-Object Thumbprint, IsPrimary, IsSecondary # 确认无异常后把新证书升为主证书 Set-AdfsCertificate -CertificateType Token-Signing -Thumbprint AA11BB22CC33DD44EE55FF66778899AABBCCDD -IsPrimary $true # 重启AD FS服务让配置彻底生效 Restart-Service adfssrv升为主证书这个动作做完了别忘了去浏览器打开AD FS的联邦元数据地址确认元数据里公布的是新证书https://sts.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml打开后搜索X509Certificate或者直接看证书信息如果元数据里还是旧证书说明AD FS服务还没刷新完毕等一会再刷新页面。这里说下为什么不要直接删旧证书。SAML令牌有一定的生命周期用户和客户端可能缓存着旧的令牌AD FS也可能会验证旧令牌的签名。旧证书保留为次要证书一段时间能保证过渡期内的认证请求不会因为签名证书不匹配而失败。直接一步到位删掉旧证书很容易造成一段时间的登录抖动。如果你的AD FS是一个多节点农场切记要把新证书导到每一台节点的本地证书存储里AD FS配置可以同步但证书文件本身不会自动复制到所有节点。3.3 第三步更新CRM部署配置中的令牌证书这步是很多人最容易漏的也是导致“AD FS登录成功但跳回CRM报401”的头号原因。CRM在验证AD FS签名令牌时用的是部署级别配置里保存的那份证书信息。AD FS那边证书换了CRM这边还拿着旧指纹两边对不上验证自然失败。操作入口在Deployment Manager。在部署节点上右键进属性找到Claims-Based Settings相关页签具体名字在不同版本里可能略有差异比如Claims、身份验证、Authentication之类但本质一样。页面里会显示当前的AD FS联合元数据地址、联合标识符、当前使用的证书指纹等信息。把证书区域切换到新证书确认后保存。保存之后别急着走在CRM服务器上重置IIS让应用程序池把新配置加载进来。最省事的命令是iisreset /noforce如果不想整个IIS重启也可以找到CRM对应的应用程序池单独回收Import-Module WebAdministration Restart-WebAppPool -Name CRMAppPool应用程序池的真实名称每个环境不一定一样先GET一下池列表再回收别硬写。这个动作的目的是让CRM进程重新读取FederationProvider表里的证书信息。有朋友会问Deployment Manager里看不到新证书怎么办这种情况十有八九是证书没装到当前服务器本地计算机的个人存储里或者证书不带私钥。去certlm.msc确认一下然后关掉重新打开Deployment Manager再看。如果还是不行确认一下AD FS新证书到底是不是已经设为主证书有些版本里CRM去读取证书时要求它是当前主证书。3.4 第四步验证与收尾证书换完不是直接宣布结束验证环节至少要走一遍而且要用不同角度去验。第一浏览器验证。最好用无痕窗口直接访问crm.contoso.com看是否会跳转到sts.contoso.com登录用户名密码之后是否能正常跳回CRM并进入应用。这一步过了说明整条IFD链路基本通了。第二接口验证。如果你有Outlook客户端、数据集成工具或者任何调用CRM Web Services的程序挑一两个重点场景测一下。重点看它们访问的是不是VDir地址证书错误有没有消失。第三证书链验证。在浏览器里点开证书信息确认系统识别到的证书链是完整的没有“无法验证到此证书的颁发者”之类的提示。如果证书来自内部CA客户端机器上必须安装了根证书和中间证书这个可以通过组策略统一下发。第四日志验证。CRM服务器上查看事件查看器里的Microsoft Dynamics CRM日志确认没有令牌签名相关的错误。AD FS服务器上也翻一下AD FS日志确认没有证书相关的告警。验证通过之后再等一段时间再做清理。我的习惯是至少等一周确保不会有用户拿着旧令牌访问系统。清理的时候把AD FS里次要的旧证书移除Remove-AdfsCertificate -CertificateType Token-Signing -Thumbprint 旧证书指纹同时把本地证书存储里的旧证书删除但PFX备份保留一段时间至少放在安全的位置存到下次证书更换之后。4. 常见问题与排查技巧实录4.1 登录AD FS成功后跳回CRM却报401这是证书更换后最多发的故障没有之一。用户输入账号密码AD FS都显示登录成功了结果浏览器跳到CRM地址时冒出一个401或者“签名验证失败”。原因基本锁定在CRM部署配置。AD FS的令牌签名证书已经换了但CRM的Claims-Based Settings里还留着旧证书指纹导致CRM验证不了新证书签发的令牌。解决办法就是按3.3的流程到Deployment Manager里把证书更新掉然后重置IIS。这里有个细节容易踩如果你只把新证书添加为AD FS次要证书还没升为主证书CRM的Claims设置页里有概率认不出这张证书所以建议先升主再改CRM配置。4.2 换完证书后浏览器提示证书链不完整这个现象常见于内部CA换证或者从根CA换到企业CA的场景。浏览器打开页面地址栏显示锁是红的或者带感叹号点开证书详情提示“无法将此证书验证到受信任的根证书颁发机构”。根子在于客户端不信任签发新证书的CA。就算服务器端证书导得再对客户端的“受信任的根证书颁发机构”和“中间证书颁发机构”存储里没有对应CA证书信任链就建立不起来。解决办法是把根CA证书和中间CA证书通过组策略或MDM下发到所有客户端。在服务器端也要确认本地机器上已经完整安装了证书链否则IIS在TLS握手时就不会把中间证书返回给客户端。4.3 主站点了新证书但部分接口地址仍然报证书错误这个就是我在3.1里反复强调的“VDir遗忘症”。主站点看着一切正常网页能开但SDK、Web Services、Outlook客户端这类走接口的路径还是旧证书。排查方法特别简单全量遍历所有HTTPS绑定按证书哈希筛选Get-WebBinding | Where-Object { $_.Protocol -eq https } | Select-Object Site, HostHeader, sslFlags, CertificateHash把输出里的证书哈希和旧证书指纹比对只要有HTTPS绑定还是旧指纹就继续替换。多组织环境尤其要注意每个组织可能有独立的Front End入口它们的绑定不一定都挂在同一个站点下。4.4 签发证书时间与客户端时间不一致之类的小问题这类问题相对少见但也值得提一下。如果客户端机器时间偏差过大即使证书本身没问题浏览器也会因为“证书尚未生效”或“证书已过期”报错。排查时看一眼客户端时间再跟服务器时间同步一下就行。另外别忽略文本框里的主机名——你访问crm.contoso.com证书里的SAN必须包含crm.contoso.com这个不匹配也是高频报错点。现象大概率原因解决方向网页提示证书过期/不受信任IIS绑定未全部更新、证书链缺失全量更新HTTPS绑定下发CA证书AD FS页面提示证书错误STS站点IIS绑定未更新或SAN缺域名更新AD FS服务器上的IIS绑定登录成功但跳回CRM报401CRM部署配置仍用旧令牌证书更新Claims-Based SettingsOutlook或SDK接口报证书错误VDir站点绑定漏改按证书哈希全量扫描绑定AD FS控制台看不到新证书证书未导入本地个人存储或缺少私钥重新导入PFX并确认可导出私钥我个人在实际操作中还有个小习惯证书更换完成后把新证书的指纹、SAN清单、过期时间、换证日期记到运维文档里顺便在AD FS和CRM两侧各留一份当时的PowerShell输出。下次再做同样操作翻一下记录就能快速确认环境里哪些位置还挂旧证书。证书这事儿最怕的不是过程繁琐而是你以为全换完了结果某个角落漏了一个绑定半夜又得爬起来收尾。