• ISDN-Rufumleitung in der Vermittlungsstelle
  • Download
• QEMU Guest Agent installieren
• TLS-Zertifikat austauschen
• TLS-Zertifikate mit ECDSA-Schlüsseln

Diese Seite fasst Erfahrungen zusammen, die ich beim Einrichten unserer STARFACE-Telefonanlage sammeln konnte.

ISDN-Rufumleitung in der Vermittlungsstelle

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.

Diese Lösung hat zwei Nachteile:

• Am Endgerät, an das der Anruf weitergeleitet wurde, sieht man nur die Nummer der Telefonanlage und nicht die des Anrufers.
• Bei einem Anruf über ISDN werden zwei B-Kanäle (einer für den eingehenden und einer für den ausgehenden Anruf) benötigt.

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.

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.

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). Bei einigen Tests funktionierte SrxReroute an einem Vodafone/Arcor-Anlagenanschluss.

Download

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 zur Verfügung gestellt.

• ISDNUmleitung_v92.sfm (für STARFACE ab Version 6.4.2)
• ISDNUmleitung_v91.sfm (für STARFACE ab Version 6.1)
• ISDNUmleitung_v89.sfm (für STARFACE ab Version 5.1)
• ISDNUmleitung_v88.sfm (für ältere STARFACE Versionen)

QEMU Guest Agent installieren

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.

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.

Die ausführliche Anleitung für die Installation des QEMU-Guest-Agent ist bei RedHat zu finden. Hier sind die wesentlichen Schritte:

Sollte STARFACE irgendwann von CentOS 6 auf eine neuere Version wechseln, wären die Schritte wie folgt anzupassen:

Vom VM-Host aus, kann das Funktionieren der Verbindung mit dem Guest Agent wie folgt überprüft werden:

TLS-Zertifikat austauschen

Das TLS-Zertifikat für Tomcat und der zugehörige private Schlüssel ist in einem Java-Keystore gespeichert.

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.

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 bearbeitet werden.

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:

Beim Export muss ein Passwort angegeben werden. Dieses Passwort muss dann erneut beim Import in KeyStore Explorer angegeben werden.

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.

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:

TLS-Zertifikate mit ECDSA-Schlüsseln

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.

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.

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:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

Je nach verwendetem Browser reicht wahrscheinlich auch nur die erste oder zweite Cipher-Suite.

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.

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.