Hallo,
jetzt kommt eine Textwand.
Die klare Antwort: nein. Man kann einen Reverse Proxy (haproxy oder wie Sophos es benennt: WAF) immer nutzen.
Im SNI Betrieb braucht der prinzipbedingt gar keine Zertifikate. Im Offload Betrieb gibt man dem halt die Zertifikate welche die 3CX schon hat (weil die Firma 3CX die bei LE holt und der 3CX Installation bereitstellt).
So ein LE Zertifikat besteht grundsätzlich aus zwei Dateien: dem Zertifikat und dem privaten Schlüssel dazu. Das Zertifikat selber nutzt einem wenig da die Kette der Zerfikataussteller / Zwischenzerfizierungsstellen zum Überprüfen für einen Client auch immer mit angegeben werden muss. Das kann eine dritte Datei sein, ist es meist nicht, das baut man i.d.R. immer mit in die Zertifikatdatei ein. Wenn Zertifikate von LE kommen nennt diese Datei sich
fullchain.pem: die enthält alle Zwischenzertifizierungsstellen und auch das eigentliche Zertifikat.
In einer Debian 3CX liegen diese beiden Dateien unter
/var/lib/3cxpbx/Bin/nginx/conf/Instance1/ (für den Webserver, die Website, die Provisionierung usw) und auch noch einal unter
/var/lib/3cxpbx/Instance1/Bin/Cert/ (für die VOIP Verschlüsselung, SRTP). Die fullchain als
<fqdn>-crt.pem bzw.
domain_cert_<fqdn>.pem und der private Schlüssel als
<fqdn>-key.pem bzw.
domain_key_<fqdn>.pem.
Tauscht man die Dateien des Webservers einer 3CX aus so muss dieser neu geladen werden (
/etc/init.d/nginx reload). Tauscht man die Dateien des 3CX System einer 3CX aus so muss der Dienst
3CXPhoneSystem01 neu gestartet werden und alle anderen davon abhängigen 3CX Dienst hinterher auch:
Bash:
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
Wie kommen nun diese fremd erstellten Zertifikate in eine pfSense? Wir lassen täglich einen cron Job laufen welcher die Zertifikate vergleicht, ggf. verlängert, was auch immer. Wenn sich da etwas ändert dann werden diese entweder mit einem wenig privilegierten Benutzeraccount auf die pfSense hochgeladen (Variante 1, per ssh, expect ist dein Freund) oder die pfSense holt die sich selber (Variante2, auch hier: ssh und expect) weil dort auch ein entspr. cron Job mit einem PHP Skript läuft. In der pfSense gibt es immer ein (Fremd)zertifikat welches der haproxy nutzt. Das hat den Namen des FQDN der 3CX. Das wird durch das cron PHP Skript auf der pfSense ersetzt wenn es sein muss, hier ein Beipiel für das PHP Skript einer pfSense für Variante 1:
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");
?>
Das klingt alles kompliziert, liest sich chaotisch, ist es gar nicht. Das richtet man einmal ein und dann läuft das automatisch und perfekt. Wir haben selbst für die Einrichtung Skripte geschrieben welche das automatisch machen
