在 macOS 26.4 上审计 MDM 服务器，而不是 27

Apple 关于审计 OS 27 TLS 变更的指引里有一句话，多数管理员会一眼扫过：如果测试设备运行的是 27 或更高版本，并且遇到连接错误，请改用运行 26.4 或更高、但低于 27 的设备重新测试，因为“不合规的连接会被阻断，而这些失败的连接可能导致工作流中后续的连接无法得到测试”。²

在新系统上测试，只能揪出一台有问题的服务器，其余的都被藏了起来。 在 27 上，不合规的连接直接失败，依赖它的工作流随之中止。后续环节根本没有机会运行，自然也就无从测试。而在 26.4 到 26.x 上，同样的问题只表现为警告——走一遍流程，就能把所有不合规的服务器全部暴露出来。

Apple 明确写下的有两点：在 27 或更高版本上，“不合规的连接会被阻断，日志消息也从警告变为错误”；以及应当在 26.4 或更高、但低于 27 的版本上测试，“以便识别出所有受影响的服务器”。² 至于这些较早版本上连接确实能够建立完成，属于合理推断而非原文照录，但这条建议只有在连接能完成的前提下才说得通。如果 26.4 上的连接同样被阻断，工作流会和 27 上一样被截断。

人的直觉是在引入变更的那个版本上测试。可在这件事上，直觉给出的是一份不完整的清单，剩下的部分只能等到生产环境里一台一台地暴露。

TL;DR

从 iOS、iPadOS、macOS、watchOS、tvOS 和 visionOS 的 27.0 版本开始，部分系统进程会对以下场景涉及的连接强制执行更严格的 TLS 要求：MDM、声明式设备管理、自动化设备注册、配置描述文件安装、App 安装（含企业级分发）以及软件更新。¹ 服务器必须支持 TLS 1.2 或更高版本，并使用符合 ATS 要求的密码套件和证书。¹ SCEP 服务器和内容缓存服务器不在此列。² 您自己 App 的网络请求不受影响。审计请在 26.4 到 26.x 上做——违规在这些版本上只记录为警告，不会阻断连接——具体做法是安装网络诊断日志描述文件，再采集一份 sysdiagnose。²

真正受影响的范围

这项变更适用于一份具体的系统活动清单，而不是笼统的网络流量。¹

• 移动设备管理（MDM）
• 声明式设备管理（DDM）
• 自动化设备注册
• 配置描述文件安装
• App 安装，包括企业级 App 分发
• 软件更新

有两项豁免值得留意，因为它们恰恰是管理员容易白白排查一整天的那类服务器：安装配置描述文件或解析 DDM 资源时与 SCEP 服务器建立的连接，以及与内容缓存服务器建立的连接——即便请求的是 App 安装或软件更新所需的资源。²

对于顺着标题找过来的开发者，有一点必须说清楚：这项变更针对的不是您 App 里的 URLSession 流量。它管的是设备管理基础设施。自从 App 链接 iOS 9.0 与 macOS 10.11 SDK 起，App Transport Security 就一直在约束 App 的网络行为。³ 27 带来的变化在于，一批系统进程开始对管理流量施加类似的要求。

受影响的平台范围，也比“企业 Mac 设备群”这个印象要宽。Apple 点名的是 iOS、iPadOS、macOS、watchOS、tvOS 和 visionOS。² 会议室里的 Apple TV 和设计工作室里的 Vision Pro，走的是同一套注册基础设施。

权威来源里的具体要求

Apple 的支持文章写明：服务器必须支持 TLS 1.2 或更高版本，使用符合 ATS 的密码套件，并提供满足 ATS 标准的有效证书。² 细节在 ATS 文档里，那才是真正该照着做的页面。³

默认的服务器信任评估必须通过：签名完整、证书未过期、名称与服务器的 DNS 名称匹配，且证书链能上溯到某个锚点证书，而签发该锚点的 CA 要么内置于客户端系统，要么由用户或管理员安装。³

在此之上，ATS 还额外要求：³

• 证书使用至少 2048 位的 RSA 密钥或至少 256 位的 ECC 密钥签名
• 证书使用摘要长度至少 256 位的 SHA-2
• TLS 1.2 或更高版本
• 数据传输使用 AES-128 或 AES-256
• 通过 ECDHE 密钥交换实现完全前向保密

最后两条很少出现在这次变更的各种摘要里，连 Apple 为审计发布的违规对照表也没有列出。管理员若只修日志点名的问题，密码套件的选择上依然可能不合规。

趁变更还没咬人，先做审计

Apple 记录的流程相当具体，每一步都有存在的理由。²

测试设备使用 26.4 或更高、但低于 27 的版本。 这正是整件事的诀窍所在。违规只记为警告，连接照常建立，工作流会继续走到下一台服务器。

先安装网络诊断日志描述文件，然后重启。 必须在任何测试开始之前安装，否则日志事件不会携带识别不合规连接所需的细节。

iPhone 或 iPad 上的自动化设备注册，需要用 Mac 版 Apple Configurator，在设备进入设置助理的“设备管理”面板之前把描述文件装好。注册流量发生得很早，事后再装就抓不到了。

跑一遍您平时的工作流。 注册设备、安装 App 和描述文件，把所有会与您服务器通信的环节都走一遍。目标是让每一台可能受影响的服务器都产生流量。

采集 sysdiagnose， 拷到 Mac 上，展开归档，然后在其顶层目录中筛选日志：

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

每条事件都带有 Domain（域名）、发起连接的 Process（进程），以及指明违反了哪项约束的 Warning（警告）。一次连接若同时违反多项要求，可能产生多条警告。²

要覆盖的是配置，不只是设备。 Apple 给出的几个维度值得照搬：环境（生产、预发布、测试）、设备类型、角色（用户组、自助终端、共享设备），以及注册类型（自动化设备注册、账户驱动、描述文件驱动、共享 iPad）。² 不同配置访问的服务器不同，其中一种审计干净，说明不了另一种。

watchOS 无法用这套方法审计。 它的大部分网络请求发生在进程之外，log 命令派不上用场。Apple 的建议是：在 iOS 上测试很可能已足以覆盖 Apple Watch 的连接。²

读懂违规记录

Apple 把失败分成两类，第二类正是那些“看起来合规”的服务器栽跟头的地方。

一般性 ATS 策略违规，日志记为 Warning [ATS violation]：²

表里还藏着一条实用的豁免：如果未通过信任评估的那张证书属于自动注册描述文件中的锚点证书，则无需整改。²

FCP v2.1 违规，日志记为 Warning [ATS FCPv2.1 violation]：²

最后一行才是最出人意料的那条。 一台服务器完全可以满足最显眼的那项要求——用现代密码套件和有效证书协商出 TLS 1.2——却依然失败，因为 TLS 功能包（Functional Package for TLS）还额外要求扩展主密钥扩展。Apple 给出的整改方案是升级到 TLS 1.3，或至少把 TLS 1.2 配置为协商 EMS。²

这里有个容易混淆的细节，值得分清楚。ATS 的 FCP v2.1 合规模式对 App 而言是选择性启用的，通过 NSRequiresNIAPTLSPackageVersion 开启，服务于受监管的环境。³ 这个开关管的是您 App 自身作为客户端的行为，与 OS 27 的系统进程无关——不管您名下有没有哪个 App 启用过什么，那些系统进程都会对您的服务器执行 FCP v2.1 检查。

27 上会发生什么变化

在 27 及更高版本上，不合规的连接会被阻断，日志消息也从警告变成错误。²

Apple 指出，有几类警告并没有直接对应的错误；而对于密码套件、TLS 版本和签名算法方面的问题，客户端具体报出什么错误“可能取决于服务器如何处理该状态”。² 不要指望警告与错误之间有一一对应的映射。

Apple 记录的唯一一个具体错误，对应的是被阻断的明文 HTTP，包括重定向最终落到 http:// URL 的情况：²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

整改之后要验证单台服务器，nscurl 可以用不同的 ATS 例外组合去连接，从而缩小范围、定位究竟是哪项要求没过，不必再走一遍完整的 sysdiagnose 流程。³

整改具体要做什么

审计产出的是一份域名与违规项的清单。把它转化为服务器改动，可以分成三种情况。

能上 TLS 1.3 就上。 这样做能一次性解决好几类违规，而不是一条一条地修。TLS 1.3 的所有密码套件都提供完全前向保密，非 PFS 密码套件的警告根本不会出现。扩展主密钥的要求只针对 TLS 1.2，自然也就不再适用。签名算法的协商在设计上本就更严格。Apple 自己的整改栏写的就是：尽可能把服务器更新为协商 TLS 1.3，TLS 1.2 是底线。²

如果被锁死在 TLS 1.2 上，三项设置能解决绝大部分问题。 启用扩展主密钥扩展——这是最容易让一套看似现代的配置翻车的违规项。把密码套件列表限制为 ECDHE 密钥交换搭配 AES-128 或 AES-256，一举满足 PFS 要求和对称加密算法要求。³ 再把 rsa_pkcs15_sha1 签名算法从服务器的偏好顺序中移除。

被锁死的情况，比听上去要常见得多。终结 TLS 的负载均衡器、还在服务合同期内的硬件设备、嵌入式管理控制器——任何一个都可能是“看起来很现代的环境”却协商出老旧参数的原因。

证书类问题需要额外的提前量。 低于 2048 位的 RSA、低于 256 位的 ECDSA，以及用弱于 SHA-256 的算法做哈希的叶证书，都只能重新签发，改配置解决不了。这意味着要走 CA 申请、变更窗口，还要和证书链的负责人协调。中间证书也要一并检查，因为默认信任评估会沿整条链一直走到锚点。³

有一条豁免能省下工作量：如果未通过信任评估的证书属于自动注册描述文件中的锚点证书，Apple 明确表示无需整改。² 开工单之前，先确认这一点。

逐项验证修复结果，不要每次都重跑整轮审计。 nscurl 会用不同的 ATS 例外组合去连接单台服务器，从而准确定位仍然失败的是哪一项要求。³ 当您正等着供应商重新部署时，每迭代一次就跑一遍完整的 sysdiagnose 流程，实在太慢。

为什么提前量才是关键

Apple 直接写道，更新服务器配置“可能需要相当长的时间，尤其是由外部供应商维护的服务器”。²

正是这句话，决定了审计应当现在就做，而不是等 27 大规模推送之后。受影响的服务器往往并不归您管：MDM 供应商的端点、软件分发合作方、挡在注册流程前面的身份提供商。10 月才发现某家供应商要花一个季度才能给他们的 TLS 1.2 端点启用 EMS，和 8 月就发现，是完全不同的两个问题。

审计产出的是一份域名清单，以及访问过这些域名的进程。这份清单就是您要发给供应商的东西，而它的具体程度，决定了对方会不会优先处理。“你们的服务器不满足 Apple 的新要求”很容易被排到后面；“你们位于该域名的端点在协商 TLS 1.2 时未启用扩展主密钥，OS 27 会因此阻断注册流量”则不会。

这与本次发布中的其他变更如出一辙。macOS 27 不再提示，直接拒绝跨团队容器访问，而菜单项图像现在取决于您链接的是哪个 SDK。每一次都是平台移除了某个信号，或收紧了某个默认行为，而故障浮现出来时看上去像是别的问题。在这里，“别的问题”表现为一次卡住的设备注册。

要点回顾

面向 IT 管理员： - 在 26.4 到 26.x 上审计。在 27 上测试会在第一处失败就被阻断，同一工作流中后续的一切都被掩盖。 - 测试前先安装网络诊断日志描述文件并重启设备，否则日志无法指认出问题服务器。 - 覆盖配置而非设备：环境、设备类型、角色、注册类型，各自触达的服务器都不相同。 - 发给供应商的信息要包含域名、进程和具体的违规项。外部服务器上的提前量，才是真正的约束条件。

面向 MDM 与设备管理开发者： - SCEP 服务器和内容缓存服务器已获豁免，审计时不必在它们身上花时间。 - ATS FCPv2.1 违规与一般性 ATS 策略违规是两回事，其中最容易被漏掉的是未启用 EMS 的 TLS 1.2。 - watchOS 上 log 命令用不了，Apple Watch 的连接通过 iOS 测试来覆盖。

面向所有看到相关标题的人： - 变的不是您 App 自己的 URLSession 流量。这项变更针对的是处理管理、注册、安装和更新流量的系统进程。

常见问题

这会影响我的 App 发出的网络请求吗？

不会。该变更针对的是参与 MDM、DDM、自动化设备注册、配置描述文件安装、App 安装和软件更新的系统进程。¹ 而 App 的网络行为，自 iOS 9.0 与 macOS 10.11 SDK 起就一直由 App Transport Security 单独管辖。³

为什么要在更旧的系统版本上审计？

因为在 27 上，失败会直接阻断连接。Apple 写明，不合规的连接会被阻断，且“这些失败的连接可能导致工作流中后续的连接无法得到测试”，并建议在 26.4 或更高、但低于 27 的版本上测试，以识别出所有受影响的服务器。² 在这些版本上，违规只记为警告，连接仍能成功建立。

哪些服务器获得豁免？

安装配置描述文件或解析 DDM 资源时访问的 SCEP 服务器；以及内容缓存服务器，即便请求的是与 App 安装或软件更新相关的资源。²

我的服务器跑的是 TLS 1.2，证书也有效，还会失败吗？

会。FCP v2.1 的检查项包括：协商 TLS 1.2 时未启用扩展主密钥扩展、证书所用签名算法未在 ClientHello 中通告，以及 rsa_pkcs15_sha1 签名算法。² 此外，ATS 还要求使用 AES-128 或 AES-256，以及通过 ECDHE 实现的完全前向保密。³

在 App 中启用 NIAP 合规模式会改变这一点吗？

不会，而且这两件事很容易被混为一谈。NSRequiresNIAPTLSPackageVersion 只是让您 App 自身的客户端行为进入面向受监管环境的更严格 FCP 模式。³ OS 27 的系统进程则会独立地对管理流量执行它们自己的要求。

参考来源