Wiki source code of STARFACE

Last modified by Sebastian Marsching on 2024/01/09 23:21
Show last authors
1 {{toc/}}
2
3 Diese Seite fasst Erfahrungen zusammen, die ich beim Einrichten unserer [STARFACE-Telefonanlage](http://www.starface.de/) sammeln konnte.
4
5 # ISDN-Rufumleitung in der Vermittlungsstelle
6
7 Normalerweise erfolgt die Umsetzung einer vom Benutzer eingerichteten Umleitung in der STARFACE-Telefonanlage, d.h. bei einer Umleitung auf eine externe Nummer wird durch die STARFACE eine Verbindung zu dieser Nummer hergestellt und auf die eingehende Verbindung geschaltet.
8
9 Diese Lösung hat zwei Nachteile:
10
11 * Am Endgerät, an das der Anruf weitergeleitet wurde, sieht man nur die Nummer der Telefonanlage und nicht die des Anrufers.
12 * Bei einem Anruf über ISDN werden zwei B-Kanäle (einer für den eingehenden und einer für den ausgehenden Anruf) benötigt.
13
14 ISDN bietet allerdings auch die Möglichkeit eine Rufumleitung in der Vermittlungsstelle zu veranlassen (CD-PR, Call Deflection Partial Routing). Dies muss die Telefonanlage allerdings entsprechend signalisieren, was bei der STARFACE in der Standard-Konfiguration nicht der Fall ist.
15
16 Ich habe deshalb ein kleines Modul geschrieben, das eine entsprechende Signalisierung übernimmt. In der aktuellen Version funktioniert das Modul allerdings nur für Umleitungen vom Typ "Immer" und "Besetzt". Umleitungen bei Zeitüberschreitungen werden aufgrund von Beschränkungen durch die für das Modul verfügbaren Funktionen weiterhin durch die Standard-Funktion der STARFACE-Anlage übernommen.
17
18 Damit das Modul korrekt funktioniert, müssen in der Konfiguration alle Leitungen eingetragen werden, für die es aktiv sein soll. Dies sind normalerweise alle externen ISDN-Leitungen. Je nach Anschlusstyp (Mehrgeräte- oder Anlagen-Anschluss) muss zwischen dem SrxDeflect- und SrxReroute-Kommandos gewählt werden (siehe [Referenz](http://www.voip-info.org/wiki/view/Asterisk+cmd+SrxDeflect)). Bei einigen Tests funktionierte SrxReroute an einem Vodafone/Arcor-Anlagenanschluss.
19
20 ## Download
21
22 Das Modul wird kostenlos zur Verfügung gestellt, entsprechend gibt es keine Gewähr für korrekte Funktionsweise und die Nutzung erfolgt auf eigene Gefahr. Es wird unter den Bedingungen der [GNU General Public License Version 3](http://www.gnu.org/licenses/lgpl.html) zur Verfügung gestellt.
23
24 * [[ISDNUmleitung_v92.sfm|attach:ISDNUmleitung_v92.sfm]] (für STARFACE ab Version 6.4.2)
25 * [[ISDNUmleitung_v91.sfm|attach:ISDNUmleitung_v91.sfm]] (für STARFACE ab Version 6.1)
26 * [[ISDNUmleitung_v89.sfm|attach:ISDNUmleitung_v89.sfm]] (für STARFACE ab Version 5.1)
27 * [[ISDNUmleitung_v88.sfm|attach:ISDNUmleitung_v88.sfm]] (für ältere STARFACE Versionen)
28
29 # QEMU Guest Agent installieren
30
31 Wenn die STARFACE als VM auf einem QEMU/KVM (z.B. mit libvirt) Host läuft, will man, dass sie heruntergefahren wird, wenn der VM-Host heruntergefahren wird. Dummerweise reagiert die STARFACE standardmäßig nicht auf ein einzelnes ACPI-Shutdown-Event, sondern braucht drei solcher Events innerhalb von 30 Sekunden, was die normalen Shutdown-Skripte von libvirt nicht unbedingt sicherstellen.
32
33 Der einfachste Weg das zu lösen ist den QEMU Guest Agent in der STARFACE-VM zu installieren (und in der VM-Konfiguration auf dem Host einen Channel für dem QEMU Guest Agent anzulegen). Dann erfolgt das Herunterfahren über den Guest-Agent statt per ACPI-Event.
34
35 Die ausführliche Anleitung für die Installation des QEMU-Guest-Agent ist bei [RedHat](https://access.redhat.com/solutions/732773) zu finden. Hier sind die wesentlichen Schritte:
36
37 ```bash
38 yum install qemu-guest-agent
39 chkconfig qemu-ga on
40 service qemu-ga start
41 ```
42
43 Sollte STARFACE irgendwann von CentOS 6 auf eine neuere Version wechseln, wären die Schritte wie folgt anzupassen:
44
45 ```bash
46 yum install qemu-guest-agent
47 systemctl start qemu-guest-agent
48 systemctl enable qemu-guest-agent
49 ```
50
51 Vom VM-Host aus, kann das Funktionieren der Verbindung mit dem Guest Agent wie folgt überprüft werden:
52
53 ```bash
54 virsh qemu-agent-command <guest-name> '{"execute":"guest-info"}'
55 ```
56
57 # TLS-Zertifikat austauschen
58
59 Das TLS-Zertifikat für Tomcat und der zugehörige private Schlüssel ist in einem Java-Keystore gespeichert.
60
61 In älteren Versionen von STARFACE befindet sich dieser unter  `/usr/share/tomcat6/ssl/tomcat.keystore`, in neureren Versionen unter `/opt/tomcat/ssl/tomcat.keystore` **und** `/var/starface/tomcat/ssl/keystore.jks`.
62
63 Das Passwort für den Keystore lautet „changeit“. Falls nicht nur ein neues Zertifikat hochgeladen werden soll (was über die Webserver-Oberfläche möglich ist), sondern auch der private Schlüssel ausgewechselt werden soll, kann diese Datei mit der Software [KeyStore Explorer](https://keystore-explorer.org/) bearbeitet werden.
64
65 KeyStore Explorer kann leider nicht mit Zertifikaten und Schlüsseln im PEM-Format umgehen. Deshalb muss zunächst eine PKCS12-Datei mit dem Schlüsselpaar (Server-Zertikat, privater Schlüssel für Server-Zertifikat, ggf. Zertifikate von Zwischenzertifizierungsstellen) erstellt werden. Dies kann mit OpenSSL erfolgen:
66
67 ```bash
68 openssl pkcs12 \
69 -in starface-cert.pem \
70 -inkey starface-privkey.pem \
71 -certfile intermediate-ca.pem \
72 -out starface.p12 \
73 -export
74 ```
75
76 Beim Export muss ein Passwort angegeben werden. Dieses Passwort muss dann erneut beim Import in KeyStore Explorer angegeben werden.
77
78 Der Eintrag muss in KeyStore Explorer unter dem Namen `tomcat` importiert werden. Ein ggf. schon vorhanderer Eintrag gleichen Namens kann ersetzt werden. Beim Import wird auch nach einem Passwort gefragt mit dem das importierte Schlüsselpaar geschützt werden soll. Dort muss das Passwort „changeit“ (das gleiche, dass auch den gesamten Key-Store schützt) angegeben werden.
79
80 Falls sich das Zertifikat der Root-CA geändert hat, muss dieses ebenfalls unter dem Eintrag `root` importiert werden. Auch hier kann ein ggf. schon vorhandener Eintrag ersetzt werden. Um ein evtl. im PEM-Format vorhandenes Zertifikat der Root-CA zu importieren, muss dieses zunächst in das DER-Format umgewandelt werden:
81
82 ```bash
83 openssl x509 \
84 -in root-ca.pem \
85 -out root-ca.cer \
86 -outform DER
87 ```
88
89 # TLS-Zertifikate mit ECDSA-Schlüsseln
90
91 Zur Zeit (STARFACE 8.1.1.1) unterstützt STARFACE keine Zertifikate mit ECDSA-Schlüsseln, d.h. es muss zwingend ein Zertifikat mit einem RSA-Schlüssel installiert werden.
92
93 Der Grund liegt nicht in der Software selbst sondern in der Tomcat-Konfiguration der STARFACE: In der `ciphers`-Liste des TLS-Connectors werden nur RSA-basierte Cipher-Suites aufgelistet. Dies führt dazu, dass bei Verwendung eines ECDSA-basierten Zertifikats keine Verbindung hergestellt werden kann. In Firefox erhält man z.B. die Fehlermeldung `SSL_ERROR_NO_CYPHER_OVERLAP`.
94
95 Ein temporärer Workaround liegt darin, sich per SSH auf der STARFACE einzuloggen und die Datei /opt/tomcat/conf/server.xml so zu bearbeiten, dass das `cipher`-Attribut des Connectors für Port 8081 zusätzlich die folgenden Cipher-Suites enthält:
96
97 * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
98 * TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
99 * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
100 * TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
101 * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
102 * TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
103 * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
104 * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
105
106 Je nach verwendetem Browser reicht wahrscheinlich auch nur die erste oder zweite Cipher-Suite.
107
108 Anschließend muss Tomcat mit `systemctl restart tomcat.service` neugestartet werden. Nach erfolgreichem Neustart kann man sich wieder in der Administrationsoberfläche anmelden und das Zertifikat durch eines ersetzen, das einen RSA-Schlüssel verwendet.
109
110 Den oben genannten Workaround dauerhaft zu verwenden empfiehlt sich eher nicht, da die hinzugefügten Cipher-Suites wieder entfernt werden, wenn STARFACE die Konfigurationsdatei neu schreibt. Dafür werden anscheinend die Templates in `/opt/tomcat/webapps/localhost/starface/WEB-INF/classes/de/vertico/starface/helpers/tomcat/https-connector-template.xml` und `/opt/tomcat/webapps/localhost/starface/WEB-INF/classes/de/vertico/starface/helpers/tomcat/provisioning-https-connector-template.xml` verwendet, d.h. man könnte prinzipiell diese Templates anpassen. Allerdings ist es sehr wahrscheinlich, dass diese Templates überschrieben werden, wenn die STARFACE-Version aktualisiert wird, d.h. eine solche Lösung würde regelmäßig manuelle Nacharbeiten erfordern. Einfach ein Zertifikat mit RSA-Schlüssel zu verwenden ist in dieser Hinsicht die einfachere Lösung. Dies funktioniert übrigens auch, wenn die übergeordnete CA selbst einen ECDSA-Schlüssel verwendet.