[HowTo] Eigenes Zertifikat für die Domäne bzw. die Fritz!Box Fernwartung

Nochmal OT:
Im Moment warte ich auf die Freigabe der Releases für die 7390/7490, das allgemeine Probieren und Testen macht derzeit wenig Sinn ... es ändert sich einfach noch zu viel von Labor- zu Labor-Version...
Ich find schon, dass es sich lohnt, jetzt zu testen. Alles, was jetzt nicht gefunden und gemeldet wird, kommt in die kommende Final. Da hilft es wenig, hinterher zu "weinen".

So, jetzt aber BTT.
 
Alles, was jetzt nicht gefunden und gemeldet wird, kommt in die kommende Final. Da hilft es wenig, hinterher zu "weinen".
Da hast Du falsch verstanden, was ich unter "Probieren und Testen" verstehe.

Dabei geht es dann eher darum, wie die internen Mechanismen (von SSL-Zertifikaten bis FTP-Server, von VPN bis Telnet) so funktionieren und wo sich die Späße verbergen.
Gerade an den für mich interessanten Stellen sind im Moment noch heftige Umbauten zu verzeichnen. Wer sich mal wirklich gekonnt von AVM an der Nase herumführen lassen will, kann ja mal das "neue" Binary "/bin/getprivkeypass" ausprobieren (das paßt dann auch wieder zum Thema, damit wird der private Schlüssel für den Gebrauch bei FTP-SSL geöffnet).

Wenn ich einen "Fehler" finde, tue ich den hier kund ... bringt meines Erachtens mehr, als bei AVM blind in das Feedback die x-te Meldung zu tippen. Außerdem bin ich mit dem Umgang von AVM mit seinen Kunden (wenn es eben nicht nur um "mein Router routet nicht" geht) so überhaupt nicht einverstanden ... das gehört aber wirklich in einen anderen Thread.

Alles, was ich bisher irgendwo hier im IPPF zu Problemen (egal ob allgemein anerkannt oder nur für mich relevant) geschrieben habe, wurde auch immer brav an AVM gemeldet. Das Feedback dazu seitens AVM veranlaßte mich aber (seit Januar 2014), keine weiteren Kontakte mit AVM pflegen zu wollen ... meine persönliche Entscheidung.
 
Nexus 5 Android 4.4.4. Über die Funktion zum import eigener Zertifikate. Das Netz ist voll wegen der Geschichte mit root-cas im Netz.

Ich installiere es ja gerade um Vertrauen zu schaffen. Bei einem eigens installierten Zertifikat ist die Meldung nervig. Sinnvoll wenn unbefugt was neu installiert wurde.

Aber wir kommen hier weit vom Thema ab. BTT
 
Nexus 5 Android 4.4.4. Über die Funktion zum import eigener Zertifikate. Das Netz ist voll wegen der Geschichte mit root-cas im Netz.
Trotz BTT-Forderung noch eine Bemerkung: (Notfalls in einen eigenen Thread verschieben - "CA-Probleme mit Nexus 5" o.s.ä.)

Ich habe im Netz gesucht und irgendwie nur sehr wenige Nutzer mit Problemen beim Zertifikate-Handling (Nexus 5 Android 4.4.4 - ich hatte auch vorher schon irgendwie verstanden, daß das KitKat-Update wg. der neuen OpenSSL-CVEs erst seit einer knappen Woche überhaupt raus ist) gefunden. Entweder es benutzt fast niemand ein eigenes Zertifikat (das muß ja nicht unbedingt eine eigene - persönliche - CA sein, es reicht ja schon ein "Enterprise-Zertifikat" für WLAN-EAP o.ä.) oder bei Dir läuft da etwas schief. Oder es ist unter der neuen Version noch nicht genügend Leuten aufgefallen ... unter https://code.google.com/p/android/issues/list habe ich jedenfalls auf Anhieb auch nichts dazu gefunden.

Hier wird zwar der Import von Zertifikaten (ab 4.3) beschrieben, mangels Nexus 5 kann ich das aber natürlich nicht selbst testen. Das einzige, was mir beim Lesen eben auffällt - die Zertifikate werden im DER-Format erwartet. Allerdings glaube ich selbst nicht so richtig, daß es an so einer simplen Sache scheitert - erst recht nicht ohne passende Fehlermeldung.
 
Nicht nur Android 4.4.4, nicht nur auf dem Nexus 5 - auch ältere Versionen. War schon vor vier Jahren auf dem S2, vor zwei Jahren auf dem S3 nicht zu machen... Such nach der von mir geposteten Meldung und du wirst x Ergebnisse finden. Habe Wochen gelesen und es nicht zum laufen bekommen ;)
 
@Smithy:

Wenn (falls) Du auf die neue Labor updatest, achtest Du mal bitte darauf, ob das Zertifikat diesmal erhalten bleibt ?

Bei der letzten Labor wurde es - nach Ansage - ja gelöscht und mußte neu importiert werden. Wenn ich mich nicht komplett vertan habe, ist beim Update einer 7490 das benutzerdefinierte Zertifikat verschwunden und durch ein "boxgeneriertes" ersetzt worden. Aber immerhin zeigt die Box jetzt von sich aus an, woher sie das Zertifikat hat ...

Und auch die Anzeige des Fingerprints ist ein weiterer Schritt in die richtige Richtung. Wer den kennt, kann die Authentizität der Gegenstelle dann auch "per Augenschein" testen, wenn er auf einem entfernten Client unterwegs ist.
 
Wenn wir mal davon ausgehen, dass wohl die wenigsten User ein eigenes Zertifikat installieren wollen bzw. können, dann macht es auch wirklich Sinn, wenn das selbst generierte Zertifikat der Box (vermutlich!) beim ersten Start mit einer neuen Firmware immer wieder neu generiert wird.
Ich meinte, daß bei mir das "benutzerdefinierte"(!) durch ein "boxgeneriertes" ersetzt wurde beim Update ... wenn ich nicht nur auf der "Probierbox" nach dem letzten Werksreset den Import vergessen habe (glaube ich aber nicht).

Wie soll denn für ONU dieses Zertifikat sonst "ab und an" erneuert werden? Oder soll AVM etwa ein dauerhaftes Zertifikat einbauen? Das wäre ja wohl auch nicht im Sinne des Erfinders.
Das wäre ein Argument, wenn nicht ohnehin als "Ablaufdatum" in einem boxgenerierten Zertifikat "max(time)" (also -1) verwendet würde (irgendwann in 23,5 Jahren).

Bei einem benutzerdefinierten Zertifikat macht das (im Moment von mir mutmaßte) Ersetzen durch ein anderes selbstgeneriertes Zertifikat beim Firmware-Update mal gar keinen Sinn, da sind wir uns sicher einig.

Aber auch bei einem "boxgenerierten" Zertifikat wird mit dem Ersetzen beim Firmware-Update der Zweck eines Zertifikats glatt verfehlt. Wenn man nach jedem Firmware-Update das "Vertrauen" neu definieren muß, ist das für mich absolut kein Unterschied zur alten Vorgehensweise, die - solange die Box das Zertifikat selbst generiert hat - bis zur vorherigen Labor-Version auch immer noch so beibehalten wurde (die heutige konnte ich noch nicht testen, es gibt noch genug andere offene Baustellen).

Da war ja dann bei der alten Art und Weise noch mehr "Kontinuität" in den Zertifikaten vorhanden, denn da wurde nur ein neues Zertifikat generiert (für HTTPS, das FTPS-Zertifikat war per Definition "volatile"), wenn sich eine Einstellung änderte, die für "Subject Alternate Name"-Werte von Bedeutung war. Das waren (wenn ich nichts vergessen habe) die My!Fritz-Anmeldung, die DynDNS-Einstellungen (da nervte es mich richtig) und der "Fritz!Box-Name". Jede Änderung an diesen Einstellungen führte (bis zur letzten Labor noch) zu einem neuen Zertifikat.

Wenn dann noch die neue Auto-Update-Funktion eine neue Firmware installiert und dabei ein neues Zertifikat generiert wird, kann man ja aus der Ferne wieder nicht sicher sein, daß man auch wirklich mit seiner eigenen Box redet, solange man kein eigenes Zertifikat verwendet.
Abgesehen davon hatte ich irgendwie die vage Hoffnung, daß AVM in nächster Zeit auch in den Smartphone- und Tablet-Apps mal dazu übergeht, Zertifikat-Änderungen nicht einfach stillschweigend zu schlucken und wenigstens 1-2x zu stutzen, wenn da eine "alte Bekannte" auf einmal mit einem neuen Zertifikat winkt. Von einem "Pairing" der Apps mit einem bestimmten Box-Zertifikat wage ich schon gar nicht mehr zu träumen ...

So haben sie das ohne erforderliche Nutzeraktionen mit den hoffentlich noch lange stattfindenden FW-Updates automatisch mit erledigt.
Wenn es nur um ein "renew" ginge, wäre das vielleicht eine Überlegung wert ... aber angesichts der "valid until"-Werte in den Zertifikaten kann das nicht der Beweggrund sein.

EDIT: Oh Mann, bis zum 16.01.2038 sind es ja schon nur noch 23,5 Jahre und nicht 26 Jahre ... die Zeit vergeht wie im Fluge. ;)
 
Zuletzt bearbeitet:
Warum nur mag das BSI in seinen Richtlinien für Softtoken eine maximale Gültigkeitsdauer von drei Jahren festlegen? ...
[Für unsere privaten Anwendungen mit dem "Geheimhaltungsgrad" "Pillepalle-privat" natürlich nicht relevant! Aber es schadet keinesfalls, darüber nachzudenken!]
Du verwirrst mich etwas ... müssten wir das nicht eigentlich AVM sagen ? Mein "Oh Mann" bezog sich mehr auf meine mangelnden algebraischen Fähigkeiten, da ich in der ersten Version die "Lebensdauer" der AVM-Zertifikate (bis 16.01.2038 - soweit reicht die 32-Bit-Unix-Zeit) noch mit "26 Jahren" angegeben hatte und es ja nur noch 23,5 sind.

Ich selbst verwende ohnehin für Client-/Server-Zertifikate nie mehr als 2 Jahre (mir graut vor Anfang August, da werden ca. 20 Server "fällig") und für S/MIME-Zertifikate allerdings fünf Jahre.

Bei Servern bin ich überwiegend selbst in der Pflicht ... aber das BSI kann ja gerne bei S/MIME mit meinen "Kunden" diskutieren. Ich bin froh, wenn ich die überhaupt zu S/MIME "überreden" kann; wenn ich da gleich am Anfang sage: "Ok, in nicht ganz drei Jahren machen wir das von vorne ...", tendiert das - ohnehin immer noch geringe - Interesse schnell gegen Null.

Fünf Jahre lassen sich - ordentliche Schlüssellängen vorausgesetzt (und auch ein ordentliches Hash-Verfahren, selbstverständlich kein MD5, SHA-1 empfiehlt das BSI ja auch nur noch bis Ende 2015 - aber mehr "aus dem Bauch heraus") - im privaten und sogar im "normalen" geschäftlichen Bereich meiner Meinung nach vertreten. Da ist das BSI in meinen Augen etwas zu vorsichtig. Und da ist mir dann sogar eine schwächer verschlüsselte Nachricht lieber als eine komplett ohne Verschlüsselung.

Ich habe auch das Recht auf eine vom BSI abweichende Meinung, ich will nicht mit/für den Bund arbeiten. Wenn ich in TR-02102-1 lese, daß ECIES-basierte Verfahren nach wie vor (letzte Änderung 02.2014) als sicher eingestuft werden und dagegen dann (leider nicht absolut eindeutige) Warnungen wie die von Bruce Schneier - mindestens vor bestimmten Kurven - setze, habe ich da auch eine andere Meinung als das BSI - zugegebenermaßen genauso nur aus dem Bauch heraus.

So, das war jetzt wieder mal komplett OT, mea maxima culpa ...
 
Zuletzt bearbeitet:
Hallo,
Ergänzend würde ich das hier noch hervorheben:
AVM Wissensdatenbank schrieb:
Wenn Sie mit verschiedenen Computern über das Internet auf die FRITZ!Box zugreifen, müssen Sie das Zertifikat auf allen Computern importieren.
 
Man sollte auch noch irgendwo dazu schreiben, daß das von der Box selbst generierte Zertifikat (das gibt es ja schon so lange, wie den HTTPS-Zugriff auf die Box an sich, neu ist nur das Interface im GUI und die Möglichkeit des Uploads eines eigenen Zertifikats) in keiner Sicherungsdatei enthalten ist.

Wer also einmal in allen verwendeten Computern ein von der Box erstelltes Zertifikat eingetragen hat, der sollte beim Zurücksetzen auf Werkseinstellungen immer berücksichtigen, daß dabei auch das Zertifikat (inkl. Key) in der FRITZ!Box gelöscht und beim ersten Neustart ein neues generiert wird. Damit geht dann das Installieren des Zertifikats in den Clients von vorne los.

Wer sich dem nicht aussetzen möchte, kann vor den Werkseinstellungen den Inhalt der Dateien /var/flash/websrv_ssl_key.pem und /var/flash/websrv_ssl_cert.pem z.B. auf einen USB-Stick sichern (die Regeln beim Zugriff auf char-Devices im TFFS beachten) und diese Dateien anschließend auch manuell wiederherstellen. Danach unmittelbar die Box neu starten, am besten durch POR, damit der ctlmgr da nicht mehr eingreifen kann.
Einfacher wäre natürlich, wenn AVM auch den Export des privaten Schlüssels (natürlich mit entsprechend sicherem Kennwort) und des Zertifikats in die export-Datei einbauen würde oder wenigstens einen entsprechenden Punkt zum Download der Dateien im GUI anbieten würde, dann gleich im passenden Format für den Import auf einer anderen Box (also key+cert in einer pem). Wie man das mit dem eventuell im Zertifikat auch enthaltenen MyFRITZ!-Namen der Box dann handhabt, ist allerdings etwas kniffliger beim Übergang auf eine andere Box.

Die gesicherten Dateien lassen sich auch nicht auf eine andere Box übertragen (die ...key.pem ist verschlüsselt mit einem boxspezifischen Kennwort), solange man das boxinterne Kennwort nicht auch ermittelt und notiert hat. Wer dabei einfach auf das vorhandene Binary 'getprivkeypass' zurückgreifen will, wird allerdings nicht wirklich erfolgreich sein ... das ist bei direktem Aufruf mehr ein Fake. Allerdings auch nur in der falschen Umgebung beim Aufruf - es soll dem ftpd den Zugriff auf den privaten Schlüssel ermöglichen und trifft alle möglichen Vorkehrungen um sich zu vergewissern, daß es auch vom Richtigen aufgerufen wurde. Den Algorithmus zur Generierung des boxeigenen Kennworts will AVM offenbar nicht direkt in den ftpd einbauen, da dessen Quelltext unter GPL steht und somit auf Anfrage ausgehändigt werden muß.

Wer also "portable" Zertifikate haben will, der sollte sie in jedem Falle vor der Konfiguration einer MyFRITZ!-Anmeldung in der Box einmal gesichert und dann als "eigene" über das GUI wieder geladen haben. An einem benutzerdefinierten Zertifikat ändert die Box von sich aus nichts mehr, egal was man an der MyFRITZ!- oder DynDNS-Konfiguration anschließend noch einstellt. Allerdings hat man dann beim Zugriff auf/über die MyFRITZ!-Adresse natürlich automatisch einen Zertifikat-Fehler (wrong site), aber das ist bei jedem "offiziellen" Zertifikat für die Box ja genauso, solange dort der MyFRITZ!-Name nicht enthalten ist.

PS: Mir fällt gerade auf, daß ich den reinen Import einer export-Datei (also ohne Werksreset davor) noch gar nicht getestet habe und somit nicht sagen kann, wie sich eine Box mit einem "Box-Zertifikat" dabei verhält. Wird dabei auch ein neues Zertifikat generiert (das wäre wegen eventuell geänderter DynDNS- und/oder MyFRITZ!-Einstellungen ja auch nicht unlogisch, ggf. nach einem Test, ob die Einstellungen wirklich geändert werden) oder bleibt das vorher vorhandene Zertifikat erhalten ? Hat das schon mal jemand getestet ? Meine 7490 hier (und nur da haben wir ja ein 06.20-Release) hat ein eigenes Zertifikat und ich kann das daher nicht ohne weiteres selbst testen.
 
Zur Sicherheit der SSL-Zertifikate:

Jede CA, die es in Browser bzw. Betriebssysteme geschafft hat, kann beliebige Zertifikate für JEDE Domain ausstellen. Viele CAs bieten sogar Intermediate-Zertifikate an, mit denen sich Firmen (oder Geheimdienste, ...) beliebige Unterzertifikate erstellen können. Intermediate-Zertifikate werden z.B. in Unternehmens-Firewalls zum Entschlüsseln des SSL-Verkehrs (mehr oder weniger legale Man-in-The-Middle-Attacke) für Deep-Packet-Inspection verwendet. Kurzum, SSL-Zertifikate sind für Verschlüsselung notwendig, bei der Authentifizierung aber für'n A....

Deshalb habe ich inzwischen auch meine privaten Domains mit DANE abgesichert (Die OpenSSL-Entwicklerversion 1.2 hat DANE-Validierung bereits integriert). Dadurch sind meine privaten Domains durch eine israelische CA (StartSSL 4096 Bit Class-2 Multidomain-Wildcard-Zertifikat) und DNSSEC der .de-Domains zweifach gesichert. Gegen einen Angreifer, der gleichzeitig eine MITM-Attacke durchführen kann, Zertifikate fälschen kann UND Zugriff auf die DNSSEC-Trust-Anchor-Keys hat (Geheimdienste) hilft DANE noch nicht, kann aber zumindest Kriminelle und Hacker abwehren.

Leider ist Core-Networks der einzige End-Nutzer-taugliche DNSSEC/DANE-Anbieter, den ich finden konnte (nach 6-wöchigem frustrierendem DNSSEC/DANE-Martyrium bei OVH). Der Haken - Core-Networks bietet kein Dynamisches DNS an. Ein CNAME auf "<UUID>.myfritz.net" unterbricht die DNSSEC-Kette. Der Geschäftsführer hat mir aber signalisiert, dass Funktionen bei entsprechender Nachfrage implementiert werden.

Wer seine Fritz!Box mit DNSSEC/DANE absichern will, bitte bei Core-Networks wegen DynDNS nachfragen!
 
7360SL mit OS 06.20

Hallo zusammen!

Ich gestehe, als ich mir das erste mal diesen Thread durchgelesen habe, habe ich (fast) nur Bahnhof verstanden. ;-)

Doch auch ich habe die "Aktion eigenes Zertifikat" in Angriff genommen und mich strikt nach Anleitung gehalten, nun habe ich in einem Ordner den Schlüssel "ssl.key" und das Zertifikat "ssl.crt" liegen, beide Dateien mit win-eigenem Editor erstellt. Das Intermediate-Zertifikat habe ich von der startssl-Seite geladen und liegt im selben Ordner.

Zwischenzeitlich hab ich dann notepad++ installiert und mit diesem die "Fritz_cert.pem" erstellt, die sieht dann so aus:
-----BEGIN CERTIFICATE-----"ssl.crt"-----END CERTIFICATE-----"Zeilenumbruch"
-----BEGIN CERTIFICATE-----"sub.class1.server.ca.pem "-----END CERTIFICATE-----"Zeilenumbruch"
-----BEGIN PRIVATE KEY-----"ssl.key"-----END PRIVATE KEY-----

Der Versuch per IE11 die Datei "Fritz_cert.pem" mit dem Key-Passwort in die 7360sl zu importieren wird mit bekannter Fehlermeldung quittiert. Habe jetzt alles drei mal gegengecheckt und komme einfach nicht weiter...

Die 7360SL wird zwar nicht explizit in der anleitung genannt, doch Umfang und Funktion dürfte doch ggü. 7390 und 7490 identisch sein, oder?

Was mir aufgefallen ist: Im Hilfetext von AVM steht unter anderem:
"[...] Das Zertifikat muss folgende Vorgaben erfüllen:
Das Zertifikat und der Private-Key müssen im PEM-Format vorliegen. [...]"

"ssl.key" <-> pem-Format?!

Jemand?
 
-----BEGIN CERTIFICATE-----"ssl.crt"-----END CERTIFICATE-----"Zeilenumbruch"
-----BEGIN CERTIFICATE-----"sub.class1.server.ca.pem "-----END CERTIFICATE-----"Zeilenumbruch"
-----BEGIN PRIVATE KEY-----"ssl.key"-----END PRIVATE KEY-----
Da hast Du gründlich etwas mißverstanden. Du sollst nicht den Namen der Datei zwischen die Begrenzer schreiben, da gehört der Inhalt der Datei hin und dann brauchst Du auch die Begrenzer nicht, weil die bereits in den Dateien stehen, wenn diese das richtige Format haben.
 
Hey, PeterPawn!

Wow, das ist mal ne schnelle Antwort! :)

Da hab ich mich besonders clever ausgedrückt! Ich habe natürlich die Daten entsprechend eingetragen, wollte aber hier sinnvollerweise nicht den Inhalt posten und habe (faulerweise) den Standard aus der Beschreibung kopiert.
Mit "die sieht dann so aus" meinte ich den Aufbau der Fritz_cert.pem, und dass sich keine Zeile oder Leerzeichen zuviel etc. reingemogelt hat. Sorry.
Wenn AVM von "Das Zertifikat und der Private-Key müssen im PEM-Format vorliegen." spricht, meinen die doch nix anderes als eben die Fritz_cert.pem, in der die beiden ja enthalten sind, richtig? Hier bin ich mir nämlich nicht sicher...
 
Wenn AVM von "Das Zertifikat und der Private-Key müssen im PEM-Format vorliegen." spricht, meinen die doch nix anderes als eben die Fritz_cert.pem, in der die beiden ja enthalten sind, richtig? Hier bin ich mir nämlich nicht sicher...
Ich bin mir auch nicht so richtig sicher, allerdings nur dessen, was Du mit der expliziten Angabe von "Zeilenumbruch" meinst.

Ein PEM-File ist normalerweise eine Base64-kodierte Repräsentation des binären Schlüssels bzw. Zertifikats.

Damit man eine Abgrenzung und eine Idee hat, was da in dem Base64-Wust steht, werden die Begrenzerzeilen verwendet. Imho ist es sogar Wurst, ob da der richtige Typ drinsteht, es kommt nur auf "BEGIN" und das passende "END" an.

Am einfachsten ist es aus meiner Sicht, die kombinierte Datei gar nicht mit irgendeinem Editor zusammenzubasteln, sondern einfach mit einem copy-Kommando. Dann vermeidet man alle Unwägbarkeiten mit Zeilenenden und Zeichensätzen.

Je nach BS ist das ziemlich simpel:

Windows:
copy file1+file2+file3 ausgabe

Linux:
cat file1 file2 file3 >ausgabe

Solange Dein privater Schlüssel ein ordentliches Kennwort hat (und eine ordentliche Verschlüsselung nutzt), könnte man ihn theoretisch sogar hier veröffentlichen, muß man aber nicht. Wenn Deine resultierende Datei wirklich folgenden Aufbau hat:

Code:
-----BEGIN CERTIFICATE-----
ABCDEFHIJKLMNOPQRSTUVWXYZ
[...]
ABCDEFHIJKLMNOPQRSTUVWXYZ
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,<Hash-Value>

01234567890
[...]
01234567890
-----END RSA PRIVATE KEY-----
sollte sie sich auch importieren lassen, ansonsten die Fehlermeldung genau angeben. Der Typ der Verschlüsselung am Beginn des private key darf auch fehlen ...
 
ist schon das richtige Stichwort. Hatte aber zwischenzeitlich alle Files nochmal mit Notepad++ erstellt bzw. deren Inhalte neu abgespeichert, und der Import funktionierte daraufhin auf Anhieb. Der Windows-Editor war wohl keine gute Wahl.

Besten Dank dennoch!

Gruß,
Tanka

P.S.: "Zeilenumbruch" deshalb, weil es so in der Anleitung steht und von mir, wie bereits verdeutlicht, per c&p übernommen wurde. ;-)
 
Hallo, ich hatt6e da auch Probleme. Richtige Reihenfolge ist anscheinend
1. Public Cert Server
2. Public Cert Ca
3. Private Key Server
 
  • Like
Reaktionen: flyingoffice
Hm irgendwie scheint die Fritzbox 7390 bei mir das Zertifikat nach einem Neustart zu verlieren. Ich nehme mal an das ist nicht beabsichtigt.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,121
Beiträge
2,246,507
Mitglieder
373,619
Neuestes Mitglied
Twann
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.