RTSPS und RTSP über TLS-Debugging: Kamerazertifikate, Handshake-Fehler und Secure Stream-Fehler

Die RTSP-Fehlerbehebung ist bereits vielschichtig: "URL, Authentifizierung, SDP, Transport, RTP, RTCP, Codec und Netzwerkpfad sind alle wichtig. RTSPS fügt eine weitere Ebene hinzu, bevor die RTSP-Konversation überhaupt beginnen kann. Wenn der TLS-Handshake fehlschlägt, erreicht der Client nie „OPTIONS“, „DESCRIBE“, „SETUP“ oder „PLAY“. Der Benutzer sieht „Verbindung nicht möglich“, „TLS-Handshake fehlgeschlagen“, „Zertifikatüberprüfung fehlgeschlagen“, „sicheres RTSP funktioniert nicht“ oder einfach einen schwarzen Bildschirm." Suchanfragen wie „RTSPs-Kamera funktioniert nicht“, „RTSP-über-TLS-Zertifikatfehler“, „Kamera-TLS-Handshake fehlgeschlagen“ und „Sicherer RTSP-Stream schlägt fehl“ stammen normalerweise von Teams, die bereits normales RTSP ausprobiert haben und nun wissen müssen, ob der sichere Transport unterbrochen ist, das Zertifikat nicht vertrauenswürdig ist, die Kamera nur alte TLS-Versionen unterstützt oder der Stream nach erfolgreichem TLS fehlschlägt.

RTSP Inspector ist in diesem Workflow nützlich, da die richtige Frage nicht lautet: „Öffnet der Player das Video?“ Die richtige Frage lautet: „Wurde die sichere Verbindung hergestellt, hat RTSP begonnen, wurde die Authentifizierung abgeschlossen, hat SDP Medien beschrieben und ist RTP angekommen?“

RTSPS ist nicht einfach RTSP mit einer anderen URL

Einfaches RTSP verwendet oft eine URL wie:

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

RTSPS commonly uses:

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

oder ein herstellerspezifischer sicherer RTSP-Port. Bevor eine RTSP-Methode gesendet wird, führen Client und Kamera einen TLS-Handshake durch. Dieser Handshake handelt die Protokollversion, die Verschlüsselungssuite, die Zertifikatsidentität und sichere Sitzungsschlüssel aus.

Wenn die TLS-Schicht ausfällt, gibt es keinen RTSP-Statuscode. „401 Unauthorized“, „404 Not Found“ oder SDP wird nicht angezeigt. Der Stream schlägt fehl, bevor RTSP existiert.

Häufige Ursachen für RTSPS-Fehler

RTSPS-Fehler fallen normalerweise in diese Gruppen:

• Die Kamera aktiviert RTSPS eigentlich nicht.
• Der sichere RTSP-Port ist falsch oder blockiert.
• Das Kamerazertifikat ist selbstsigniert.
• Der Hostname des Zertifikats stimmt nicht mit der URL überein.
• Das Zertifikat ist abgelaufen.
• Der Client benötigt modernes TLS, aber die Kamera unterstützt nur altes TLS.
• Die Kamera erfordert ein Client-Zertifikat.
• Ein Proxy oder eine Firewall beendet TLS falsch.
• TLS ist erfolgreich, aber die RTSP-Authentifizierung schlägt danach fehl.
• RTSP ist erfolgreich, aber der Medientransport schlägt nach „PLAY“ fehl.

Die letzten beiden sind wichtig. Sobald TLS erfolgreich ist, bestehen weiterhin die üblichen RTSP-Probleme. Eine sichere RTSP-Verbindung kann immer noch aufgrund von Digest-Authentifizierung, fehlerhaftem SDP, blockiertem RTP, H.265-Unterstützung, Paketverlust oder fehlendem SPS/PPS fehlschlagen.

Nicht übereinstimmender Zertifikatsname

Viele Kameras werden mit Zertifikaten ausgeliefert, die nicht mit der vom Benutzer tatsächlich eingegebenen Adresse übereinstimmen. Das Zertifikat kann für den Hostnamen eines Geräts ausgestellt werden, während der Benutzer eine Verbindung über die IP-Adresse herstellt:

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="..."

Das bedeutet, dass die sichere Verbindung in Ordnung ist, die RTSP-Anmeldeschicht jedoch weiterhin Anmeldeinformationen benötigt. Benutzer verwechseln die Zertifikatauthentifizierung häufig mit der Authentifizierung des Kamerakontos. Sie sind getrennt.

Die richtige Reihenfolge ist:

1. Die TCP-Verbindung wird geöffnet.
2. Der TLS-Handshake ist erfolgreich.
3. Die RTSP-Anfrage wird innerhalb von TLS gesendet.
4. Kamera-Challenges mit RTSP-Authentifizierung, falls erforderlich.
5. Der Client sendet eine RTSP-Autorisierung.
6. Die Kamera gibt SDP zurück.
7. Der Kunde richtet Medienspuren ein.
8. Medienpakete kommen an.

Medientransport nach RTSPS

RTSPS schützt die RTSP-Steuerung, die Details zum Medientransport variieren jedoch je nach Kamera und Client. Einige Bereitstellungen verwenden interleaved RTP über die TLS-geschützte RTSP-Verbindung. Andere verhandeln den Medientransport separat. Firewall- und NAT-Verhalten können immer noch von Bedeutung sein.

Wenn „DESCRIBE“, „SETUP“ und „PLAY“ erfolgreich sind, aber kein Video erscheint, jagen Sie nicht weiter nach Zertifikaten. Medienlieferung prüfen:

• Sind RTP-Pakete auf der RTSP-Verbindung verschachtelt?
• Hat die Kamera UDP-Ports ausgehandelt?
• Steigen die RTP-Sequenzzahlen?
• Deklariert SDP H.264 oder H.265?
• Sind Codec-Konfigurationsdatensätze vorhanden?
• Zeigt RTCP Verlust oder Jitter?

Der TLS-Erfolg ist nur ein Prüfpunkt.

Debug-Checkliste für RTSPS

Verwenden Sie diese Reihenfolge:

1. Bestätigen Sie, dass die Kamera RTSPS unterstützt, und identifizieren Sie den sicheren RTSP-Port.
2. Stellen Sie sicher, dass die TCP-Verbindung zu diesem Port erfolgreich ist.
3. Bestimmen Sie, ob der Fehler vor oder nach dem TLS-Handshake auftritt.
4. Überprüfen Sie die Vertrauenswürdigkeit, den Ablauf und die Hostnamenübereinstimmung des Zertifikats.
5. Überprüfen Sie die TLS-Version und die Verschlüsselungskompatibilität.
6. Bestätigen Sie, ob Clientzertifikate erforderlich sind.
7. Sobald TLS funktioniert, überprüfen Sie RTSP „OPTIONS“, „DESCRIBE“, „SETUP“ und „PLAY“.
8. Überprüfen Sie die RTSP-Authentifizierung getrennt von TLS.
9. Überprüfen Sie SDP auf Codecs und Tracks.
10. Überprüfen Sie RTP und RTCP nach Beginn der Wiedergabe.

Endgültige Diagnose

RTSPS-Fehler müssen in TLS-Fehler und RTSP-Fehler unterteilt werden. Wenn der Handshake fehlschlägt, debuggen Sie Zertifikate, Vertrauen, Hostnamen, TLS-Version, Cipher Suite und sicheren Port. Wenn der Handshake erfolgreich ist, debuggen Sie RTSP genau so, wie Sie es für einen normalen Stream tun würden: Authentifizierung, SDP, Transport, RTP, RTCP und Codec-Nachweis.

RTSP Inspector eignet sich für diesen Arbeitsablauf, da die Diagnose auf mehreren Ebenen erfolgt. Beim sicheren Kamera-Streaming geht es nicht nur um „Player öffnet Video“ oder „Player schlägt fehl“. Es handelt sich um eine Kette beobachtbarer Protokollschritte, und die Lösung hängt vom ersten defekten Link ab.