Meta 是否支持 webhook mTLS 客户端证书的 CRL/OCSP 检查?
结论
目前无法确认 Meta 是否正式支持 WhatsApp webhook mTLS 客户端证书的 CRL 或 OCSP 吊销检查,也无法确认其官方安全模型是否为“仅验证 Meta CA 证书链,并依赖短期证书”。
题述材料没有提供这两项政策的官方说明,公开资料核验也未找到明确的支持声明。因此,现阶段无法回答“支持”,但 CRL 下载失败也不足以说明“Meta 明确不支持吊销检查”。
接收端仍应验证证书链、有效期、客户端认证用途和预期客户端身份。如果安全要求包含吊销检查,还需向 Meta 确认适用的 CRL/OCSP 服务或替代机制。
为什么证书中的 CRL 地址不足以证明支持
题述地址为:
http://meta.publickeyinfra.com/crl/outbound_api
需要核实该地址是否返回有效的 CRL,以及这份 CRL 是否覆盖实际收到的客户端证书。
CRL Distribution Points 扩展给出的是所在证书的吊销信息获取位置。根 CA 证书中的地址,不能直接当作它签发的所有中间证书和叶证书共用的吊销端点。应逐张检查证书链,再根据 CRL 的签发者和适用范围判断。RFC 5280
浏览器无法显示下载内容,也不一定说明 CRL 无效。CRL 可以采用二进制 DER 编码或 PEM 编码。但如果返回的是 HTML 错误页、空响应或无法解析的数据,就不能用于吊销验证。
对于 OCSP,应检查证书的 Authority Information Access 扩展中是否包含 OCSP URI。缺少该 URI,只能说明证书没有通过这一字段公布响应器地址,无法据此判断 Meta 是否有其他查询机制。
如何排查当前证书和 CRL
1. 检查实际收到的证书链
从 webhook 接收端的 TLS 终止层导出客户端叶证书和中间证书。不要用访问 Meta 网站时取得的 HTTPS 服务端证书代替。
假设叶证书保存为 meta-client.pem:
# 查看签发者、有效期、用途和扩展
openssl x509 -in meta-client.pem -noout -text
# 单独输出证书中公布的 OCSP URI
openssl x509 -in meta-client.pem -noout -ocsp_uri
对每张中间证书也做同样的检查,重点查看:
Issuer与上一层 CA 是否对应。Not Before、Not After的实际时间范围。Extended Key Usage是否允许客户端认证。CRL Distribution Points和Authority Information Access。
-ocsp_uri 没有输出,不代表证书已通过吊销检查。OpenSSL x509 文档
2. 确认下载结果是否真的是 CRL
可用以下命令排查题述地址;该地址是否为可用服务,仍需确认:
curl --fail --show-error --location \
--connect-timeout 10 --max-time 30 \
--dump-header outbound-api.headers \
--output outbound-api.crl \
'http://meta.publickeyinfra.com/crl/outbound_api'
检查响应状态和响应体,再按实际编码尝试解析:
# DER 格式
openssl crl -inform DER -in outbound-api.crl \
-noout -issuer -lastupdate -nextupdate -text
# 如果实际为 PEM 格式,改用此命令
openssl crl -inform PEM -in outbound-api.crl \
-noout -issuer -lastupdate -nextupdate -text
解析成功只说明文件格式可识别。使用前,还必须验证 CRL 的签名、签发者、适用范围和更新时间。HTTP 200 或解析成功,都不足以证明这份 CRL 可以用于吊销验证。OpenSSL crl 文档
3. 将证书链验证与吊销检查分开确认
假设:
meta-ca.pem是从 Meta 官方渠道取得并核验的信任锚。meta-intermediates.pem包含所需的中间证书。meta-client.pem是实际收到的客户端叶证书。
可以先检查证书链和客户端认证用途:
openssl verify \
-CAfile meta-ca.pem \
-untrusted meta-intermediates.pem \
-purpose sslclient \
meta-client.pem
这条命令不执行 CRL 或 OCSP 检查,预期客户端身份也需要另行核对。即使输出 OK,也不能据此判断“证书未被吊销”。
OpenSSL 的 -crl_check 要求找到适用的有效 CRL,否则会报错。在取得有效 CRL 之前强制开启这项检查,可能导致合法的 webhook 请求被拒绝。OpenSSL 验证选项文档
能否依赖短期证书
短期证书可以缩短私钥泄露后被利用的时间,但证书到期前仍可能遭到滥用。频繁轮换证书也不意味着旧证书会立即失效。
Meta 公开介绍过面向其边缘 HTTPS 基础设施的短期证书方案,但这不能证明 WhatsApp 出站 webhook mTLS 客户端证书采用了同一策略。Meta Engineering:短期证书方案
要确认 webhook 的安全模型,需要向 Meta 问清以下问题:
- 客户端叶证书和中间 CA 分别是否提供 CRL 或 OCSP,正式地址是什么?
- 吊销信息多久更新一次?服务故障时,接收端应如何处理?
- 如果不提供吊销服务,客户端证书的最长有效期是多少?密钥泄露后有什么应急机制?
在得到答复前,不应将“未获取到吊销状态”记录为“未吊销”。如果查询失败后仍继续接收请求,应明确这是接收方作出的风险选择。如果业务要求强制执行吊销检查,就需要取得 Meta 的支持说明或完成内部例外审批,证书链验证成功不能替代吊销检查。
备注:内容仅供参考。
