Hot Desking funktioniert nicht – und die 3CX zeigt keinen Fehler

Es gibt Störungen, die machen sich mit einem klaren Fehlerbild bemerkbar: Dienst down, rote Ampel im Monitoring, aussagekräftige Logzeile. Und dann gibt es die anderen. Die, bei denen sich alle Systeme scheinbar korrekt verhalten – und trotzdem funktioniert für die Benutzer nichts. Genau so ein Fall ist mir an einem Unternehmensstandort mit Yealink SIP-T53W Telefonen hinter einem 3CX Session Border Controller (SBC) begegnet.

Das Symptom: Die Hot-Desking-Funktion – also das flexible An- und Abmelden von Benutzern an beliebigen Telefonen – funktionierte von einem Tag auf den anderen nicht mehr. Benutzer gaben Durchwahl und PIN ein, das Telefon schien den Login kurz anzunehmen, und wenige Sekunden später waren sie wieder abgemeldet. In der 3CX-Verwaltungskonsole: kein einziger sichtbarer Fehler.

Erst ein Wireshark-Trace direkt am Telefon brachte die Ursache ans Licht: ein TLS Fatal Alert mit der Description „Unknown CA”. In diesem Artikel zeige ich dir Schritt für Schritt, wie sich dieser Fall analysieren ließ, warum die 3CX-Konsole hier systembedingt schweigt – und wie du das Problem dauerhaft löst.

Das Fehlerbild: Login, Timeout, Logout – im 6-Sekunden-Takt

Aus Benutzersicht sah der Ablauf immer gleich aus: Am Yealink-Telefon wird die Hot-Desking-Anmeldung gestartet, Durchwahl und PIN werden eingegeben. Das Display quittiert die Eingabe, für einen kurzen Moment sieht alles nach einem erfolgreichen Login aus. Dann eine Pause von etwa 6 bis 8 Sekunden – und das Telefon fällt zurück in den abgemeldeten Zustand. Kein Fehlertext, keine Meldung, einfach wieder der Anmeldebildschirm.

Wer den Fehler reproduzierte, konnte die Uhr danach stellen. Und genau diese Regelmäßigkeit war der erste wichtige Hinweis: Ein zufälliges Netzwerkproblem – etwa Paketverluste oder ein instabiler Uplink – produziert selten ein derart deterministisches Muster. Ein fester Zeitabstand riecht fast immer nach einem Timeout-Mechanismus in einer der beteiligten Applikationen.

Wie Hot Desking bei 3CX technisch funktioniert

Um zu verstehen, warum der Login scheitert, muss man wissen, was beim Hot Desking unter der Haube passiert. Der Ablauf besteht aus drei Schritten:

• SIP NOTIFY: Nach der PIN-Eingabe prüft die 3CX-Anlage die Anmeldedaten und sendet ein SIP-NOTIFY an das Telefon. Diese Nachricht ist im Kern die Aufforderung: „Hol dir eine neue Konfiguration ab.”
• HTTPS-Download der Provisionierung: Das Telefon baut daraufhin eine HTTPS-Verbindung zum Provisionierungsdienst der 3CX auf und lädt die benutzerspezifische Konfigurationsdatei herunter – mit der Nebenstelle, den Anmeldedaten für die SIP-Registrierung und allen Benutzereinstellungen.
• SIP REGISTER: Mit der neuen Konfiguration registriert sich das Telefon als der angemeldete Benutzer an der Anlage. Erst jetzt ist der Login abgeschlossen.

Und hier steckt auch der Timeout: Die 3CX behandelt den Login zunächst als vorläufig. Trifft nach dem NOTIFY innerhalb von rund 8 Sekunden kein neues SIP REGISTER des Benutzers ein, geht die Anlage davon aus, dass die Anmeldung gescheitert ist, und macht einen Rollback – der Benutzer wird wieder abgemeldet. Genau das erklärt das beobachtete 6-bis-8-Sekunden-Muster: Schritt 1 funktionierte, Schritt 2 scheiterte still, Schritt 3 fand nie statt.

Was die 3CX-Konsole zeigt – und was sie verschweigt

Der naheliegende erste Blick geht natürlich in die 3CX-Verwaltungskonsole. In den Aktivitätsprotokollen fand sich zu jedem Login-Versuch ein sauberes Muster: ein Login-Event für den Benutzer, wenige Sekunden später ein Logout-Event. Das war’s. Kein TLS-Fehler, kein HTTP-Statuscode, kein Hinweis auf eine abgebrochene Provisionierung.

Das ist keine Schwäche speziell der 3CX, sondern ein strukturelles Problem vieler Applikationslogs: Die Konsole protokolliert Ereignisse aus Sicht der Anlage. Aus dieser Perspektive ist der Ablauf völlig konsistent – Benutzer meldet sich an, Benutzer sendet kein REGISTER, Benutzer wird abgemeldet. Dass der eigentliche Fehler in einer fehlgeschlagenen TLS-Verhandlung zwischen Telefon und Webserver lag, taucht in dieser Ereigniskette schlicht nicht auf, weil der abgelehnte Verbindungsversuch aus Applikationssicht nie eine „richtige” Verbindung war.

Anders formuliert: Die Konsole zeigt den Effekt, nicht die Ursache. Sie dokumentiert, dass der Login zurückgerollt wurde – aber nicht, warum das Telefon nie sein REGISTER geschickt hat. Wer an dieser Stelle aufhört zu suchen, landet schnell bei Verdächtigungen ins Blaue: Firmware? Netzwerk? Firewall? Ein klassischer Ausgangspunkt für Fingerpointing zwischen Teams.

Der Wireshark-Trace deckt den echten Fehler auf

Wenn die Applikation schweigt, hilft nur noch der Blick auf die Leitung. Für den Mitschnitt habe ich den Traffic direkt am SBC-Interface aufgezeichnet – in diesem Fall lief der 3CX SBC auf einem Raspberry Pi, sodass sich der Capture unmittelbar an der Stelle ansetzen ließ, an der Telefon und Anlage miteinander sprechen. Alternativ funktioniert ein Mirror-Port am Switch vor dem Telefon genauso gut. Wichtig ist nur: Der Trace muss während eines Login-Versuchs laufen, damit der komplette Ablauf im Mitschnitt landet.

Im Wireshark-Trace war der Ablauf dann glasklar zu sehen:

• Die 3CX sendet das erwartete SIP NOTIFY an das Yealink-Telefon – Schritt 1 funktioniert.
• Das Telefon baut brav eine TCP-Verbindung auf Port 5001 auf, dem HTTPS-Provisionierungsport der 3CX. Der Three-Way-Handshake läuft sauber durch – am Transport liegt es also nicht.
• Das Telefon sendet ein TLS Client Hello, der Server antwortet mit Server Hello und seinem Zertifikat.
• Und dann, statt der erwarteten Fortsetzung des Handshakes: ein Fatal Alert vom Telefon – Alert Level: Fatal, Alert Description: Unknown CA. Direkt danach reißt das Telefon die Verbindung ab.

Wer solche Pakete gezielt suchen will, filtert in Wireshark einfach auf TLS-Alerts:

tls.alert_message.level == 2

Der Alert-Level 2 steht dabei für Fatal – also Fehler, nach denen die TLS-Verbindung sofort beendet wird. Die Description „Unknown CA” (Code 48) bedeutet konkret: Der Client – hier das Yealink-Telefon – konnte das vom Server präsentierte Zertifikat keiner ihm bekannten Zertifizierungsstelle (CA) zuordnen. Aus Sicht des Telefons ist das ein potenzieller Man-in-the-Middle-Angriff, und die einzig richtige Reaktion darauf ist ein harter Abbruch.

Damit war die Kausalkette komplett: TLS-Handshake scheitert → HTTPS-Download der Benutzerkonfiguration findet nie statt → Telefon sendet kein neues SIP REGISTER → 3CX läuft in den 8-Sekunden-Timeout → Rollback des Logins. Jedes einzelne Symptom, inklusive des merkwürdig regelmäßigen Timings, war jetzt erklärbar – mit einem einzigen Paketmitschnitt. Wie sich solche abgebrochenen Verbindungen generell systematisch untersuchen lassen, habe ich in meinem Artikel über das Analysieren von Verbindungsabbrüchen ausführlicher beschrieben.

Warum vertraut das Telefon dem Zertifikat nicht?

Jetzt wird es spannend – denn auf den ersten Blick ergibt der Fehler keinen Sinn. Die 3CX-Anlage nutzte ein Let’s Encrypt-Zertifikat, und Let’s Encrypt gehört zu den bekanntesten CAs überhaupt. Warum sollte ein aktuelles Yealink-Telefon dieser CA nicht vertrauen? Und vor allem: Warum hat es vorher monatelang funktioniert?

Die Rolle der Intermediate-Zertifikate

Um das zu verstehen, muss man sich die Zertifikatskette (Chain) von Let’s Encrypt ansehen. Let’s Encrypt signiert Serverzertifikate nicht direkt mit seinem Root-Zertifikat ISRG Root X1, sondern über Intermediate-CAs – aktuell die RSA-Intermediates R10 und R11 sowie die ECDSA-Intermediates E5 und E6. Die Vertrauenskette sieht also so aus:

• ISRG Root X1 (im Trust Store des Clients hinterlegt)
• → Intermediate (z. B. R10)
• → Serverzertifikat der 3CX-Anlage

Damit ein Client diese Kette prüfen kann, muss der Server neben seinem eigenen Zertifikat auch das Intermediate-Zertifikat mit ausliefern – die sogenannte Fullchain. Das Root-Zertifikat bringt der Client selbst mit, das Bindeglied dazwischen aber typischerweise nicht.

Was in der 3CX schiefgelaufen war

Genau an diesem Punkt lag das Problem: Nach einer fehlgeschlagenen automatischen Zertifikatserneuerung lieferte der Webserver der 3CX nur noch das End-Entity-Zertifikat ohne das Intermediate aus. Für das Telefon war die Kette damit nicht mehr aufbaubar – das präsentierte Zertifikat verwies auf einen Aussteller, den das Telefon nicht kannte und nicht nachladen konnte. Ergebnis: Unknown CA.

Und hier kommt ein Detail ins Spiel, das viele aus dem Browser-Alltag nicht auf dem Schirm haben: Browser kompensieren fehlende Intermediates. Chrome, Firefox und Co. können über AIA-Fetching (Authority Information Access) fehlende Zwischenzertifikate selbstständig aus dem Internet nachladen oder greifen auf einen Cache bereits gesehener Intermediates zurück. Deshalb fällt eine unvollständige Chain im Browser oft gar nicht auf – die Seite lädt trotzdem mit grünem Schloss.

Die Embedded-Crypto-Engines in VoIP-Telefonen können das nicht. Ein Yealink-Telefon validiert stur gegen das, was der Server in der Handshake-Nachricht liefert, plus seinen lokalen Trust Store. Fehlt das Intermediate in der ausgelieferten Chain, ist die Validierung gescheitert – Punkt. Kein Nachladen, keine zweite Chance, keine Fehlertoleranz. Was im Browser ein unsichtbarer Schönheitsfehler ist, wird auf dem Telefon zum harten Totalausfall.

Warum trifft es auch bereits verbundene Telefone?

Bleibt die Frage nach dem „Warum jetzt?”. Die Antwort liegt in der 90-Tage-Gültigkeit der Let’s Encrypt-Zertifikate. Die 3CX erneuert das Zertifikat automatisch – und wenn bei dieser Erneuerung die Chain unvollständig neu geschrieben wird, sind plötzlich auch Telefone betroffen, die vorher monatelang problemlos liefen. Die Geräte selbst haben sich nicht verändert, keine Firmware, keine Konfiguration. Nur das, was der Server im TLS-Handshake ausliefert, ist ein anderes. Solche „es hat sich doch nichts geändert”-Fälle gehören zu den tückischsten überhaupt, weil die Fehlersuche instinktiv an der falschen Stelle beginnt.

Die Lösung – Zertifikat in der 3CX erneuern

Die gute Nachricht: Ist die Ursache erst einmal klar, ist die Behebung überschaubar. Ziel ist es, die 3CX dazu zu bringen, ihr Zertifikat komplett neu zu beziehen und die vollständige Fullchain inklusive Intermediate sauber im Webserver zu hinterlegen. Der Weg dorthin führt über einen dokumentierten, aber wenig bekannten Mechanismus:

Schritt 1: Erneuerung in der Konsole anstoßen. In der 3CX-Verwaltungskonsole unter Admin → Erweitert → Parameter den Parameter TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED suchen und dessen Wert auf 1 setzen. Dieser Parameter signalisiert der Anlage beim nächsten Lauf des Konfigurationswerkzeugs, dass das Zertifikat neu erzeugt bzw. neu bezogen werden muss.

Schritt 2: Zertifikatserneuerung per Kommandozeile ausführen. Auf einer Linux-basierten 3CX per SSH verbinden und das PbxConfigTool mit dem Renew-Flag starten:

sudo -u phonesystem /usr/lib/3cxpbx/PbxConfigTool -renew-certificates

Auf einer Windows-Installation liegt das Werkzeug im 3CX-Programmverzeichnis und wird analog mit dem Parameter aufgerufen:

“C:\Program Files\3CX Phone System\Bin\3CXPhoneSystemConfigTool.exe” -renew-certificates

Das Tool fordert dabei ein frisches Zertifikat an und schreibt die vollständige Kette – Serverzertifikat plus Let’s Encrypt Intermediate – neu in die Webserver-Konfiguration.

Schritt 3: nginx neu starten. Damit der Webserver die neue Zertifikatsdatei auch tatsächlich ausliefert, muss er einmal durchgestartet werden:

sudo service nginx restart

Schritt 4: Funktion prüfen. Anschließend einen Hot-Desking-Login am Telefon testen. Im Erfolgsfall läuft der TLS-Handshake jetzt sauber durch, der Konfigurationsdownload funktioniert, das Telefon sendet sein SIP REGISTER – und der Login bleibt bestehen. Wer es genau wissen will, lässt den Wireshark-Trace parallel mitlaufen: Statt des Fatal Alerts sieht man nun den vollständigen Handshake mit anschließender verschlüsselter Datenübertragung. In meinem Fall war das Problem damit an allen betroffenen Telefonen des Standorts sofort behoben – ohne ein einziges Gerät anzufassen.

Was dieser Fall lehrt – und warum die Konsole allein nicht reicht

Für mich steht dieser Fall exemplarisch für eine ganze Klasse von Störungen: Die Benutzer beschweren sich massiv, und die IT sieht in allen Konsolen nur grüne Ampeln. Das ist die perfekte Ausgangslage für Fingerpointing – der VoIP-Verantwortliche verweist aufs Netzwerk, das Netzwerkteam zeigt einen unauffälligen Switch-Port vor, und der Hersteller-Support fragt als Erstes nach der Firmware-Version. Jeder hat aus seiner Sicht recht. Und keiner findet den Fehler.

Der Grund ist einfach: Der Fehler lag auf einer Schicht, die keine der beteiligten Sichten abdeckt. Die TLS-Verhandlung zwischen Telefon und Provisionierungsdienst – Layer 5/6, wenn man im OSI-Modell denkt – taucht weder im Applikationslog der 3CX noch in den Interface-Countern des Switches auf. Ein abgelehnter Handshake ist für die Anlage keine Verbindung und für das Netzwerk nur eine Handvoll unauffälliger Pakete. Sichtbar wird er ausschließlich im Paketmitschnitt.

Die folgende Gegenüberstellung bringt es auf den Punkt:

Drei Dinge nehme ich aus solchen Fällen immer wieder mit:

• Applikationslogs zeigen die Welt aus Sicht der Applikation. Was die Applikation nicht als Fehler wahrnimmt, protokolliert sie auch nicht. Der Paketmitschnitt dagegen zeigt, was tatsächlich über die Leitung geht – ungefiltert und ohne Interpretation.
• Zeitmuster sind Gold wert. Ein deterministischer 6-bis-8-Sekunden-Rhythmus deutet fast immer auf einen Timeout hin. Wer solche Muster ernst nimmt, spart sich viele Irrwege – ähnlich wie bei der Analyse von TCP-Retransmissions mit Wireshark, wo Timing-Verhalten oft mehr verrät als jede einzelne Fehlermeldung.
• Auch VoIP-Umgebungen verdienen eine Baseline. Ein Referenz-Capture eines funktionierenden Login-Ablaufs – einmal aufgezeichnet und abgelegt – macht die spätere Fehlersuche dramatisch schneller. Man vergleicht den fehlerhaften Ablauf einfach Paket für Paket mit dem Soll-Zustand und sieht sofort, an welcher Stelle die Abläufe auseinanderlaufen.

Und noch ein letzter Gedanke: Zertifikatsketten sind ein Paradebeispiel für Fehler, die sich schleichend und zeitversetzt materialisieren. Die fehlerhafte Erneuerung passiert still im Hintergrund, und das Problem schlägt erst zu, wenn Clients ohne AIA-Fetching-Fähigkeit die neue Chain prüfen müssen. Wer in seiner Umgebung Embedded-Geräte betreibt – VoIP-Telefone, Drucker, IoT-Gateways, Industriesteuerungen –, sollte die Vollständigkeit der ausgelieferten Zertifikatskette aktiv überwachen und nicht nur die Restlaufzeit des Zertifikats.

Falls du gerade selbst vor einem Fall stehst, in dem sich Benutzer beschweren, aber alle Konsolen grün sind: Der Weg über den Paketmitschnitt lohnt sich fast immer. Einen guten Einstieg, wie du mit Wireshark systematisch Performance- und Verbindungsproblemen auf den Grund gehst, findest du in meinem Grundlagenartikel Warum ist mein Netzwerk langsam?. Und wenn der Fall komplexer ist oder die Zeit fehlt: Genau solche „unsichtbaren” Fehler sind mein Tagesgeschäft.