401 是「不知道你是谁」，403 是「知道但不行」

一句话总结

缩小认证问题范围，成本最低的工具是两个状态码；缩小证书问题范围，成本最低的工具则是数清服务器实际发送了几张证书。

为什么需要这些知识

FDE 是经手别人家钥匙的人。而在各类故障报告中，认证问题属于最难复现的一类，因为它会因令牌、用户和时间段的不同而以不同方式失败。

不过，有一个区分可以把这种复杂度减半。

401 表示身份认证（authentication）失败。 “无法确认你是谁。”可能没有令牌、格式错误、令牌过期，或签名不匹配。

403 表示权限授权（authorization）失败。 “我知道你是谁，但不允许你做这件事。”身份确认已经通过，只是权限不足。

分清两者后，调查方向会截然相反。遇到 401，应检查凭据本身——令牌是否正确传递、是否已经过期。遇到 403，则无需改动凭据，而应检查权限配置和作用域。如果不做这个区分，只笼统地称为“权限错误”，就可能朝错误方向排查数小时。

还要注意一点：如果返回 401 时，响应中没有说明重新认证的路径，客户端就会陷入无限重试。 因为客户端不知道如何刷新令牌，只会不断发送同一个令牌。

即使同为 401，原因也各不相同。缺少令牌、无法识别的令牌和已过期的令牌都会返回 401，但应对方式并不一样。因此，还必须查看响应正文中的原因字符串。如果只根据状态码判断，就可能在本该回答“请重新签发令牌”的场景下，错误地回答“请检查配置”。

它是如何运作的

证书问题只有几种固定的失败模式，而且每种模式都有不同的证据。

过期——已经超过 notAfter。但这里还有一项必须同时确认：客户端的时钟。 没有时钟的嵌入式设备、长期停机后重新启动的虚拟机，以及时间与宿主机不一致的容器，常常会报告“证书已过期”，而此时服务器证书其实完全正常。要养成同时记录到期日和当前时间的习惯。

名称不匹配——访问时使用的名称不在证书中。这里常见的错误是查看 CN。现代客户端完全不看 CN，只检查 subjectAltName。 认为“CN 中填了域名就没问题”的判断，从 2017 年起就已经不再成立。

缺少中间证书——这是 FDE 最常遇到的类型，而且症状很特别：浏览器中的锁形图标正常，但服务器到服务器的调用却失败。 原因不在客户端，而在服务器。服务器没有一并发送中间证书；浏览器会沿着证书中的链接自行下载缺失的中间证书，替服务器弥补错误。curl 和大多数语言运行时则不会沿着这个链接下载。

因此，判断方法很简单：数一数服务器发送了几张证书。如果只收到一张终端证书，原因当场就能确定，而且需要修复的是服务器，不是客户端。

在实际工作中会是什么样

这时，FDE 很容易受到一条捷径的诱惑：关闭验证。

症状会立刻消失。但如果以这种状态部署到生产环境，系统就会直接暴露在中间人攻击之下。更糟的是，关闭验证进行开发，相当于在一个生产环境中并不存在的条件下工作，其他问题也会被一起掩盖。这些被遮住的问题最终会同时爆发。

只有在原因已经确定后，才可以临时关闭验证，用于确认“确实是这个问题导致的”；完成确认后必须立即恢复。

经手他人凭据的规则

“FDE 经手的是别人家的钥匙”这句话，分量远不止技术层面。在接收并使用客户的令牌和证书期间，有几条规则必须遵守。违反这些规则后，无论诊断做得多好，项目都会就此结束。

只索取所需的最小权限。 如果调查对象只是一个查询 API，读取令牌就足够了。“为了方便，请给我们管理员令牌”不应该由我们先说出口。即使客户主动提供，如果无法解释为什么需要如此高的权限，也最好退还。发生事故时，该令牌能够执行哪些操作，就会直接决定调查范围有多大。

设定有效期，结束后及时归还。 调查结束后，应请求废止凭据，并留下书面记录。项目结束半年后，仍然有效的令牌还留在笔记本电脑上，是最常见的事故路径之一。

预先规定存放位置。 正如前面的课程所讲，环境变量可能被同一主机上的其他进程读取，凭据也可能残留在 Shell 历史记录和命令行参数里。即使只是临时使用，也最好放进文件并收紧文件权限。而且，屏幕共享期间不要打开该文件。

从日志和报告中滤除凭据。 粘贴诊断过程时，经常会把认证标头一起带过去。粘贴前应养成通读检查一遍的习惯；如果脚本会在团队内共享，更稳妥的做法是从一开始就让它不打印这些值。

此外，关闭验证必须留下记录。 前面说过，这只能用于确认原因；这里再补充一条：如果关闭过验证，就在报告中写明为何关闭、何时恢复。留下记录可以减少相关代码被意外保留的可能性；更重要的是，客户日后发现这些痕迹时，我们有据可依，能够作出解释。

下一次实操要做什么

你将分别使用四种令牌，手动制造 401 和 403，取得令牌过期的原因字符串，再从过期证书和名称不匹配的证书中分别提取诊断所需的值，并编写诊断报告。