RTSPS 与 RTSP over TLS 调试——摄像头证书、握手失败、加密流的问题

RTSP 本身已经涉及多层问题：URL、认证、SDP、传输方式、RTP、RTCP、编解码器和网络路径。RTSPS 在这一切开始之前又多了一层——TLS。如果 TLS 握手失败，客户端根本走不到 OPTIONS、DESCRIBE、SETUP 或 PLAY。用户看到的只有"无法连接"、"TLS 握手失败"、"证书验证失败"、"安全 RTSP 不工作"，或者干脆就是黑屏。

像"RTSPS 摄像头无法连接"、"RTSP over TLS 证书错误"、"摄像头 TLS 握手失败"、"安全 RTSP 流无法播放"这类搜索词，通常来自已经试过普通 RTSP 的团队。他们现在需要确定：安全传输本身坏了？证书不被信任？摄像头只支持旧的 TLS 版本？还是 TLS 成功之后流才出问题？

RTSP Inspector 在这个排查流程中有用，是因为正确的问题不是"播放器能不能打开画面"，而是"安全连接完成了吗？RTSP 开始了吗？认证通过了吗？SDP 描述了媒体吗？RTP 到达了吗？"

RTSPS 不只是换了个 URL

普通 RTSP 通常是这样的 URL：

rtsp://camera.example.com:554/stream1

RTSPS 通常用：

rtsps://camera.example.com:322/stream1

或者厂商自定义的安全 RTSP 端口。在发送任何 RTSP 方法之前，客户端和摄像头会先完成一次 TLS 握手。这个握手协商了协议版本、密码套件、证书身份和安全会话密钥。

如果 TLS 层失败，就不会有任何 RTSP 状态码。你不会看到 401 Unauthorized、404 Not Found 或者 SDP。流在 RTSP 存在之前就已经失败了。

常见的 RTSPS 失败原因

RTSPS 失败通常属于以下几类：

• 摄像头实际上没有启用 RTSPS
• 安全 RTSP 端口写错了或被防火墙挡住了
• 摄像头证书是自签名的
• 证书的主机名和 URL 不一致
• 证书已过期
• 客户端要求现代 TLS 版本，但摄像头只支持旧版本
• 摄像头要求客户端证书
• 代理或防火墙错误地终结了 TLS 连接
• TLS 成功但 RTSP 认证失败
• RTSP 成功但 PLAY 之后的媒体传输失败

最后两条尤其重要。TLS 成功之后，普通的 RTSP 问题依然存在。一条安全的 RTSP 连接仍然可能因为 Digest 认证、错误的 SDP、RTP 被防火墙阻挡、H.265 支持问题、丢包或缺少 SPS/PPS 而失败。

证书名称不匹配

很多摄像头出厂自带的证书和你实际输入的地址不匹配。证书可能是签给设备主机名的，而你通过 IP 地址连接：

rtsps://192.168.1.50/stream1

如果证书的 subject 或 subject alternative name 里没有 192.168.1.50，严格的客户端会拒绝连接。有些播放器默认忽略这个错误，另一些则直接失败。这就是为什么 RTSPS 在一个工具里能工作，在另一个工具里却不行。

生产环境中，应该使用与客户端 DNS 名称匹配的证书。实验室诊断时，记录下失败是信任错误、主机名不匹配还是更底层的 TLS 握手失败。

自签名摄像头证书

IP 摄像头和 NVR 通常使用自签名证书。操作系统或应用程序默认不信任自签名证书。客户端可能报告：

• certificate verify failed
• unknown ca
• self signed certificate
• unable to get local issuer certificate

这不代表流 URL 是错的。它只代表客户端不信任证书链。

在可控环境中，可以把摄像头证书或私有 CA 导入信任存储。在产品工作流中，更好的做法是让信任行为明确可见，而不是静默关闭验证。

旧的 TLS 版本和密码套件

有些摄像头固件版本太旧，只支持过时的 TLS 版本或密码套件。一个现代客户端可能因为安全原因直接拒绝它们。结果看起来就像普通的连接重置或握手失败。

有用的排查问题：

• 摄像头提供了哪个 TLS 版本？
• 它支持哪些密码套件？
• 是客户端拒绝了摄像头，还是摄像头拒绝了客户端？
• 有没有中间设备（代理、负载均衡器）在处理 TLS？

通过手动 TLS 握手测试验证

在 RTSP Inspector 之前，先用命令行验证 TLS 握手。这能帮你区分是 TLS 的问题还是 RTSP 的问题：

# 检查 TLS 连接和证书
openssl s_client -connect camera.example.com:322 -servername camera.example.com

# 如果上面成功，手动发送 RTSP DESCRIBE
echo -e "DESCRIBE rtsp://camera.example.com/stream1 RTSP/1.0\r\nCSeq: 2\r\n\r\n" | openssl s_client -connect camera.example.com:322 -servername camera.example.com -quiet

如果 openssl s_client 也失败，说明是 TLS/网络层的根本问题。如果 openssl 成功但 RTSP 失败，问题在 RTSP 层。

关于端口和防火墙

普通 RTSP 的默认端口是 554。RTSPS 没有统一标准化的默认端口。常见做法包括：

• 322：某些安防厂商（如 Hikvision）使用 322 作为安全 RTSP 端口
• 554：有些摄像头在同一个 554 端口上同时侦听 RTSP 和 RTSPS，由 Client Hello 中的 SNI 区分
• 443：少数情况下，RTSPS 走标准 HTTPS 端口
• 自定义端口：可在摄像头管理页面中配置

排查时第一步：确认端口号是正确的。用 telnet camera-ip 322 或 nmap -sT -p 322 camera-ip 验证端口确实是开放的。

TLS 成功后的 RTSP 认证问题

TLS 成功不代表认证通过。摄像头仍然可能返回 401 Unauthorized。常见场景：

• Digest 认证参数（realm、nonce、qop）与客户端不兼容
• 摄像头的用户账户配置了 IP 地址白名单——当前客户端 IP 不在白名单中
• 多用户摄像头，当前账户没有流的访问权限

此时问题不在安全层，而在应用层。排查方式与普通 RTSP 401 相同。

媒体传输在安全会话中的问题

TLS 只保护控制通道（RTSP 命令）。RTP/RTCP 媒体流在 TLS 握手完成后通过独立的 UDP 或 TCP 连接传输，通常不经过 TLS 加密。这意味着：

• 即使 RTSPS 连接成功，RTP 仍然可能被防火墙阻止
• 丢包、抖动、时间戳漂移等问题不受 TLS 影响
• RTP 端口号由 SETUP 响应中的 Transport header 决定，和普通 RTSP 一样

排查媒体问题时应忽略"连接是加密的"这个事实——排查方法与普通 RTSP 完全一致。

总结：RTSPS 排查顺序

1. 端口是否可达？ → telnet 或 nmap
2. TLS 握手能否完成？ → openssl s_client
3. 证书是否受信任？ → 检查 Certificate 和 Alert 消息
4. RTSP 命令能否正常发送？ → DESCRIBE、SETUP、PLAY
5. 媒体流是否正常到达？ → RTP 序列号、时间戳、丢包率