我还没有完全掌握 ADFS 2.0 / 3.0 中依赖方令牌签名证书的功能。一旦自动自签名证书轮转发生（默认情况下），在某些情况下，您必须手动将新的令牌签名证书交付给（通常）外部 SSO 应用程序提供商，以便他们将新证书放在他们的终端，这样 SSO 才能继续运行。
然而，这能自动发生。我发现最好的解释如下：
[ADFS] ... 可以在到期前自动更新自签名证书，并且如果为自动联合元数据更新配置了信赖方信任，自动向依赖方提供新的公钥。这种自动化功能可实现弹性、低维护的联合服务，因为服务使用的密钥证书不需要定期关注。
问题是：我如何知道依赖方信任是否已配置为自动联合元数据更新？信任中的设置是否简单明了（感谢 Google 图片搜索）：
如果是这样，我如何确保更新已成功（除了可能的“上次检查”日期）并且依赖方已自动获取新证书或其公钥？
答案1
SAML2 和 WS 联合信任中存在多个证书。这里我将忽略服务器 https url 的 TLS 证书（ADFS 称之为通信证书）。
每一方都可以拥有一个签名证书。该方发送的消息使用该证书的私钥进行签名。SAML2 各方通常对请求和响应进行签名。WS-Federation 被动方不会对请求进行签名（因此被动 RP 没有签名）。签名证书在元数据中发布。在滚动更新期间，可以有两个（旧的和新的）。
每一方都可以拥有一个加密证书。当向拥有加密证书的一方发送请求或响应时，该证书的公钥可用于加密加密密钥。使除了目标之外的所有人都无法读取该消息。加密证书在元数据中发布。大多数情况下，元数据中只发布一个加密证书。但旧证书在一段时间内会被接受，以使过渡无缝衔接。
ADFS 的自动滚动功能很棒。我建议您保留它，或者用有效期为 10 年的自签名证书替换它。如果 ADFS 有其合作伙伴发布的元数据的 URL，则 ADFS 将遵循其合作伙伴发布的元数据。
WS-Fed 领域的依赖方读取 Microsoft .NET（也称为 WIF）应用程序。这取决于应用程序。应用程序可以发布其元数据，这对 ADFS 管理员来说很好，因为他们不必输入很多内容，减少了带外错误通信等。对每个人都有利。因此，每个应用程序都应发布其元数据。对每个人都更好。但对于被动的 WS-Fed 依赖方来说，不会有签名证书。可能会有加密证书。.NET 有类来读取和生成 System.IdentityModel.Metadata 中“每个请求”的元数据。互联网上有几个示例。其中一个例子是在 Thinktecture IdentityServer 中。
依赖方可以读取 ADFS 元数据。始终有一个计划任务可用。它确实读取了 ADFS 元数据，然后更新了应用程序的 web.config 文件。我从未使用过它，因为它有池回收的副作用（即使没有变化），并且它确实用旧版本的 web.config 破坏了目录。如果您在编写读取器或写入器时遇到困难，请离线联系我。它可以用于任何应用程序（也适用于 SharePoint）。这是一个成本问题，手动执行（每年一次）或编写代码自动执行。
答案2
当回复方使用您的 AD FS 服务时，您无法控制回复方应用程序的工作方式。您需要与他们合作以减少服务停机时间。
答案3
这能自动发生。
不仅如此，它确实会自动发生！您的证书每 X 天自动更新一次，X 是属性“CertificateRolloverInterval”的值（或者可能是“CertificateDuration”，我对此表示怀疑；运行 Get-ADFSProperties 来检索它们）。
如何知道依赖方信任是否已配置为自动联合元数据更新？
你无法知道...这是不是由您的 ADFS 服务器控制。另一方决定是否定期检查您的元数据。显然，如果您更改了证书，并且 SSO 中断，那么您就知道另一方没有验证您的 ADFS...
您的打印屏幕显示相反的内容，即显示您正在检查对方的元数据。如果您将此打印屏幕发送给您的合作伙伴，他们就会知道他们可以“安全地”更改其证书。
最后要说的是：根据我的经验，唯一内置此“自动更新”功能的应用程序是 ADFS 本身。甚至 Sharepoint 和 Dynamics CRM 都没有此功能。所以我觉得它没什么用。
总而言之，我的建议是禁用 ADFS 的“AutoCertificateRollover”属性，并自行管理证书。这样做的好处是，您可以使用自己想要的证书，并选择到期日期（对于测试环境，将到期日期设置为 50 年后，非常有用）。并在日历中写下一个大提醒，以便在证书即将到期时更新您的信任！