• Eigenständig gehostete oder lokal installierte Instanzen sind komplexer in der Einrichtung und Fehlerbehebung und erfordern daher kostenpflichtigen technischen Support. Kostenlosen Support erhalten Sie mit 3CX StartUP oder einer gehosteten 3CX-Installation mit einen unterstützten SIP-Trunk-Anbieter.

SSL Certificate erneuert

Freya

Customer
Mitglied seit
4. Februar 2023
Beiträge
2
Guten Tag,

Ich hab von meine Provider 3 Zertifikates Datei bekommen.

house-stark.de_ssl_certificate.cer
house-stark.de_ssl_certificate_INTERMEDIATE.cer
house-stark.de_private_key.key

Bei der erst Einrichtung konnte ich diese einfach Hochladen und die Installation Routine hat sich um den Rest gekümmert.

Was muss ich nun machen um die Zertifikate austauschen das der webclient und alle anderen Funktionen wieder zuverlässige mit ssl laufen?
Ich hab auch schon das nach paar Anleitung Probiert die mir aber nicht weiter geholfen.
Ich denke muss die Zertifikate Daten mit openssl konvertieren.


Mit Freundlich Grüßen

Freya
 
Hallo @Freya ,

mir ist kein Weg bekannt, das über die 3CX Verwaltungskonsole zu tun. Man kann das Secure SIP Zertifikat (Erweitert / Secure SIP) einspielen, aber nicht das des NGINX.

Wenn die Zertifikatdateien mit einem Texteditor geöffnet werden und mit ------BEGIN CERTIFICATE----- bzw. -----BEGIN PRIVATE KEY----- anfangen, dann muss da nichts konvertiert werden.

Wir rollen alle Zertifikate automatisiert aus. Die grobe Vorgehensweise für dich wäre:
  1. das Zertifikat umbennen in <fqdn>-crt.pem
  2. die Schlüsseldatei umbenennen in <fqdn>-key.pem
  3. beide Dateien in die passenden NGINX Verzeichnisse der 3CX kopieren:
    1. Debian: /var/lib/3cxpbx/Bin/nginx/conf/Instance1/
    2. Windows: C:\Program Files\3CX Phone System\Bin\nginx\conf\instance1\)
  4. gib diesen beiden Dateien in diesen Verzeichnissen den richtigen Besitzer und die Gruppe / Berechtigungen:
    1. Debian: chown phonesystem:phonesystem *.pem und chmod 644 *.pem im jew. Verzeichnis
    2. Windows: rechtsklick und Eigentümer + Vollzugriff entspr. ändern
  5. den Dienst NGINX (oder gleich die 3CX) neu starten

Evtl. diese beiden Dateien für Secure SIP bereitstellen:
  1. das Zertifikat umbenennen in domain_cert_<fqdn>.pem
  2. die Schlüsseldatei umbenennen in domain_key_<fqdn>.pem
  3. die beiden Dateien in die passenden Verzeichnisse der 3CX kopieren:
    1. Debian: /var/lib/3cxpbx/Instance1/Bin/Cert/
    2. Windows C:\Program Files\3CX Phone System\Bin\Cert\
  4. Berechtigungen wieder setzen (s.o.)
  5. den Dienst 3CXPhoneSystem01 (oder gleich die 3CX) neu starten

Unsere alte Variante mittels Letsencrypt auf der 3CX und Upload in eine vorgeschaltete Firewall (wg. Proxy mit SSL offload, das Skript lief jahrelang überall problemlos):
Bash:
#!/bin/bash
#
# ALTE VERSION: Ausstellen des Cert _auf_ der 3CX, Upload _in_ die pfSense wg. SSL offload
#
# bash Skript zur Erneuerung eines LetsEncrypt Zertifikates lokal auf einem Client (hier: unter debian mit certbot, z.B. )
# und anschl. Upload auf eine pfSense Firewall und Speichern in deren Konfiguration für z.B. squid rp oder haproxy
#
# Hinweis: es erfolgt keine Überprüfung der automatischen Verlängerung und Benachrichtigung, schlägt die Verlängerung fehl dann
#  läuft zwar das Skript aber es werden keine Zertifikate verlängert und ersetzt, das läuft halt aus
#
# Problem:
# - nur root kann auf der Firewall die Konfigurationsänderungen speichern
# - nur root kann auf der Firewall Dienste neu starten lassen
# - daher muss auf der Firewall ein separater cron Job als root laufen der das macht
#
# die Ausführung ist daher leider zweigeteilt
# Teil 1:
# - auf dem Client wird die Zertifikatverlängerung angestoßen und durchgeführt falls erforderlich
# - es wird ein php Skript für die Firewall generiert
# - das Skript und die zuvor generierten LE Zertifikate werden auf die Firewall hochgeladen
# Teil 2:
# - auf der Firewall muss ein _extra_ cron Job später laufen der das hochgeladene PHP Skript ausführt
# - dieses PHP Skript pflegt die Zertifikate ein, startet haproxy neu und löscht anschl. sich selbst
#     und die Zertifikate
#
#
# es wird auf dem Client Computer (debian) benötigt:
# - certbot, sollte schon 1x gelaufen sein, d.h. auch Port 80 ankommend und Verlängerung möglich ...
# - sshpass und es sollte schon mind. 1x eine ssh verbindung zur pfSense aufgebaut gewesen sein wg. dem ssh hostkey!
# - ein cron job: (crontab -l ; echo "0  1  *  *  * /root/letsencrypt-renew-and-upload_pbx.domain.de-pfsense.sh >/dev/null 2>&1") | crontab -
#
# es wird auf der pfSense benötigt:
# - aktiviertes ssh
# - installiertes Paket cron
# - aktivierter cron Job zur (einmal täglichen) Ausführung des Aktualisierungsskripts auf der Firewall:
#    /usr/local/bin/php -f /home/<certuser>/<fqdn>/<fqdn>.php   <- certuser name und fqdn ersetzen!
# - ein extra eingerichteter Benutzer der Gruppe der Administratoren auf der pfSense (ja, geht wohl leider nicht anders, aktuell gibt es dafür ein anderes Skript)
# - ein vorab manuell eingespieltes Zertifikat welches als Bezeichnung den Hostnamen des Zertifikates beinhaltet,
#    das wird dann nach Bedarf (wenn eine LE Verlängerung ansteht) immer mal ausgetauscht
#
# Suchstichworte: pfsense haproxy letsencrypt upload automatisch skript script shell bash debian sshpass 3cx pbx
#
# (temp.?) Anpassen der 3CX v18 Debian 10 Sourcen für die Installation von certbot und sshpass unter /etc/apt/sources.list:
# deb http://deb.debian.org/debian buster main
# deb-src http://deb.debian.org/debian buster main
#
# deb http://security.debian.org/debian-security buster/updates main
# deb-src http://security.debian.org/debian-security buster/updates main
#
# apt -y update && apt -y install certbot sshpass
#
# Suchstichworte: pfsense haproxy letsencrypt upload automatisch skript script shell bash debian
#
# Portweiterleitung vorab evtl. testen mit simplen http server:
#   python3 -m http.server 80
#

_pfsenseip="192.168.10.10"                      # die IP der pfSense mit haproxy
_pfsenseport="61322"                            # der SSH Port der pfSense mit haproxy
_pfusername="sshuser"                           # der auf der pfSense extra angelegte Benutzer
_pfpassword="passwortsuperstrenggeheim"         # das Passwort des auf der pfSense extra angelegten Benutzers
_fqdn=$(hostname -f)                            # der FQDN des Letsenrypt Zertifikates, ist auch genau so unter diesem Namen in der pfSense drin
_certemail="[email protected]"     # das zur Verlängerung des Leytsencrypt Zertifikates benutzte E-Mail Konto
_doupdate=$false

_oldcerthash=$(cat /etc/letsencrypt/live/$_fqdn/fullchain.pem | md5sum)
_oldkeyhash=$(cat /etc/letsencrypt/live/$_fqdn/privkey.pem | md5sum)

# ab hier erfolgt die Zertifikatverlängerung mittels certbot, standalone, ohne Webserver Integration
#
# wichtig: der Port 80 muss frei sein und es muss eine Port- und Domainweiterleitung zu diesem Host existieren
#
certbot certonly --standalone -d "$_fqdn" --rsa-key-size 4096 --email "$_certemail" --agree-tos -n

_actcerthash=$(cat /etc/letsencrypt/live/$_fqdn/fullchain.pem | md5sum)
_actkeyhash=$(cat /etc/letsencrypt/live/$_fqdn/privkey.pem | md5sum)
_tcxcerthash=$(cat /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-crt.pem | md5sum)
_tcxkeyhash=$(cat /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-key.pem | md5sum)
_sipcerthash=$(cat /var/lib/3cxpbx/Instance1/Bin/Cert/domain_cert_$_fqdn.pem | md5sum)
_sipkeyhash=$(cat /var/lib/3cxpbx/Instance1/Bin/Cert/domain_key_$_fqdn.pem | md5sum)

if [[ ($_oldcerthash != $_actcerthash) || ($_tcxcerthash != $_actcerthash) || ($_sipcerthash != $_actcerthash) || ($_oldkeyhash != $_actkeyhash) || ($_tcxkeyhash != $_actkeyhash) || ($_sipkeyhash != $_actkeyhash) ]]; then
    rm /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-crt.pem
    rm /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-key.pem
    cp /etc/letsencrypt/live/$_fqdn/fullchain.pem /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-crt.pem # nicht cert.pem ?!?
    cp /etc/letsencrypt/live/$_fqdn/privkey.pem /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-key.pem
    chown phonesystem:phonesystem /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-crt.pem
    chown phonesystem:phonesystem /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-key.pem
    chmod 644 /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-crt.pem
    chmod 644 /var/lib/3cxpbx/Bin/nginx/conf/Instance1/$_fqdn-key.pem

    /etc/init.d/nginx reload

    rm /var/lib/3cxpbx/Instance1/Bin/Cert/domain_cert_$_fqdn.pem
    rm /var/lib/3cxpbx/Instance1/Bin/Cert/domain_key_$_fqdn.pem
    cp /etc/letsencrypt/live/$_fqdn/fullchain.pem /var/lib/3cxpbx/Instance1/Bin/Cert/domain_cert_$_fqdn.pem
    cp /etc/letsencrypt/live/$_fqdn/privkey.pem /var/lib/3cxpbx/Instance1/Bin/Cert/domain_key_$_fqdn.pem
    chown phonesystem:phonesystem /var/lib/3cxpbx/Instance1/Bin/Cert/domain_cert_$_fqdn.pem
    chown phonesystem:phonesystem /var/lib/3cxpbx/Instance1/Bin/Cert/domain_key_$_fqdn.pem
    chmod 644 /var/lib/3cxpbx/Instance1/Bin/Cert/domain_cert_$_fqdn.pem
    chmod 644 /var/lib/3cxpbx/Instance1/Bin/Cert/domain_key_$_fqdn.pem

    systemctl stop 3CXPhoneSystem01
    _services=$(systemctl list-unit-files --state=enabled |grep -i 3cx |awk '{printf "%s\n", $1}')
    for _service in $_services; do systemctl is-active --quiet $_service || systemctl start $_service; done
    _doupdate=$true

cat << EOF > ~/$_fqdn.php
<?php
require_once("certs.inc");
require_once("pfsense-utils.inc");

\$a_cert = &\$config['cert'];

\$fname=pathinfo(__FILE__, PATHINFO_FILENAME);

for (\$ii=0; \$ii < count(\$a_cert); \$ii++) {
    if (\$a_cert[\$ii]['descr'] == \$fname) {
        \$fcinh=file_get_contents("/home/$_pfusername/\$fname/\$fname.pem");
        \$fkinh=file_get_contents("/home/$_pfusername/\$fname/\$fname.key");
        \$a_cert[\$ii]['crt']=base64_encode(\$fcinh);
        \$a_cert[\$ii]['prv']=base64_encode(\$fkinh);
    }
}
write_config("Zertifikat \$fname wurde aktualisiert");
parse_config(true);
shell_exec("/usr/local/etc/rc.d/haproxy.sh restart");
?>
EOF

    # evtl. noch div. lokale Services auf dem Client mit dem neuen Zertifikat versorgen und diese anschl. neu starten laasen
 
    # ssh-keygen -f ~/.ssh/known_hosts -R $_pfsenseip
    # ssh-keyscan -H $_pfsenseip >> ~/.ssh/known_hosts
 
    sshpass -p $_pfpassword ssh -p $_pfsenseport -o StrictHostKeyChecking=no $_pfusername@$_pfsenseip rm -r -f /home/$_pfusername/$_fqdn
    sshpass -p $_pfpassword ssh -p $_pfsenseport -o StrictHostKeyChecking=no $_pfusername@$_pfsenseip mkdir /home/$_pfusername/$_fqdn
    sshpass -p $_pfpassword ssh -p $_pfsenseport -o StrictHostKeyChecking=no $_pfusername@$_pfsenseip chmod -R 700 /home/$_pfusername/$_fqdn
    sshpass -p $_pfpassword scp -P $_pfsenseport /etc/letsencrypt/live/$_fqdn/fullchain.pem $_pfusername@$_pfsenseip:/home/$_pfusername/$_fqdn/$_fqdn.pem
    sshpass -p $_pfpassword scp -P $_pfsenseport /etc/letsencrypt/live/$_fqdn/privkey.pem $_pfusername@$_pfsenseip:/home/$_pfusername/$_fqdn/$_fqdn.key
    sshpass -p $_pfpassword scp -P $_pfsenseport ~/$_fqdn.php $_pfusername@$_pfsenseip:/home/$_pfusername/$_fqdn/$_fqdn.php
    # sshpass -p $_pfpassword scp -P $_pfsenseport  ~/$_fqdn.sh $_pfusername@$_pfsenseip:/home/$_pfusername/$_fqdn/$_fqdn.sh
fi
rm -f ~/$_fqdn.php

exit 1


# Reste:

# zugriff unter php / psSsh auf die config
print_r($config['cert']['4']['crt']);
exec;
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Ben04
Danke für die Hilfe hat geklappt nach den ich raus gefunden hab welche Fehler ich gemacht hab.
 
Ich habe versucht der Anleitung von fxbastler zu befolgen, jedoch ist bei mir etwas schief gelaufen und nun ist die 3CX nicht mehr erreichbar... Ich komme aber via Putty & Filezilla aufs Debian drauf und die Backup Zertfikate bringen auch leider nichts. Hatte versucht gehabt, das Intermediate Zertifikat einzubringen, da dies gefehlt hat für den reibungslosen Ablauf.

Ich habe folgende Dateien:
x.de_private_key.key
x.de_private_key.pfx
x.de_ssl_certificate.cer
x.de_ssl_certificate_INTERMEDIATE.cer

die müssen in <fqdn>-crt.pem und <fqdn>-key.pem umbenannt werden, richtig ?
Für folgendes Verzeichnis: /var/lib/3cxpbx/Bin/nginx/conf/Instance1/

Und müssen dann die selben nochmal umbenannt werden, für den Part 2 ?
Achso und die Rechte habe ich schon gemacht nach dem versuchten zurückspielen.
 
Ich habe versucht der Anleitung von @fxbastler zu befolgen, jedoch ist bei mir etwas schief gelaufen und nun ist die 3CX nicht mehr erreichbar
Hast du ein LetsEncrypt Zertifikat, was du in die 3CX einbringen willst?
 
Ist es öffentlich akkreditiert? Wenn ja: wer ist der Herausgeber und wer unterschreibt mit?
 
Ehm, ich habe absolut keine Ahnung o_O Kann ich das aus den Dateien herausfinden ?
Es lief ja mit dem Zertifikat, was nur fehlte war das x.de_ssl_certificate_INTERMEDIATE.cer, um das Zerfikat sicher zu machen.
 
Wenn das eine Base64 Kodierung ist, dann kann man die einfach kopieren, ist ja nur Text. Es sollte halt alles die gleiche Kodierung haben (unter Linux sinnvollerweise UTF8 und nur LF ohne CR). Wegen der Reihenfolge siehe in der RFC4346:
Dies ist eine Sequenz (Kette) von X.509v3-Zertifikaten. Das Zertifikat des Absenders muss in der Liste an erster Stelle stehen. Jedes folgende Zertifikat muss das vorhergehende Zertifikat direkt bescheinigen. .....
Also erst das Cert, dann evtl. nachfolgende aufeinander aufbauende Intermediate.

Dennoch die Frage: Ist das Zertifikat öffentlich akkreditiert? Öffne die pem bzw. die zusammengesetzte Datei mit einem Validierer. Wenn die Datei unter Windows in .crt umbenannt wird, kann man die mit einem Browser öffnen und dort sehen woher das Zertifikat kommt, für was das gut ist usw..

Alles andere mit div. Online Tools oder mit den openssl tools auf der Kommandozeile.
 
Ist es öffentlich akkreditiert? Wenn ja: wer ist der Herausgeber und wer unterschreibt mit?
Infos aus dem Zerfikat7Details:
CN = GeoTrust TLS RSA CA G1
OU = www.digicert.com
O = DigiCert Inc
C = US
////
CN = DigiCert Global Root G2
OU = www.digicert.com
O = DigiCert Inc
C = US

Also erst das Cert, dann evtl. nachfolgende aufeinander aufbauende Intermediate.
Die Hashwerte in einer Datei untereinander zusammen setzen oder was ? Blick da leider überhaupt nicht durch und versteh nur ein Bruchteil. :/
 
Das sind pem Dateien, das ist reiner Text.
Die Hashwerte in einer Datei untereinander zusammen setzen oder was ?
Prinzipiell ja. Dann benenne das Ergebnis testweise in .crt um und öffne das. Schon da wirst du sehen, ob das grundsätzlich funktionieren kann.
 
Also er zeigt mir in dem Zerti. Pfad die 3 Ebenen an, also wird es wohl so richtig sein oder ? Das jetzt richtig umbenennen für die 3cx und dann weiter schauen. Rückmeldung gibt's wahrscheinlich spätestens morgen.
 
Rückmeldung:
Nachdem ich gestern alles mögliche versucht habe mit den Zertifikaten, habe ich über das experimentieren via dem clean Befehl im Linux die Anlage mehrmals neu gemacht. nach langen Experimentieren, konnte ich die Anlage mit der alten Setup Config dafür wieder herstellen und hat das "Erweiterte" Zertifikat ohne zu meckern geschluckt.

Via SSH Terminal (FileZilla) das alte Backup eingespielt, welches ich via FileZilla in den Pfad reinkopiert habe.
Im Backup habe ich die Zertifikate als Dateien gelöscht habe und beim einspielen des Backups, hat er das ganze geschluckt.

Was mir bei der Nachkontrolle aufgefallen ist:
Im Pfad "/var/lib/3cxpbx/Instance1/Bin/Cert/" exisiteren keine Zertfikate. Packt die 3CX da diese nicht hinein von selbst, beim first touch mit dem Zertifikat ?

Mein Problem:
SBC via Linux will sich nicht verbinden. Findet angeblich beim eingeben des Keys, den Server nicht.
Wie bekomme ich nun raus, wo das Problem begraben liegt ? Windows Installationen können die Verbindung ja aufbauen.
 
@fxbastler evtl. kannst du mir ja eine einleuchtung bringen.
Wenn ich auf https://ssl.de/ssl-check.html den FQDN Name Prüfe, sagt er mir,

Fehler: Ungültige SSL , nicht gleiche zu Name ZertifikatWenn ich aber die Hashwerte von dem Zertifikat nehme, sei es die 2 Einzeln oder zusammen, dann sagt er, es ist alles sicher und richtig.

Unser Zertifikat läuft auf *.FIRMA.de, FIRMA.de.
Kann es daher kommen, dass es mit dem SBC nicht klappt, weil der FQDN nicht richtig zertifiziert ist ?
 
Im Pfad "/var/lib/3cxpbx/Instance1/Bin/Cert/" exisiteren keine Zertfikate. Packt die 3CX da diese nicht hinein von selbst, beim first touch mit dem Zertifikat ?
Dort liegt das Zertifikat und der Key für Secure SIP, welches auch für div. andere Interna genutzt wird. Antwort auf die Frage: nein.

Unser Zertifikat läuft auf *.FIRMA.de, FIRMA.de.
Das ist das Problem: das ist ein wildcard Zertifikat. Damit wird das grundsätzlich nicht funktionieren soweit ich weiß. Browser haben damit im Allgemeinen keine Probleme, viele andere Gegenstellen schon.
 
Das ist das Problem: das ist ein wildcard Zertifikat. Damit wird das grundsätzlich nicht funktionieren soweit ich weiß. Browser haben damit im Allgemeinen keine Probleme, viele andere Gegenstellen schon.

Haben wir gestern auch schon fast geahnt, dass es wohl das sein wird. Dann brauch ich mich ja mit dem jetzigen Zertifikat nicht weiter auseinander setzen und experimentieren, wenn es eh nicht geht. Danke dir (mal wieder) :)
 
  • Like
Reaktionen: fxbastler
Das ist das Problem: das ist ein wildcard Zertifikat. Damit wird das grundsätzlich nicht funktionieren soweit ich weiß. Browser haben damit im Allgemeinen keine Probleme, viele andere Gegenstellen schon.
Es hat doch geklappt, haben es gerade nochmal probiert, nun zeigt er bei https://ssl.de/ssl-check.html den FQDN in Grün an. Also hat er nur seine Zeit gebraucht um das übergeordnete Zerti zu erkennen. SBC und Router Telefon lassen sich nun Provisionieren.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
21.359
Beiträge
107.421
Mitglieder
70.518
Neuestes Mitglied
jeanmarieguillaume392@gma
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 register cta
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.