Snom D865 Secure Connection rejected

[Suboptimal]

Hallo,
habe hier ein eigenartiges Problem und da mein Partner gerade nicht aus dem Knick kommt, muss ich hier selbst mal fragen..

Ich habe hier eine 3cx Instanz die schon seit 2018 mehr oder weniger Problemlos lief. Mit der richtigen DHCP-Option funktioniert das Provisionieren von Snom D865 oder Yealink T54W ebenfalls Problemlos und ich war positiv angetan wegen der ganzen Features die uns durch exzessives Nutzen von DECT per Gigaset entgangen sind. Firmware-Updates, Style, Logo, Telefonbuch, Remote-Config... alles Super.

Nun habe ich zweite On-Premise Instanz installiert für einen unserer weiteren Standorte. Lizenz ist eine 24 SC Pro. Installiert komplett mit dem 3cx-Image als VM. Einrichtung des DHCP per isc-dhcp-server unter Debian. Was mir gleich aufgefallen ist: Die Installation hat paar Sachen die ich bei meiner ersten Instanz nicht habe und deshalb gehe ich davon aus das dort grundlegende einfache Sachen wie Provisionierung von einem Tischtelefon anders abläuft. Die DHCP-Option 66 greift ohne Probleme, jetzt passiert aber folgendes:

Nach Start des Telefons und dem Provisionierung-Vorgang flackert immer wieder eine schwarze Meldung über den gesamten Bildschirm mit der Meldung...

Secure Connection rejected... Certificate Section

Da steht eigentlich noch mehr, aber der Rest ist abgehakt. Leider kann ich auf die ganzen Debugging-Funktionen vom Snom aus dem Webinterface nicht zugreifen ohne mit der Option per Provisionierung ein Admin-Passwort festgelegt zu haben. Somit kann ich hier nur raten derzeit. Der Link zeigt auf eine https Url und genau dieser wurde auch in die Option 66 eingetragen:



Unter "Schnittstelle auswählen" habe ich nur als Option den FQDN. In meiner ersten Instanz ist dort zum Beispiel nur die interne IP-Adresse bei Methode LAN.

Nach ewigen herumflackern der Meldung, gibt er es irgendwann auf und zeigt den normalen Welcome-Screen. Bei Yealink ist teilweise noch verrückter: Dort wird zwar der SIP-Account der Nebenstelle angelegt, aber die Provisionierung bleibt unvollständig. Der Hintergrund ändert sich nicht auf Schwarz und das Logo wird auch nicht angezeigt, sondern nur der Standard von Yealink. Außerdem führt er nicht das Firmware-Update auf die 3cx-Firmware durch, selbst nach mehreren manuellen Versuchen.

Split-DNS funktioniert. Verwendet wird ein LetsEncrypt-Zertifikat mit Custom FQDN. Genau das selbe wie bei meiner ersten Instanz und da geht ohne Probleme.

Jemand eine Idee woran das lieg?

Gruß

 

[fxbastler]

Hallo @Suboptimal

Unter "Schnittstelle auswählen" habe ich nur als Option den FQDN. In meiner ersten Instanz ist dort zum Beispiel nur die interne IP-Adresse bei Methode LAN.

Ja, das ist seit geraumer Zeit so.

Drei Fragen:

1. Wurden die Telefone manuell einmalig mit wenigstens heilwegs aktueller Fimware vom Hersteller versorgt?
2. Wenn so ein Telefon startet, wird dann die Konfigurationsdatei von der 3CX angefordert und übertragen? Zu sehen in einem Wireshark Mitschnitt auf der 3CX.
3. Ist der Provisionierungslink bei allen Endgeräten gleich? Kontrolle auch über die 3CX Option Sicherheit / Angriffsschutz / Erstellung eines geheimen Schlüssels aktivieren. Dann funktioniert die Option 66 schlecht.

Nachtrag: Die Provisionierung der Endgeräte auf der zuvor bestehenden Anlage läuft über den http Port?

 

[Suboptimal]

Zu 1.: Die Firmware auf den Telefonen war gar nicht so alt. Ich hatte dennoch bei einigen das 3cx-Firmwareimage gleich direkt drauf gemacht. Hat aber nichts gebracht.

Zu 2.: Ja, wird sie. Ich hatte es sogar direkt am DHCP-Server beobachtet. Man konnte auch deutlich beim Snom den Unterschied sehen, wenn die Option 66 richtig oder falsch gesetzt war. Das komische war allerdings, das selbst wenn man die Option 66 ohne https auf http stellt und die IP-Adresse nimmt, statt dem FQDN, dann hat er dennoch die obengenannte Fehlermeldung rausgeschmissen.

Zu 3.: Der Schlüssel ist überall gleich. Die Option ist nicht aktiviert.

 

[fxbastler]

Wenn ihr selber die LE Zertifikate holt und in die 3CX packt, wird das fullchain cert verwendet?

Nachtrag: Verwendet ihr das in etwa so wie hier beschrieben, so dass auch Secure SIP aktiv ist?

 

[Suboptimal]

Bin mir zu 80% sicher das es das Fullchain ist, weil der Nginx akzeptiert es ja auch und im Browser per HTTPS sieht alles i.O. aus.

Aber ich werde es zu morgen nochmal prüfen und berichten.

 

[fxbastler]

Wenn du in den 3CX Parametern nach PROVISIONING_LINK schaust, da sind die beiden Parameter die auf _SEC enden die https FQDN. Sind die beiden Link Parameter, die nicht auf _SEC enden, mit http://fqdn angegeben?

 

[Suboptimal]

So sieht es bei mir aus. Es handelt sich bei beiden jeweils um den FQDN:



Aber ich habe das Problem gefunden: Es war tatsächlich das falsche Zertifikat. Komisch das Nginx nicht gemeckert hat. Nach Installation des FullChain klappt es dann auch mit der Provisionierung. Danke für deine Hilfe @fxbastler