RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops

RTSP-Authentifizierungsfehler gehören zu den häufigsten Supportfällen für IP-Kameras. Benutzer suchen nach „RTSP 401 Unauthorized“, „RTSP Digest-Authentifizierung fehlgeschlagen“, „Kamera funktioniert in VLC, aber nicht in NVR“, „RTSP Basic vs Digest“, „stale nonce“, „falscher Bereich“ und „IP-Kamera-Anmeldeschleife“, weil das Symptom einfach ist, die Ursache jedoch in den Anforderungs- und Antwortheadern verborgen ist.

RTSP Inspector wurde genau für diese Problemklasse entwickelt. Ein Spieler darf nur „Authentifizierung fehlgeschlagen“ sagen. Ein Protokollinspektor kann das erste nicht authentifizierte „DESCRIBE“, die „WWW-Authenticate“-Herausforderung, die „Authorization“-Antwort des Clients, den Nonce-Wert, den Bereich, den in der Digest-Berechnung verwendeten URI und ob die Kamera die zweite Anfrage ablehnt, anzeigen.

Warum die RTSP-Authentifizierung verwirrend ist

Viele Kameras akzeptieren keine Zugangsdaten auf die erste Anfrage. Der normale Digest-Ablauf ist:

1. Der Client sendet „DESCRIBE“ ohne Autorisierung.
2. Die Kamera gibt „401 Unauthorized“ zurück.
3. Die Kamera enthält „WWW-Authenticate: Digest ...“.
4. Der Client berechnet die Digest-Antwort neu.
5. Der Client sendet erneut „DESCRIBE“ mit „Authorization: Digest ...“.
6. Die Kamera akzeptiert entweder die Anfrage oder gibt eine weitere „401“ zurück.

Das erste „401“ ist nicht unbedingt ein Fehler. Der wiederholte „401“ nach dem Senden der Digest-Anmeldeinformationen durch den Client ist der wichtige Beweis.

Grundlegende vs. Digest-Kameraeinstellungen

Einige Kameras machen eine Einstellung sichtbar wie:

• Basisauthentifizierung
• Digest-Authentifizierung
• Basic und Digest
• Nur Digest
• Keine Authentifizierung

Wenn der Client nur Basic unterstützt, die Kamera jedoch Digest benötigt, schlägt der Stream fehl. Wenn der Client Digest sendet, die Kamera jedoch für eine herstellerspezifische Variante konfiguriert ist, schlägt der Stream möglicherweise ebenfalls fehl.

Suchbegriffe, die diesen Fall häufig beschreiben:

• „RTSP Basic-Authentifizierungskamera“
• „RTSP Digest Authentifizierungskamera“
• „VLC funktioniert, aber die App erhält 401“
• „Authentifizierung der NVR-Kamera fehlgeschlagen“
• „ONVIF funktioniert, aber die RTSP-Anmeldung schlägt fehl“

Die Lösung besteht darin, das Passwort nicht erneut zu erraten. Überprüfen Sie zunächst, welches Authentifizierungsschema die Kamera tatsächlich ankündigt.

Reichskonflikte

Der Digest-„Bereich“ ist Teil der Authentifizierungsberechnung. Wenn der Client die Antwort mit einem anderen Realm als dem von der Kamera bereitgestellten berechnet, schlägt die Authentifizierung fehl.

Dies kann passieren, wenn:

• Ein Proxy schreibt die Herausforderung neu.
• Die Firmware ändert den Kamerabereich nach dem Upgrade.
• Der Client speichert eine frühere Herausforderung zwischen.
• Mehrere Kameras teilen sich über einen Reverse-Proxy einen Hostnamen.
• Die App verwendet ein gespeichertes Profil eines anderen Kameramodells.

RTSP Inspector sollte den Bereich sichtbar machen, damit der Fehler konkret wird. Die Frage lautet nicht: „Ist das Passwort falsch?“ aber „welcher genaue Bereich und URI wurden verwendet, als die Digest-Antwort generiert wurde?“

Nonce- und veraltete Nonce-Probleme

Die Digest-Nonce ist ein vom Server bereitgestellter Wert. Bei einigen Kameras läuft es schnell ab. Einige Kameras verwenden es für eine Sitzung wieder. Einige Kameras lehnen alte Nonces nach einem Neustart, einem Firmware-Update, einer Zeitverschiebung oder zu vielen Fehlversuchen ab.

Nützliche Beweise:

• Enthält die Kamera „stale=true“?
• Versucht der Client es erneut mit einer neuen Nonce?
• Sendet die Kamera nach jedem „401“ eine andere Nonce?
• Funktioniert die Authentifizierung einmal und schlägt dann später fehl?
• Schlägt dieselbe URL fehl, nachdem die Kamera inaktiv war?

Wenn die Kamera eine neue Herausforderung zurückgibt, der Client jedoch weiterhin die alte Nonce sendet, liegt der Fehler am clientseitigen Caching. Wenn die Kamera wiederholt Aufforderungen ohne sinnvollen Fortschritt zurückgibt, liegt das Problem möglicherweise an der Kamera-Firmware, an der Sperrrichtlinie oder an einer Nichtübereinstimmung der Anmeldeinformationen.

URI-Konflikt innerhalb der Digest-Authentifizierung

Die Digest-Authentifizierung umfasst den angeforderten URI. Eine subtile Diskrepanz kann dazu führen, dass die Anmeldung unterbrochen wird:

• Der Client stellt eine Verbindung zu „rtsp://192.168.1.10/stream1“ her.
• Die Digest-Antwort wird für „/stream1“ berechnet.
• Die Kamera erwartet „rtsp://192.168.1.10:554/stream1“.
• Proxy leitet „/live/stream1“ weiter.
• Der Client versucht es erneut mit einer normalisierten URL.

Aus diesem Grund sind rohe Anforderungszeilen wichtig. Der „DESCRIBE“-URI, der „Authorization“-Header-URI und der endgültige Kamerapfad sollten verglichen werden.

Das Passwort ist nicht die einzige Ursache

Support-Teams setzen Passwörter oft zu früh zurück. Wiederholtes „401 Unauthorized“ kann auch bedeuten:

• Falsches Authentifizierungsschema.
• Digest-Realm-Konflikt.
• Abgestandene Nonce.
• URL-Pfad stimmt nicht überein.
• Das Kamerakonto verfügt über keine RTSP-Berechtigung.
• Nach fehlgeschlagenen Anmeldeversuchen wird das Konto gesperrt.
• Sonderzeichen im Benutzernamen oder Passwort sind nicht URL-kodiert.
• Der Client hat Anmeldeinformationen von der umgeleiteten oder erneut versuchten URL entfernt.
• Für die Kamera ist vor dem RTSP-Zugriff die Erstellung eines ONVIF-Benutzers erforderlich.

Der beste SEO-Artikel sollte dies klar zum Ausdruck bringen, da viele Suchanfragen mit der Annahme beginnen, dass das Passwort falsch ist.

Sonderzeichen in RTSP-URLs

RTSP-URLs enthalten häufig Inline-Anmeldeinformationen:

rtsp://user:password@camera.example.local:554/stream1

If the password contains @, :, /, ?, #, or %, the URL parser may split the string incorrectly. The protocol trace can show whether the client actually sent the intended username and whether the request path was damaged.

Better diagnostics separate:

• URL parsing.
• Authentication challenge.
• Digest calculation.
• Camera authorization decision.

What to capture

For a useful RTSP authentication report, collect:

• Full request method sequence: OPTIONS, DESCRIBE, SETUP, PLAY.
• First 401 Unauthorized response.
• WWW-Authenticate header.
• Authentication scheme.
• Realm.
• Nonce.
• Stale flag.
• Client Authorization header metadata.
• Request URI used for Digest.
• Second or third camera response.
• Timing between retries.

Do not publish passwords or full Digest response values in public support cases. For internal debugging, preserve enough header structure to prove the protocol path.

Diagnosis workflow

Use this process:

1. Confirm whether the first 401 is only a challenge.
2. Check whether the client retries with Authorization.
3. Compare Basic vs Digest.
4. Compare realm and nonce values.
5. Check whether stale=true appears.
6. Verify the URI used in the authorization header.
7. Check whether credentials contain reserved URL characters.
8. Confirm the account has RTSP permissions.
9. Test the same camera path after reboot or lockout window.
10. Save the trace for regression testing.

Final diagnosis

RTSP Digest authentication failures should be diagnosed from headers, not from player error text. The important evidence is the challenge, the retry, the nonce, the realm, the URI, and the final camera decision.

RTSP Inspector helps turn "RTSP 401 Unauthorized" into a specific finding: wrong scheme, stale nonce, realm mismatch, URL credential parsing, account permission, or camera lockout.