Depuração de RTSPS e RTSP sobre TLS: certificados de câmera, falhas de handshake e erros de fluxo seguro

A solução de problemas de RTSP já está em camadas: "URL, autenticação, SDP, transporte, RTP, RTCP, codec e caminho de rede são importantes. O RTSPS adiciona outra camada antes mesmo que a conversa RTSP possa começar. Se o handshake TLS falhar, o cliente nunca alcançará OPTIONS, DESCRIBE, SETUP ou PLAY. O usuário vê "não é possível conectar", "falha no handshake TLS", "falha na verificação do certificado", "RTSP seguro não funciona" ou simplesmente uma tela preta." Pesquisas como "câmera RTSPS não funciona", "erro de certificado RTSP sobre TLS", "falha no handshake TLS da câmera" e "falha no fluxo RTSP seguro" geralmente vêm de equipes que já tentaram o RTSP normal e agora precisam saber se o transporte seguro está quebrado, o certificado não é confiável, a câmera suporta apenas versões TLS antigas ou o fluxo falha após o sucesso do TLS.

O RTSP Inspector é útil neste fluxo de trabalho porque a pergunta correta não é "o player abre o vídeo?" A pergunta correta é "a conexão segura foi concluída, o RTSP começou, a autenticação foi concluída, o SDP descreveu a mídia e o RTP chegou?"

RTSPS não é apenas RTSP com URL diferente

O RTSP simples geralmente usa um URL como:

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

RTSPS commonly uses:

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

ou uma porta RTSP segura específica do fornecedor. Antes de qualquer método RTSP ser enviado, o cliente e a câmera realizam um handshake TLS. Esse handshake negocia a versão do protocolo, o conjunto de criptografia, a identidade do certificado e as chaves de sessão seguras.

Se a camada TLS falhar, não haverá código de status RTSP. Você não verá 401 Unauthorized, 404 Not Found ou SDP. O fluxo falha antes que o RTSP exista.

Causas comuns de falha de RTSPS

As falhas de RTSPS geralmente se enquadram nestes grupos:

• Na verdade, a câmera não habilita RTSPS.
• A porta RTSP segura está errada ou bloqueada.
• O certificado da câmera é autoassinado.
• O nome do host do certificado não corresponde ao URL.
• O certificado expirou.
• O cliente requer TLS moderno, mas a câmera suporta apenas TLS antigo.
• A câmera requer um certificado de cliente.
• Um proxy ou firewall encerra o TLS incorretamente.
• O TLS é bem-sucedido, mas a autenticação RTSP falha posteriormente.
• O RTSP é bem-sucedido, mas o transporte de mídia falha após PLAY.

Os dois últimos são importantes. Depois que o TLS for bem-sucedido, os problemas usuais de RTSP ainda existirão. Uma conexão RTSP segura ainda pode falhar devido à autenticação Digest, SDP incorreto, RTP bloqueado, suporte H.265, perda de pacotes ou SPS/PPS ausente.

Incompatibilidade de nome de certificado

Muitas câmeras são fornecidas com certificados que não correspondem ao endereço digitado pelos usuários. O certificado pode ser emitido para um nome de host de dispositivo, enquanto o usuário se conecta por endereço IP:

rtsps://192.168.1.50/stream1

If the certificate subject or subject alternative name does not include 192.168.1.50, a strict client may reject it. Some players ignore this error by default; others fail hard. That is why RTSPS may work in one tool and fail in another.

For production deployments, use a certificate whose name matches the DNS name clients use. For lab diagnostics, record whether the failure is a trust error, a hostname mismatch, or a lower-level TLS handshake failure.

Self-signed camera certificates

IP cameras and NVRs often use self-signed certificates. A self-signed certificate is not automatically trusted by the operating system or application. The client may report:

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

This does not prove that the stream URL is wrong. It proves that the client does not trust the certificate chain.

In a controlled environment, you can import the camera certificate or private CA into the trust store. In a product workflow, the safer answer is to make trust behavior explicit and visible instead of silently disabling verification.

Old TLS versions and cipher suites

Some cameras have old firmware and support only outdated TLS versions or cipher suites. A modern client may reject them for security reasons. The result may look like a generic connection reset or handshake failure.

Useful questions:

• Which TLS version did the camera offer?
• Did the client reject the cipher suite?
• Did the camera close the connection immediately?
• Does the same camera work with plain RTSP?
• Did a firmware update change TLS behavior?

If plain RTSP works and RTSPS fails before RTSP methods appear, focus on TLS compatibility before debugging SDP or RTP.

RTSPS authentication still matters

TLS encrypts the connection, but it does not replace RTSP authentication. After TLS succeeds, the camera may still return:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

Isso significa que a conexão segura está correta, mas a camada de login RTSP ainda precisa de credenciais. Os usuários costumam confundir a autenticação de certificado com a autenticação de conta de câmera. Eles estão separados.

A sequência correta é:

1. A conexão TCP é aberta.
2. O handshake TLS foi bem-sucedido.
3. A solicitação RTSP é enviada dentro do TLS.
4. Desafios de câmera com autenticação RTSP, se necessário.
5. O cliente envia autorização RTSP.
6. A câmera retorna SDP.
7. O cliente configura trilhas de mídia.
8. Chegam pacotes de mídia.

Transporte de mídia após RTSPS

O RTSPS protege o controle RTSP, mas os detalhes do transporte de mídia variam de acordo com a câmera e o cliente. Algumas implantações usam RTP intercalado na conexão RTSP protegida por TLS. Outros negociam o transporte de mídia separadamente. O comportamento do firewall e do NAT ainda pode ser importante.

Se DESCRIBE, SETUP e PLAY forem bem-sucedidos, mas nenhum vídeo aparecer, não continue buscando certificados. Inspecione a entrega de mídia:

• Os pacotes RTP estão intercalados na conexão RTSP?
• A câmera negociou portas UDP?
• Os números de sequência RTP estão aumentando?
• O SDP declara H.264 ou H.265?
• Os registros de configuração do codec estão presentes?
• O RTCP mostra perda ou jitter?

O sucesso do TLS é apenas um ponto de verificação.

Lista de verificação de depuração para RTSPS

Utilize esta ordem:

1. Confirme se a câmera suporta RTSPS e identifique a porta RTSP segura.
2. Verifique se a conexão TCP com essa porta foi bem-sucedida.
3. Determine se a falha ocorre antes ou depois do handshake TLS.
4. Inspecione a confiança, a expiração e a correspondência do nome do host do certificado.
5. Verifique a versão do TLS e a compatibilidade da criptografia.
6. Confirme se os certificados do cliente são necessários.
7. Assim que o TLS funcionar, inspecione RTSP OPTIONS, DESCRIBE, SETUP e PLAY.
8. Inspecione a autenticação RTSP separadamente do TLS.
9. Inspecione o SDP em busca de codecs e faixas.
10. Inspecione RTP e RTCP após o início da reprodução.

Diagnóstico final

As falhas de RTSPS devem ser divididas em falhas de TLS e falhas de RTSP. Se o handshake falhar, depure certificados, confiança, nome do host, versão TLS, conjunto de criptografia e porta segura. Se o handshake for bem-sucedido, depure o RTSP exatamente como faria para um fluxo normal: autenticação, SDP, transporte, RTP, RTCP e evidência de codec.

O RTSP Inspector se adapta a esse fluxo de trabalho porque mantém o diagnóstico em camadas. O streaming seguro da câmera não é apenas “player abre vídeo” ou “player falha”. É uma cadeia de etapas de protocolo observáveis ​​e a correção depende do primeiro link quebrado.