Aufruf Telefon UI funktioniert nicht....

[Juergen61]

Nachdem ich mich auf der 3cx angemeldet habe, wähle ich irgend ein Telefon aus um anschließend via Button "Telefon-UI" das jeweils Telefon zu konfigurieren.
Ich erhalte aber leider den Hinweis: "Diese Verbindung ist nicht privat". Wenn ich mir anschließend die Details einblende, heißt es:
Safari gibt einen Warnhinweis aus...
Lasse ich mir jetzt noch das Zertifikat anzeigen, erhalte ich folgendes:
Zertifikat 001565f50ad6 verwendet eine beschädigte Schlüsselgröße.

Alle Telefone kann ich anfingen... TK und Telefone haben ein eigenes Netz.

Über Hilfestellung bin ich mehr als dankbar....

mfg

 

[fxbastler]

Hallo,

passiert das auch wenn du einen anderen (Chromium basierenden) Browser benutzt?

Grundsätzlich: das ist normal. Das ist ja das Telefon. Das Telefon UI wird bei dir mit Sicherheit das Telefon über die IP und in deinem Fall vmtl. per HTTPS ansprechen. Wenn ja: hat das Telefon denn ein von deinem Computer bzw. Browser akkreditiertes Zertifikat über diese IP? Es würde mich sehr interessieren wie das möglich sein soll. Das geht nicht.

Man mich leicht wundert: die Meldung 'nicht privat' weist bei den meisten Browsern üblicherweise auf eine HTTP Verbindung hin. Bei HTTPS ohne entspr. Zertifikat kommt so etwas wie 'nicht sicher'. Habe keinen Safari hier zum Testen.

 

[Juergen61]

... hier drei Beispiele:

Noch zur Info:
TK und alle dazugehörigen Komponenten sind im Netz 192.168.5.0 und mein normales mit allen Rechnern und Server im 192.168.1.0
Mein FQDN ist lokal meineTK.my3cx.de die auf den WEB Server im 192.168.1.0 steht.

 

[mbehrens]

TK und alle dazugehörigen Komponenten sind im Netz 192.168.5.0 und mein normales mit allen Rechnern und Server im 192.168.1.0
Mein FQDN ist lokal meineTK.my3cx.de die auf den WEB Server im 192.168.1.0 steht.

Wo steht denn nun die TK? Warum zeigt der FQDN der TK auf einem Webserver im fremden Netzsegment?

Ansonsten stimmen doch die Meldungen, was auch ein Blick in die verwendeten Zertifikate zeigen dürfte. Regelmäßig stehen IP Adressen nicht in Zertifikaten. Des weiteren wird wohl auch die verwendete Root-CA nicht manuell als vertrauenswürdig deklariert sein.

 

[Juergen61]

Nun, die TK steht wie bereits gesagt im192.168.5.er Netz - mein Apache sprich Ubuntu Server steht im 192.168.1.er Netz.
Soll denn die TK.my3cx,de auf meine IP meines Web zeigen oder auf die IP der TK?

 

[fxbastler]

TK und alle dazugehörigen Komponenten sind im Netz 192.168.5.0 und mein normales mit allen Rechnern und Server im 192.168.1.0

Soll denn die TK.my3cx,de auf meine IP meines Web zeigen oder auf die IP der TK?

Zur Klärung: die 3CX bringt einen eigenen Webserver (nginx) mit. Der ist untrennbar mit dem Rest verbunden. Auf diesen soll der FQDN der 3CX auch verweisen damit die Dienste entspr. funktionieren können. Sowohl intern als auch per NAT von extern. Dann funktioniert auch der Aufruf per HTTPS der 3CX Verwaltung, des Webclient und sonst. verschlüsseltelter Kommunikation mit der 3CX.

Spezialfall: Wenn du Ahnung hast und für besondere Situationen einen Reverse Proxy einsetzt, dann verweisen verschiedene (zumeist externe) Links auf diesen - aber das ist ein ganz anderes Thema. Das hat auch nichts mit der Fragestellung zu tun. Das habe ich nur der Vollständigkeit halber angegeben.

Standardinstallation: alles dreht sich um die 3CX. Deren Equipment ist idealerweise im gleichen lokalen Netzwerk.

Schau dir bitte das Adminhandbuch bzgl. Installation und die von 3CX kostenlos angebotenen Kurse und Folien samt Kommentaren (insbes. von Anfang an) an.

Noch zu meinem vorigen Post: wenn Kommunikation per HTTPS erfolgt, dann ist diese immer verschlüsselt (ergo privat). Der Browser erachtet dann 'evtl. nur' den Kommunikationsschlüssel (das Zertifikat) als nicht sicher, warnt vor einer Kommunikation damit und drückt dies in einer solchen mißverständlichen (in meinen Augen nicht richtigen) Meldung aus. Der Schlüssel könnte eben nicht mehr so geheim sein wie er sollte. Der Browser kann das nicht prüfen da der Aussteller des Zertfikates (oder die wesentlichen Mitunterzeichnenden) nicht bekannt / nicht vertrauenswürdig sind. Siehe auch hier, hier und generell z.B. auch mal hier.

Das alles nur am Rande. Die Frage des Threads wurde ja bereits beantwortet.

 

[Juergen61]

Zur Klärung: die 3CX bringt einen eigenen Webserver (nginx) mit. Der ist untrennbar mit dem Rest verbunden. Auf diesen soll der FQDN der 3CX auch verweisen damit die Dienste entspr. funktionieren können. Sowohl intern als auch per NAT von extern. Dann funktioniert auch der Aufruf per HTTPS der 3CX Verwaltung, des Webclient und sonst. verschlüsseltelter Kommunikation mit der 3CX.

Spezialfall: Wenn du Ahnung hast und für besondere Situationen einen Reverse Proxy einsetzt, dann verweisen verschiedene (zumeist externe) Links auf diesen - aber das ist ein ganz anderes Thema. Das hat auch nichts mit der Fragestellung zu tun. Das habe ich nur der Vollständigkeit halber angegeben.

Standardinstallation: alles dreht sich um die 3CX. Deren Equipment ist idealerweise im gleichen lokalen Netzwerk.

Schau dir bitte das Adminhandbuch bzgl. Installation und die von 3CX kostenlos angebotenen Kurse und Folien samt Kommentaren (insbes. von Anfang an) an.

Noch zu meinem vorigen Post: wenn Kommunikation per HTTPS erfolgt, dann ist diese immer verschlüsselt (ergo privat). Der Browser erachtet dann 'evtl. nur' den Kommunikationsschlüssel (das Zertifikat) als nicht sicher, warnt vor einer Kommunikation damit und drückt dies in einer solchen mißverständlichen (in meinen Augen nicht richtigen) Meldung aus. Der Schlüssel könnte eben nicht mehr so geheim sein wie er sollte. Der Browser kann das nicht prüfen da der Aussteller des Zertfikates (oder die wesentlichen Mitunterzeichnenden) nicht bekannt / nicht vertrauenswürdig sind. Siehe auch hier, hier und generell z.B. auch mal hier.

Das alles nur am Rande. Die Frage des Threads wurde ja bereits beantwortet.

Vielen Dank für die Nachricht - war sehr informativ...