3CX Hot Desking funktioniert nicht – der TLS-Fehler „Unknown CA“, den die Konsole verschweigt

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-Mitschnitt 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 der Fall analysieren ließ, warum die 3CX-Konsole hier systembedingt schweigt, warum das Thema seit der Umstellung der Let’s-Encrypt-Zertifikatsketten 2026 noch relevanter geworden ist – und wie du das Problem dauerhaft löst.

Kurz zusammengefasst:

• Ursache: Die 3CX lieferte nach einer fehlgeschlagenen Zertifikatserneuerung eine unvollständige Zertifikatskette aus. Die Telefone brachen den TLS-Handshake zum Provisionierungsdienst mit „Unknown CA“ ab.
• Warum niemand es sah: Die Konsole protokolliert nur Login und Logout, das Netzwerkmonitoring zeigt grüne Ports, und im Browser fällt eine unvollständige Kette oft gar nicht auf.
• Lösung: Zertifikat in der 3CX gezielt neu beziehen, nginx neu laden, Kette prüfen – ohne ein einziges Telefon anzufassen.

Das Fehlerbild: Login, Timeout, Logout – im Sekundentakt

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. Vereinfacht besteht der Ablauf 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 nicht innerhalb weniger Sekunden – in diesem Fall reproduzierbar nach rund 6 bis 8 Sekunden – ein 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 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 nie bis zur Applikation durchgedrungen ist. Auch der Webserver selbst hilft hier selten weiter: Vom Client abgebrochene Handshakes landen bei nginx typischerweise unterhalb des Standard-Loglevels und tauchen im normalen Error-Log nicht auf.

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. Entscheidend ist dabei der richtige Messpunkt: Du brauchst eine Stelle, an der du sowohl die SIP-Signalisierung als auch den HTTPS-Abruf der Provisionierung siehst. Das ist bei 3CX mit SBC nicht selbstverständlich, denn durch den SBC-Tunnel läuft in einem typischen Setup nur SIP und RTP – die Konfiguration holt sich das Telefon direkt per HTTPS von der Anlage. Am zuverlässigsten ist deshalb ein Mirror-Port (SPAN) am Switch-Port eines betroffenen Telefons. Wichtig ist außerdem: 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 Standard-HTTPS-Port der 3CX (je nach Installation auch 443). 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 seiner Certificate-Nachricht.
• 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 auf fatale TLS-Alerts:

Der Alert-Level 2 steht dabei für Fatal – also Fehler, nach denen die TLS-Verbindung sofort beendet wird. Willst du gezielt nur „Unknown CA“ sehen, nutzt du tls.alert_message.desc == 48. Weitere nützliche Filter für solche Analysen findest du in meinem Überblick über die 10 wichtigsten Wireshark-Display-Filter.

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 der Server damit nicht vertrauenswürdig – es könnte sich ebenso um einen Man-in-the-Middle handeln –, 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 Timeout → Rollback des Logins. Jedes einzelne Symptom, inklusive des merkwürdig regelmäßigen Timings, war jetzt erklärbar – mit einem einzigen Paketmitschnitt. Wie sich abgebrochene Verbindungen generell systematisch untersuchen lassen, habe ich in meinem Artikel über das Analysieren von Verbindungsabbrüchen ausführlicher beschrieben.

Warum der Alert überhaupt lesbar war

Ein Detail, das bei solchen Analysen gern übersehen wird: Dass Zertifikat und Alert im Trace im Klartext zu sehen waren, liegt daran, dass Telefon und Server TLS 1.2 ausgehandelt haben. Bei TLS 1.3 werden die Certificate-Nachricht und ein Alert in dieser Phase bereits verschlüsselt übertragen. Im Trace siehst du dann nur noch, dass der Client die Verbindung kurz nach dem Server Hello beendet – aber nicht mehr, warum. Spätestens dann lohnt sich der Gegencheck der Zertifikatskette mit openssl, den ich weiter unten zeige.

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) ansehen. Let’s Encrypt signiert Serverzertifikate nicht direkt mit seinem Root-Zertifikat ISRG Root X1, sondern über Intermediate-CAs. Das Root-Zertifikat bringt der Client in seinem Trust Store selbst mit – die Zwischenglieder dagegen muss der Server im TLS-Handshake mit ausliefern. Man spricht dann von der Fullchain.

Und genau bei diesen Zwischengliedern hat sich 2026 einiges bewegt. Seit dem 13. Mai 2026 stellt Let’s Encrypt auch im Standardprofil auf die neue „Generation Y“-Hierarchie um. Die Kette wird dadurch länger:

Der Punkt dabei: Die neuen Roots ISRG Root YR und ISRG Root YE sind in vielen Trust Stores – und erst recht in der Firmware von Telefonen – noch nicht hinterlegt. Ein Gerät, das nur ISRG Root X1 kennt, kann die Kette deshalb nur aufbauen, wenn der Server beide Zwischenzertifikate mitschickt. Jedes zusätzliche Glied in der Kette ist eine zusätzliche Stelle, an der sie unvollständig ausgeliefert werden kann.

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.

Das Schöne an der Paketanalyse: Du kannst das direkt im Trace belegen. Mit dem folgenden Filter springst du zur Certificate-Nachricht des Servers und siehst im Paketdetail unter Certificates, wie viele Zertifikate tatsächlich ausgeliefert wurden:

Steht dort nur ein einziges Zertifikat – oder fehlt bei Generation Y das zweite Zwischenglied –, ist die Kette unvollständig. Damit hast du nicht nur eine Vermutung, sondern einen objektiven Beweis, den du jedem Team und jedem Hersteller-Support vorlegen kannst.

Warum Browser das nicht merken – Telefone aber schon

Und hier kommt ein Detail ins Spiel, das viele aus dem Browser-Alltag nicht auf dem Schirm haben: Browser kompensieren fehlende Intermediates. Chrome und Safari laden fehlende Zwischenzertifikate per AIA-Fetching (Authority Information Access) selbstständig aus dem Internet nach, Firefox bringt die Intermediates der bekannten CAs gleich vorinstalliert mit. Dazu kommen Caches bereits gesehener Zertifikate. Deshalb fällt eine unvollständige Chain im Browser oft gar nicht auf – die 3CX-Weboberfläche lädt trotzdem mit Schloss-Symbol.

Die Embedded-Crypto-Engines in VoIP-Telefonen können das nicht. Ein Yealink-Telefon validiert stur gegen das, was der Server im Handshake liefert, plus seinen lokalen Trust Store. Fehlt ein Glied 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 begrenzten Laufzeit der Let’s-Encrypt-Zertifikate, aktuell standardmäßig 90 Tage. Die 3CX erneuert das Zertifikat automatisch – und wenn bei dieser Erneuerung die Chain unvollständig 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.

Und dieser Effekt wird künftig häufiger auftreten: Let’s Encrypt verkürzt die Laufzeiten schrittweise weiter – 2027 auf 64 Tage, 2028 auf 45 Tage. Mehr Erneuerungen bedeuten mehr Gelegenheiten, bei denen eine Kette unvollständig ausgeliefert werden kann.

So prüfst du die Zertifikatskette – auch ohne Telefon

Bevor du an der Anlage etwas änderst, lohnt sich ein schneller Gegencheck von einem beliebigen Linux- oder macOS-Rechner aus. openssl s_client verhält sich dabei ähnlich stur wie ein Telefon: Es lädt keine fehlenden Intermediates nach, sondern prüft nur, was der Server tatsächlich liefert. Ersetze den Hostnamen durch den FQDN deiner Anlage:

Achte in der Ausgabe auf zwei Stellen: Unter Certificate chain siehst du jedes ausgelieferte Zertifikat mit Subject und Issuer. Und ganz unten steht der Prüfstatus. Lautet er „Verify return code: 0 (ok)“, ist die Kette vollständig. Steht dort dagegen „unable to verify the first certificate“, fehlt mindestens ein Intermediate – genau das Fehlerbild aus diesem Fall.

Die Lösung – Zertifikat in der 3CX neu beziehen

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 sauber im Webserver zu hinterlegen. 3CX dokumentiert dafür einen eigenen Weg für die von 3CX bereitgestellten FQDNs.

Vorher aber ein wichtiger Gedanke: Prüfe, warum die automatische Erneuerung gescheitert ist. Typische Ursachen sind Firewall-Regeln, die der Anlage den Weg nach außen versperren, oder Verbindungsprobleme zum Zeitpunkt der Erneuerung. Bleibt die Ursache bestehen, stehst du beim nächsten Erneuerungszyklus wieder vor demselben Problem.

Schritt 1: Erneuerung in der Konsole vorbereiten. In der 3CX-Verwaltungskonsole unter Admin → Erweitert → Parameter den Parameter TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED suchen und seinen Wert auf 1 setzen. Existiert der Parameter noch nicht, legst du ihn über Hinzufügen an.

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

Auf einer Windows-Installation rufst du dasselbe Werkzeug in einer Eingabeaufforderung mit Administratorrechten auf:

Das Tool fordert ein frisches Zertifikat an und schreibt die Kette neu in die Webserver-Konfiguration. Gib dem Vorgang ein paar Minuten Zeit, bevor du weitermachst – rund fünf Minuten sind ein sicherer Puffer.

Schritt 3: nginx neu laden. Damit der Webserver die neue Zertifikatsdatei auch tatsächlich ausliefert, muss er die Konfiguration neu einlesen. Unter Linux:

Unter Windows startest du den nginx-Dienst der 3CX in einer administrativen Eingabeaufforderung neu:

Schritt 4: Kette und Funktion prüfen. Wiederhole zuerst den openssl s_client-Check von oben – erst wenn dort „Verify return code: 0 (ok)“ steht, liefert die Anlage die vollständige Kette aus. 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 – oberhalb von TCP, aber unterhalb der eigentlichen Applikation – 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 das 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. Du vergleichst den fehlerhaften Ablauf einfach Paket für Paket mit dem Soll-Zustand und siehst 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 zeigen. Die fehlerhafte Erneuerung passiert still im Hintergrund, und das Problem schlägt erst zu, wenn Clients ohne AIA-Fetching die neue Chain prüfen müssen. Wer in seiner Umgebung Embedded-Geräte betreibt – VoIP-Telefone, Drucker, IoT-Gateways, Industriesteuerungen –, sollte deshalb die Vollständigkeit der ausgelieferten Zertifikatskette aktiv überwachen und nicht nur die Restlaufzeit des Zertifikats. Mit kürzer werdenden Laufzeiten und längeren Ketten wird das eher wichtiger als unwichtiger.

Häufige Fragen zu „Unknown CA“ und 3CX Hot Desking

Was bedeutet der TLS-Alert „Unknown CA“?

Der Client – hier das Telefon – konnte das Zertifikat des Servers keiner ihm bekannten Zertifizierungsstelle zuordnen und hat den Handshake deshalb abgebrochen. Die häufigste Ursache ist nicht eine unbekannte CA an sich, sondern eine unvollständig ausgelieferte Zertifikatskette, bei der dem Client ein Zwischenglied fehlt.

Warum funktioniert die 3CX-Weboberfläche im Browser, die Telefone aber nicht?

Browser laden fehlende Intermediates nach oder bringen sie bereits mit. Telefone und andere Embedded-Geräte prüfen nur das, was der Server tatsächlich schickt. Ein erfolgreicher Browser-Test ist deshalb kein Beweis für eine vollständige Kette.

Wie erkenne ich eine unvollständige Zertifikatskette ohne Wireshark?

Am schnellsten mit openssl s_client wie oben gezeigt: Liefert der Prüfstatus „unable to verify the first certificate“, fehlt ein Intermediate. Den eigentlichen Beweis, dass genau das die Telefone stört, liefert aber erst der Mitschnitt mit dem Fatal Alert.

Fazit: Wenn alle Konsolen grün sind, lohnt der Blick auf die Leitung

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. Wie du dabei strukturiert vorgehst, statt an fünf Stellen gleichzeitig zu suchen, beschreibe ich in meiner 5-Schritte-Methodik zum Eingrenzen von Netzwerkproblemen. Einen guten Einstieg in die Wireshark-Analyse von Performance- und Verbindungsproblemen findest du außerdem in meinem Grundlagenartikel Warum ist mein Netzwerk langsam?.

Und wenn der Fall komplexer ist, die Zeit fehlt oder sich Teams gegenseitig den Ball zuspielen: Genau solche „unsichtbaren“ Fehler sind mein Tagesgeschäft. Ob du die Telefonie verantwortest, das Netzwerk betreust oder als IT-Leitung einfach wieder Ruhe im Betrieb brauchst – mit einem Paketmitschnitt bekommst du objektive Fakten statt Vermutungen. Lass uns in einem kostenlosen Erstgespräch über deinen Fall sprechen. Einen Überblick, wie ich dich dabei unterstützen kann, findest du auf meiner Seite mit den Leistungen.