15
ProCall Enterprise 8 - jemand im Einsatz?
Moin,
wir haben seit einiger Zeit ProCall Enterprise 8 im Einsatz. Alles läuft prima aber beim Öffnen des Chats kommt dann eine Meldung, dass die Verbindung nicht hergestellt werden kann und unten in der Leiste "authentication error". Sekunden später ist alles wieder in Ordnung und funktioniert auch.
Nachdem ich im ProCall Client den Debug Modus eingeschaltet habe, konnte ich sehen, dass der Client über die Methode "connectWebView" sich versucht mit dem UCConnect Web Service zu verbinden und dann mit folgendem Fehler quittiert: Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID
Der Aufruf der URL ist in Gegensatz zur Clientverbindung (HTTP über Port 7222) über HTTPS und Port 7225. Die aufgerufene URL ist lokal also in der Form "https://procallserver.meinedomäne.xyz:7225/ws/client..." Nach zwei Versuchen gibt es ein Fallback auf HTTP, dann klappt es.
Der UC Web Server HTTPS hat hier allerdings ein SSL-Zertifikat im Einsatz der auf *.firmenname.com ausgestellt ist. Kann also nicht klappen, da interner Domänenname aufgerufen wird. Wenn ich die aufgerufene URL in einem Browser kopiere und anpasse, dann geht es auch.
Vielleicht hat jemand, der auch ProCall 8 einsetzt, dieses Problem gehabt? Die eigentliche Frage ist, wie bzw. wo kann ich bei den Clients die UC Web Server URL anpassen?
wir haben seit einiger Zeit ProCall Enterprise 8 im Einsatz. Alles läuft prima aber beim Öffnen des Chats kommt dann eine Meldung, dass die Verbindung nicht hergestellt werden kann und unten in der Leiste "authentication error". Sekunden später ist alles wieder in Ordnung und funktioniert auch.
Nachdem ich im ProCall Client den Debug Modus eingeschaltet habe, konnte ich sehen, dass der Client über die Methode "connectWebView" sich versucht mit dem UCConnect Web Service zu verbinden und dann mit folgendem Fehler quittiert: Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID
Der Aufruf der URL ist in Gegensatz zur Clientverbindung (HTTP über Port 7222) über HTTPS und Port 7225. Die aufgerufene URL ist lokal also in der Form "https://procallserver.meinedomäne.xyz:7225/ws/client..." Nach zwei Versuchen gibt es ein Fallback auf HTTP, dann klappt es.
Der UC Web Server HTTPS hat hier allerdings ein SSL-Zertifikat im Einsatz der auf *.firmenname.com ausgestellt ist. Kann also nicht klappen, da interner Domänenname aufgerufen wird. Wenn ich die aufgerufene URL in einem Browser kopiere und anpasse, dann geht es auch.
Vielleicht hat jemand, der auch ProCall 8 einsetzt, dieses Problem gehabt? Die eigentliche Frage ist, wie bzw. wo kann ich bei den Clients die UC Web Server URL anpassen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 11355848048
Url: https://administrator.de/forum/procall-enterprise-8-jemand-im-einsatz-11355848048.html
Ausgedruckt am: 21.12.2024 um 13:12 Uhr
15 Kommentare
Neuester Kommentar
Hast du mal ein Ticket bei ESTOS auf gemacht? Die konnten mir schon ab und zu mal helfen.
Moin,
Leg in eurem DNS eine neue Zone an:
In der Zone einen neuen Host-A Record, der keinen Namen hat, aber auf die IP des procall-Servers zeigt.
Obendrein in der Zone
Dann sollte es passen.
Per GPO dann noch den Clients den Namen auf den "richtigen" Server zeigen.
Alternativ erzeugst du über deine interne CA (sofern vorhanden) ein eigenes SAN-Zertifikat, welches neben
Mit der letzten Variante läuft das bei ins ganz gut.
ERR_CERT_COMMON_NAME_INVALID
die Meldung ist ja eindeutig, der Name passt nicht zum Namen im Zertifikat.Der UC Web Server HTTPS hat hier allerdings ein SSL-Zertifikat im Einsatz der auf *.firmenname.com ausgestellt ist. Kann also nicht klappen, da interner Domänenname aufgerufen wird.
Leg in eurem DNS eine neue Zone an:
procall.firmenname.comIn der Zone einen neuen Host-A Record, der keinen Namen hat, aber auf die IP des procall-Servers zeigt.
Obendrein in der Zone
meinedomäne.xyz im Pfad _tcp den Eintrag _ctiserver anlegen, der auf procall.firmenname.com zeigt.Dann sollte es passen.
Per GPO dann noch den Clients den Namen auf den "richtigen" Server zeigen.
Alternativ erzeugst du über deine interne CA (sofern vorhanden) ein eigenes SAN-Zertifikat, welches neben
procallserver.meinedomäne.xyz aus procallserver.firmenname.com enthält.Mit der letzten Variante läuft das bei ins ganz gut.
1
@em-pie
DNS Zone mit procall.firmanname.com exisitert. Unter _TCP habe ich den Serviceeintrag auch und auch ein SAN Zertifikat. Das "Problem" ist aber nach wie vor da, also auch wenn der Client mit procall.firmenname.com installiert wird, Chat via WebView2 will immer noch procall.meinedomäne.xyz kontaktieren.
Vielleicht mache ich irgendwo einen Fehler, aber wo?
@ukulele-7 Ticket eröffnen geht nur via Estos Partner und unser Partner ist eine "Schnarchnase", da kann ich auch gleich sein lassen
DNS Zone mit procall.firmanname.com exisitert. Unter _TCP habe ich den Serviceeintrag auch und auch ein SAN Zertifikat. Das "Problem" ist aber nach wie vor da, also auch wenn der Client mit procall.firmenname.com installiert wird, Chat via WebView2 will immer noch procall.meinedomäne.xyz kontaktieren.
Vielleicht mache ich irgendwo einen Fehler, aber wo?
@ukulele-7 Ticket eröffnen geht nur via Estos Partner und unser Partner ist eine "Schnarchnase", da kann ich auch gleich sein lassen
Stehen in den Servereinstellungen (Dort, wo die Dienste konfiguriert werden) von ProCall überall die richtigen Einträge.
Komme gerade nicht ans unseren Server, um dir einen Screenshot zu zeigen.
Komme gerade nicht ans unseren Server, um dir einen Screenshot zu zeigen.
Moin,
Gruß,
Dani
Vielleicht hat jemand, der auch ProCall 8 einsetzt, dieses Problem gehabt?
Ne, da wir Split-DNS einsetzen.Der UC Web Server HTTPS hat hier allerdings ein SSL-Zertifikat im Einsatz der auf *.firmenname.com ausgestellt ist. Kann also nicht klappen, da interner Domänenname aufgerufen wird.
Warum nicht ein neues SSL-Zertifikat abrufen, welches beide Domains (auch als SAN) abdeckt? Da bietet sich inzwischen auch LE in Verbindung mit PowerShell an.Das "Problem" ist aber nach wie vor da, also auch wenn der Client mit procall.firmenname.com installiert wird, Chat via WebView2 will immer noch procall.meinedomäne.xyz kontaktieren.
gibt es in dieser Zone die selben DNS Einträge für die automatische Findung des UC Servers? Hast du mal vor dem Start von ProCall Client Wireshark gestartet und die DNS Abfragen analysiert?@ukulele-7 Ticket eröffnen geht nur via Estos Partner und unser Partner ist eine "Schnarchnase", da kann ich auch gleich sein lassen
Es gibt auch kompetente Partner von Estos. Ansonsten hilft es auch ungemein Estos darüber in Kenntnis zu setzen, damit hier Abhilfe geschaffen wird.Gruß,
Dani
@em-pie heute habe ich dafür keine Zeit, andere Dinge haben höhere Prio, kann erst Donnerstag wieder da reinschauen
@Dani wir haben ein *-Firmen-Zertifikat mit zwei Jahren Gültigkeit. Dies wird überall eingesetzt, wo externer Zugriff erfolgt. ein LE-Zertifikat mit 90 Tagen Gültigkeit ist hier nicht sinnvoll. Das mit Wireshark ist eine gute Idee, werde ich mal machen.
@Dani wir haben ein *-Firmen-Zertifikat mit zwei Jahren Gültigkeit. Dies wird überall eingesetzt, wo externer Zugriff erfolgt. ein LE-Zertifikat mit 90 Tagen Gültigkeit ist hier nicht sinnvoll. Das mit Wireshark ist eine gute Idee, werde ich mal machen.
Zitat von @DerMaddin:
@ukulele-7 Ticket eröffnen geht nur via Estos Partner und unser Partner ist eine "Schnarchnase", da kann ich auch gleich sein lassen
Oh wusste ich gar nicht. Das letzte mal ist bei mir ein paar Jahre her, damals ging das "irgendwie".@ukulele-7 Ticket eröffnen geht nur via Estos Partner und unser Partner ist eine "Schnarchnase", da kann ich auch gleich sein lassen
Haste's gelöst?
Sobald Du am Server an der schon richtig erkannten Stelle: UC-Serververwaltungskonsole ->Extras ->Netzwerkdienste ->UCServer https ein passendes Zertifikat einlegst, läuft es sofort bei den Clients ohne Weiteres.
Sobald Du am Server an der schon richtig erkannten Stelle: UC-Serververwaltungskonsole ->Extras ->Netzwerkdienste ->UCServer https ein passendes Zertifikat einlegst, läuft es sofort bei den Clients ohne Weiteres.
An der Stelle ist das SSL Zertifikat vorhanden und funktioniert, dies allerdings nur für Clients die über das Internet kommen. Alle anderen im internen LAN wollen den Server über Port 7225 mit dem lokalen Hostnamen erreichen und da klappt das natürlich nicht, weil SSL-Zertifikat diesen nicht abdeckt. Ein SAN-Zertifikat können wir nicht einsetzen, da wir ein *-Zertifikat für die komplette Domain haben (Internet-Domain).
Das "Problem" kommt vermutlich historisch als der ProCall Server installiert wurde, denn nur da hat man initial den Servernamen angegeben. Diesen zu ändern, scheint nachträglich nicht mehr möglich zu sein.
Das "Problem" kommt vermutlich historisch als der ProCall Server installiert wurde, denn nur da hat man initial den Servernamen angegeben. Diesen zu ändern, scheint nachträglich nicht mehr möglich zu sein.
Nimm eine interne CA und die Zertifikatsvorlage "Webserver". Beantrage damit ein Zertifikat und setze es dort ein - fertig.
??? Ich verstehe nur Bahnhof. Wo soll ich was beantragen?
Ein internes Domain-Zertifikat ist hier nur die Verlagerung des Problems von internen Clients auf die externen (Mobilgeräte). Dort ist die interne CA unbekannt und ein Fallback von HTTPS zu HTTP gibt es nicht.
Ein internes Domain-Zertifikat ist hier nur die Verlagerung des Problems von internen Clients auf die externen (Mobilgeräte). Dort ist die interne CA unbekannt und ein Fallback von HTTPS zu HTTP gibt es nicht.
Ok, an deine Anforderung mit Mobilgeräten habe ich nicht gedacht.
Ein internes Domain-Zertifikat ist hier nur die Verlagerung des Problems von internen Clients auf die externen (Mobilgeräte)
Warum? Habt ihr ProCall per PortForwarding öffentlich bereitgestellt?Das sind doch, so glaube ich, Webservices. Prüfe doch, ob du dann einen ReverseProxy vorschalten kannst (und solltest), der das „offizielle“ Zertifikat nach extern aushändigt.
Ansonsten:
Im DNS ne neue Zone anlegen:
ProCall.Company.de
Dort einen neuen Eintrag (Host A) ohne Namen mit der IP des Procalls anlegen.
Im ProCall-Server dann das öffentliche Zertifikat hinterlegen und überall den Namen „ProCall.company.de“ angeben.
Aktiv hab ich es das mit ProCall noch nicht realisiert, läuft mit dem Prinzip aber für div. Webserver hier bei uns…
Moin,
Damit verbunden ist es auch Best Practise einen Reverse Proxy für die Web Services zu nutzen. Achte darauf, dass der Reverse Proxy auch Web Sockets unterstützt. Somit kannst du innerhalb deines Netzwerks auf dem ProCall Server ein internes Zertifikat nutzen. Auf dem Reverse Proxy nutzt das gekaufte Zertifikat.
Haben wir genau so bei uns seit Version 6 im Einsatz. Einzig die Einrichtung und Routing von STUN/TURN war eine Herausforderung. Aber einmal funktionstüchtig eingerichtet, läuft es.
Gruß,
Dani
Ein internes Domain-Zertifikat ist hier nur die Verlagerung des Problems von internen Clients auf die externen (Mobilgeräte).
Ich gehe davon aus, dass du mit externen Mobilgeräten (Tablet und Smartphone) meinst. Dort ist die ProCall App installiert. Somit solltest du keine direkte Kommunikation mit dem ProCall Server realisieren, sondern über einen STUN/TURN Server von Estos. Das ist auch so dokumentiert.Damit verbunden ist es auch Best Practise einen Reverse Proxy für die Web Services zu nutzen. Achte darauf, dass der Reverse Proxy auch Web Sockets unterstützt. Somit kannst du innerhalb deines Netzwerks auf dem ProCall Server ein internes Zertifikat nutzen. Auf dem Reverse Proxy nutzt das gekaufte Zertifikat.
Haben wir genau so bei uns seit Version 6 im Einsatz. Einzig die Einrichtung und Routing von STUN/TURN war eine Herausforderung. Aber einmal funktionstüchtig eingerichtet, läuft es.
Ansonsten:
Im DNS ne neue Zone anlegen:
ProCall.Company.de
Dort einen neuen Eintrag (Host A) ohne Namen mit der IP des Procalls anlegen.
Setzt voraus, dass auf dem Server ausschließlich ProCall Server betrieben und bereitgestellt wird. Des weiteren werden vermutlich die mobilen Clients mit der Estos App innerhalb des LANs nicht mehr funktionieren, weil diese eine Art Pinning vornehmen. Das ist der Grund warum wir auch innerhalb des LANs den Traffic auf die STUN/TURN Server routen.Im DNS ne neue Zone anlegen:
ProCall.Company.de
Dort einen neuen Eintrag (Host A) ohne Namen mit der IP des Procalls anlegen.
Gruß,
Dani
DNS A Eintrag mit procall.internetdomain.com hilft hier nicht. Lokale Clients (im LAN) verbinden sich dann mit der "Internet-URL) zwar über Port 7222 aber der Chat (man wechselt auf Chat-Reiter) öffnet eine Verbindung zum HTTPS-Web Server über 7225 und will nichts anderes als procall.internedomain.xyz aufrufen.
Die Idee mit dem ReverseProxy kann ich versuchen umzusetzen. Vielleicht gleich die Weiterleitung intern über http statt https.
Die Idee mit dem ReverseProxy kann ich versuchen umzusetzen. Vielleicht gleich die Weiterleitung intern über http statt https.
