Verlängerung des SSL-Zertifikats fehlgeschlagen

[VGW]

Die Verlängerung des SSL-Zertifikats ist fehlgeschlgen,
Ausgehende Ports sind frei.
Installation ist auf Windows.
TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED wurde auch schon auf 1 gesetzt.
Leider immer noch keine Verlängerung.

 

[bitn2]

Die Verlängerung des SSL-Zertifikats ist fehlgeschlgen,
Ausgehende Ports sind frei.
Installation ist auf Windows.
TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED wurde auch schon auf 1 gesetzt.
Leider immer noch keine Verlängerung.

Der parameter allein reicht auch nicht, du musst es über die Konsole verlängern.

setze unter Einstellungen ->Parameter
TEMPORARY_SELF_SIGNED_CERTIFICATE_GENERATED wert auf 1

Falls Windows:
Über CMD(administrator)
folgenden Befehl Ausführen:

"C:\Program Files\3CX Phone System\Bin\PbxConfigTool.exe" -renew-certificates

Falls Linux:

Login SSH als root
- su phonesystem
- sr/lib/3cxpbx/PbxConfigTool -renew-certificates

Warte ca. 5 Minuten.

Evtl. musst du den nginx neu starten.
service nginx restart

 

[VGW]

Nun das habe ich auch schon probiert.
CMD als admin. Den Pfad findet er nicht Program Files.
Änderung auf Programme da dort die exe liegt schlägt auch fehl: Zugriff Verweigert obwohl auch als Admin auf dem System angemeldet.
nginx gestoppt, gleiches Problem: Zugriff verweigert.
Auch ein Neustart des ganzen System bracht nichts mit dem Parameter 1.

 

[bitn2]

Dann läuft bei dir noch was ganz anderes falsch... Den Pfad gibt es natürlich. Aber wenn du selbst als Admin keine Berechtigungen hast, dann hast du dir da noch was ganz anderes zerschossen.

Um was für ein Betriebssystem handelt es sich denn?

 

[VGW]

Zerschossen ist gut
Das Zertifikat wurde immer aktualisiert, an dem System wurde nichts geändert, plötzlich läuft die aktualisierung nicht mehr?
Das einzige was sein könnte das wir unsere Firewall getauscht haben.
An den Ports liegt es nicht die sind alle entsprechend eingetragen.
Einzige Möglichkeit wäre auf der Firewall das Malware Detection.
Habe nun mal unser FQDN dort in die White List eingetragen.
Frage wäre welche Adresse verwendet wird (nicht unser FQDN sonder die Kontakt Gegenstelle) um das Zertifikat zu verlängern.

Nachtrag:
konnte nun das Tool aufrufen (" " war der Fehler für den Zugriff) doch weiterhin konnte das Zertifikat nicht verlängert werden.

 

[bitn2]

Zerschossen ist gut
Das Zertifikat wurde immer aktualisiert, an dem System wurde nichts geändert, plötzlich läuft die aktualisierung nicht mehr?
Das einzige was sein könnte das wir unsere Firewall getauscht haben.
An den Ports liegt es nicht die sind alle entsprechend eingetragen.
Einzige Möglichkeit wäre auf der Firewall das Malware Detection.
Habe nun mal unser FQDN dort in die White List eingetragen.
Frage wäre welche Adresse verwendet wird (nicht unser FQDN sonder die Kontakt Gegenstelle) um das Zertifikat zu verlängern.

"Nur die Firewall..." na das kann schon der Grund sein. Was sagt denn der Firewallcheck der 3cx? Die Gegenseite ist Lets Encrypt. Die 3cx sollte grundsätzlich als Ausnahme in solchen Tools der Firewall eingetragen sein.

Wenn du keine Zugriffsrechte auf Dienste oder Ordner/Dateien hast, dann hast du wie gesagt noch ein anderes Problem.

 

[fxbastler]

Das was @bitn2 zur Verlängerung des Zertifkates geschrieben hat funktioniert. Unter Debian kann das gern als root ausgeführt werden, es muss nicht der user phonesystem sein, es gibt sonst evtl. Probleme mit den Berechtigungen.

Die Verlängerung dauert 2-3 Minuten, praktisch nie länger. Das sieht man auch am Zeitstempel der Dateien unter
C:\ProgramData\3CX\Instance1\Bin\Cert\domain_<cert|key>_<3CXFQDN>.pem
bzw. unter Linux unter
/var/lib/3cxpbx/Instance1/Bin/Cert/domain_<cert|key>_<3CXFQDN>.pem .

Wichtig ist: Wenn die Verlängerung zu häufig in einem gewissen Zeitraum versucht wird, dann greift bei Lets Encrypt eine Sperre. Dann darf man 7 Tage warten bis diese automatisch aufgehoben wird. Eher bekommt man auf diesen FQDN von LE kein neues Zertifikat. Daran führt kein Weg vorbei, siehe LE Rate Limits. Also Vorsicht.

Habe nun mal unser FQDN dort in die White List eingetragen.

Ich weiß nicht welche Firewall verwendet wird und wo du das eingetragen hast. Es wäre insbes. für dich hilfreich, wenn du uns das hier schreibst: Hersteller, Modell, Firmware usw..
Das was du da gemacht hast wird vmtl. nicht reichen. Benötigte erreichbare Ziele (die FQDN von der Firma 3CX zu denen sich deine 3CX verbinden will, u.a. auch wg. LE Verlängerung), Protokolle und Ports sind hier gelistet:
https://www.3cx.de/docs/adminhandbuch/firewall-router-konfiguration/
https://www.3cx.com/docs/manual/firewall-router-configuration/
Wenn man den Verkehr der 3CX während der LE Verlängerung mitschneidet, dann sieht man das sehr gut im Wireshark wo die 3CX hin will:
ssl.handshake.extension.type == 0 als Filter zeigt activate.3cx.com und anschl. smtp-proxy.3cx.net beim Versand der E-Mail über die erfolgte Verlängerung des Zertifikates.

Schau bitte bei den 3CX Firewall Anleitungen auch nach, ob es nicht schon eine passende Anleitung für die von dir verwendete Firewall gibt.

Merke:
Der 3CX Firewall Test ist wichtig und sollte einmal komplett mit grün durchlaufen. Die weitergeleiteten SIP und RTP Ports (und nur diese) der 3CX sollte man später auf die Netzwerke des Provider begrenzen. Man kann diese Weiterleitungen auch - wenn nicht notwendig, entspr. Wissen vorausgesetzt - später deaktivieren.

Merke auch:
Der 3CX Firewall Test prüft ausschließlich UDP Verbindungen. Die Zertifikatverlängerung u.v.a.m. findet per TCP über die Server der Firma 3CX statt, siehe Link oben. Das kann damit also nicht getestet werden.

 

[VGW]

Hallo,
also exposed host ist eingerichtet, die Ports auf der Meraki freigeschaltet und forwarding zur 3cx.
Ausgehend alles frei.
Der Firewall Check sagt zwar was anderes aber das capchern ergab das alles ok ist, alles funktioniert.
Ein- und Ausgehende Gespräche und auch die App hat Verbindung also funktioniert auch der FQDN von draußen.
Aktualisierung des Lizenzkeys funktioniert.

Hier scheint es eher ausserhalb zu liegen....??
License Key and FQDN mismatch The license key and FQDN are not linked
.
Lediglich ssl renew geht nicht.


Gruß
Jörg

 

[bitn2]

License Key and FQDN mismatch The license key and FQDN are not linked

Oha.. Dann bitte im Portal prüfen ob der FQDN noch mit der Lizenz verknüpft ist und die Firewall Einstellungen korrigieren. Wie du ja siehst ist nicht alles ok.

 

[VGW]

Die Systeme im Portal hatte ich am Anfang auch schon geprüft.
Dieses ist dort sauber hinterlegt, aufrufbar und der richtige Key auch hinterlegt.

 

[bitn2]

Die Systeme im Portal hatte ich am Anfang auch schon geprüft.
Dieses ist dort sauber hinterlegt, aufrufbar und der richtige Key auch hinterlegt.

Das heisst der FQDN ist mit der richtigen Lizenz im Portal verknüpft? Dann bitte die Firewall Einstellungen korrigieren und dann noch mal versuchen.

 

[VGW]

was kann ich denn noch korrigieren?
Ports sind freigegeben, Ports sind weiter geleitet.
Ausgehend alles Frei.
Malware Detection, Intrusion Detection war dafür extra deaktiviert.
Ein Meraki Support war auf der MX drauf und hat den Netzwerkverkehr geprüft. Es wird nichts geblockt was der Firewall Checker anzeigt.

 

[VGW]

• Multiple port forwarding rules in place for this device. We checked: TCP 5090, TCP 5060, 443 All ports were open and we can see bi-directional traffic.
• We can also see the client sending out hellos to the server- cert, key exchanges , but ultimately we get an RST packet from the server.

 

[bitn2]

Die Ports dürfen nicht verändert werden ein wie ausgehend muss das der selbe Port sein und das ist bei dir nicht der Fall. Gibt es noch einen Proxy? Da darf die 3cx auch nicht drin sein.

 

[bitn2]

Hier noch mal ein Link: https://www.3cx.com/docs/cisco-meraki-firewall/

 

[fxbastler]

Meraki

Ja, genau damit (Full Cone NAT und Meraki) haben andere auch so ihre Probleme, siehe z.B.
https://www.3cx.com/community/threads/please-help-i´m-ended-with-my-knowledge-mapping-does-not-match-mapping-is.130603/
hier geht's in deutsch weiter:
https://www.3cx.de/forum/threads/bitte-um-hilfe-irgendwie-am-ende-mit-meinem-latein-mapping-does-not-match-mapping-is.121581/
...

Die gleichen Probleme, tlw. die gleichen Bildschirmfotos wie das von dir, keine Lösung.
Andere hatten da noch andere Einstellungen wie z.B. multiple WAN Anbindung, Site2Site Verbindungen (mit den gleichen Ports und Weiterleitungen) oder GeoIP Blocking. Aber das Problem des SNAT blieb auch danach bestehen soweit ich noch weiß.