Nach umstellung auf V20 bekomme ich Fehler der Zertifizierungsstelle: ID (429)

vollweise

SOHO User
Mitglied seit
20. Dezember 2016
Beiträge
21
Ich habe die Umstellung auf V20 unter windows gemacht hatte einige PRobleme mit SPlit DNS und mit den Ports

nach mehreren neuinstallationen (wegen Port änderungen....) bekomme ich jetzt die meldung

Fehler der Zertifizierungsstelle: ID (429) - Ich habe durch die neuinstallation das abrufen der Zertifikate überschritten

und soll warten bis diese wieder Frei gegeben sind - nun kann ich leider nichts mehr machen

hat jemand eine Ahnung wie lange die freigabe der ZErtifikate dauert? weil ohne dem kann ich ja die vorhandene Datensicherung nicht einspielem
 
  1. setze den 3CX Parameter TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED auf 1
  2. starte auf einer Kommandozeile der 3CX den Befehl
    /usr/lib/3cxpbx/PbxConfigTool -renew-certificates
  3. starte die 3CX neu
 
Da bleibt nur warten bis LE das wieder erlaubt... meine das waren 5 Tage.
 
na klar, das geht, mklink sei Dank :D

Aber ja, einfacher ist es, man startet das gleich unter Windows mit
"C:\Program Files\3CX Phone System\Bin\PbxConfigTool.exe" --renew-certificates
 
na klar, das geht, mklink sei Dank :D

Aber ja, einfacher ist es, man startet das gleich unter Windows mit
"C:\Program Files\3CX Phone System\Bin\PbxConfigTool.exe" --renew-certificates
Und damit umgeht man die Sperre bei LE?
 
Es ist die Frage, woher der Fehler wirklich kommt. Einen Versuch ist es wert. Die Sperre greift i.d.R. bei mehreren Fehlaufrufen so schnell. Bei erfolgreichen wiederholten LE Abrufen ist das Limit höher.
 
  • Like
  • Haha
Reaktionen: bitn2 und fxbastler
So wie ich das lese, hat der TE kein eigenes Zertifikat für seine installierte 3CX sondern eines von der Firma 3CX für einen von denen verwalteten FQDN.

Das heißt: die Firma 3CX hält alle FQDN, fragt dort selber bei LE an und bekommt immer ein Zertifikat. Die Firma 3CX dürfte für so einen Vorgang nie in die Sperre laufen. Die installierte 3CX bekommt das dann von der Firma 3CX abgerufene LE Zertifikat. Das ist es, was du damit auslöst.
 
Das war mir nicht so ganz klar... Normalerweise fragt doch die 3cx bei LE an und LE prüft ob der FQDN erreichbar ist bzw per DNS Challenge... Wenn das zu oft fehl schlägt wird man bei LE gesperrt für eine gewisse Zeit. So kenne ich das zumindest bei eigenen FQDN die per LE ein Zertifikat bekommen. Ist das bei einem 3CX FQDN anders?
 
Ja, wenn man das selber anfragt, weil einem die Domain gehört. In den von 3CX gestellten FQDN gehört einem aber nicht die Domain und daher auch nicht die Subdomains und man hat keine Kontrolle über deren DNS.

Ich gebe zu, ich habe mich mit dem Mechanismus so wie ihn 3CX benutzt nie wirklich beschäftigt, da - bis auf einige wenige Testinstallationen - alle unsere Anlagen einen eigenen FQDN der eigenen Domain mit eigener Zertifikatverteilung nutzen.

Hier die Textwand.

Vereinfacht gesagt: um ein LE Zertifikat für einen FQDN zu bekommen, muss man nachweisen, dass einem die Domain gehört bzw. man eine gewisse Kontrolle darüber hat. Es gibt aktuell grundsätzlich zwei Mechanismen diese Kontrolle nachzuweisen: für einen kurzen Moment eine gelieferte Datei per HTTP in einem speziellen Unterverzeichnis unterhalb des FQDN für beliebige Anfrager aus aller Welt bereitzustellen oder einen bestimmten TXT Record im DNS Server der Domain des FQDN bereitzustellen. Beides bedingt, dass dem LE Cert Anfrager die Domain oder die Kontrolle darüber gehören muss.

Variante eins scheidet bei 3CX aus: der von der Firma 3CX gestellte FQDN verweist immer auf die eigene IP der installierten 3CX und die eigene 3CX liefert i.d.R. nichts an Port 80 TCP. Der HTTP Port einer 3CX kann frei gewählt werden, ist standardmäßig Port 5000 und wird generell nicht für Anfragen aus dem Internet geöffnet.

Variante 2 könnte heißen: die eigene 3CX PBX fragt bei LE nach einem Zertifikat an, der zu stellende TXT Record Eintrag im DNS Server wird von LE der eigenen 3CX übergeben, die eigene 3CX PBX fragt bei der Firma 3CX (die den DNS Server dieser Domain kontrolliert) um Eintragung dieses TXT Record an, die Firma 3CX modifiziert diesen TXT Record in ihrem DNS Server, gibt der eigenen anfragenden 3CX PBX Bescheid dass das getan wurde, die eigene 3CX PBX gibt LE Bescheid dass der TXT Record bereitsteht, die LE Zertifizierungsstelle fragt den TXT Record des DNS Server ab und befindet den für gültig, LE gibt der eigenen 3CX PBX daraufhin das Zertifikat und diese pflegt das bei sich für den Nginx und SIPS ein.

Alternative Variante 2: die Anfrage nach LE Verlängerung geht von der eigenen 3CX PBX bei der Firma 3CX ein, die Firma 3CX fragt bei LE nach Bereitstellung eines DNS Eintrages an, der Inhalt wird ausgehandelt, die Firma 3CX (welche den DNS Server ihrer eigenen Domains und Subdomains kontrolliert) setzt den gewünschten TXT Record im von ihr kontrollierten DNS Server, gibt LE Bescheid dass der gesetzt ist, LE kontrolliert das und gibt dem Anfrager (der Firma 3CX) das Zertifikat. Die Firma 3CX gibt das Zertifikat wiederum der eigenen 3CX PBX die das bei sich einpflegt (Nginx und SIPS). Der Vorgang der Variante zwei ist ein klein wenig komplexer und dauert ein klein wenig länger.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: mbehrens und bitn2

Statistik des Forums

Themen
44.414
Beiträge
232.715
Mitglieder
78.328
Neuestes Mitglied
as7h