Gamma SIP over TLS

[igmbh]

Moin,

vorweg unser Setup:

• lokal gehosted auf einer Linux-VM
• Version 20.0 Update 9 (Build 995 Release - AI 1.4.48)
• Custom FQDN
• Wir verwenden Lets Encrypt für unsere 3CX-Maschine

Ich versuche aktuell bei uns SIP over TLS mit unserem SIP Anbieter Gamma zu konfigurieren. Ich folge dabei den Anleitungen hier:

https://www.3cx.com/docs/sip-trunk-tls-srtp/

Secure SIP – TLS

Check out this post for more information on how to configure secure SIP, TLS, simple CA, ReSiProcate and secure SIP Stack with 3CX.

www.3cx.com

Ich habe zudem bei Gamma angefragt, ob es von ihrer Seite unterstützt ist und folgende Antwort bekommen:

Um unser kostenloses Verschlüsselungsfeature zu nutzen, muss der Kunde:

• Die neue Domain customer.ngnetwork.de als Registrar verwenden
• SIP-TLS-Port 5061 verwenden
• als Transportprotokoll „TLS“ (anstatt UDP oder TCP) einstellen
• Medienverschlüsselung aktivieren ( RTP / SAVP ) bzw. SRTP
• Die IP-Bereiche 213.167.169.0/26 und 213.167.169.64/26 in der Firewall freigeben
• Als Mediaports ( SRTP ) für die Gamma Seite den Bereich 35000 bis 59999 konfigurieren
• Das Root-CA von Sectigo (unserem Zertifikataussteller) in die TK- Anlage importieren, siehe Link:

http://crt.sectigo.com/USERTrustRSACertificationAuthority.crt

Jetzt habe ich aus meiner Sicht alles passend konfiguriert, eingehende Anrufe schlagen aber leider fehl. In einem Mitschnitt sehe ich folgendes:

 > tshark -r dump.pcap -Y "tcp.port == 5061"
 1317   1.952153 Gamma-IP → 3cx-IP TCP 80 24288 → 5061 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=2666377836 TSecr=0
 1318   1.952188 3cx-IP → Gamma-IP TCP 80 5061 → 24288 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 TSval=3226390265 TSecr=2666377836 WS=128
 1324   1.965491 Gamma-IP → 3cx-IP TCP 72 24288 → 5061 [ACK] Seq=1 Ack=1 Win=262144 Len=0 TSval=2666377849 TSecr=3226390265
 1326   1.965725 Gamma-IP → 3cx-IP TLSv1.2 589 Client Hello
 1327   1.965742 3cx-IP → Gamma-IP TCP 72 5061 → 24288 [ACK] Seq=1 Ack=518 Win=64768 Len=0 TSval=3226390279 TSecr=2666377849
 1328   1.966404 3cx-IP → Gamma-IP TLSv1.3 2968 Server Hello, Change Cipher Spec, Application Data
 1329   1.966418 3cx-IP → Gamma-IP TLSv1.3 1005 Application Data, Application Data, Application Data
 1346   1.982169 Gamma-IP → 3cx-IP TLSv1.3 79 Alert (Level: Fatal, Description: Unknown CA)
 1347   1.982169 Gamma-IP → 3cx-IP TCP 72 24288 → 5061 [FIN, ACK] Seq=525 Ack=3830 Win=262144 Len=0 TSval=2666377866 TSecr=3226390280
 1348   1.982402 3cx-IP → Gamma-IP TCP 72 5061 → 24288 [FIN, ACK] Seq=3830 Ack=526 Win=64768 Len=0 TSval=3226390296 TSecr=2666377866
 1356   1.995738 Gamma-IP → 3cx-IP TCP 72 24288 → 5061 [ACK] Seq=526 Ack=3831 Win=262144 Len=0 TSval=2666377879 TSecr=3226390296

Spannend ist also:

1346 1.982169 Gamma-IP → 3cx-IP TLSv1.3 79 Alert (Level: Fatal, Description: Unknown CA)

Ich habe Gamma darauf angesprochen, weil ich vermute, dass diese schlicht keine Lets Encrypt Zertifikate unterstützen / die CA nicht kennen. Von deren Seite kam eine Vermutung auf, dass unsere 3CX-Anlage mTLS versucht. Letzteres kann ich mir nicht so wirklich vorstellen. Muss ich hier weiter auf unserer Seite auf Fehlersuche gehen oder eher den Gamma-Support nerven? Hat es hier jemand mit Gamma als Provider schon zum Laufen bekommen? Besten Dank vorab

 

[StefanPf]

Nur ein wild guess:
Falls noch nicht geschehen, versuch mal das Zertifikat inkl. der vollen Zertifikatskette in die 3CX zu laden.

 

[avraammich_3CX]

346 1.982169 Gamma-IP → 3cx-IP TLSv1.3 79 Alert (Level: Fatal, Description: Unknown CA)

Obige Meldung ist etwas was du mit dem Provider prüfen musst.
Meldung bekommst du von Gamma

Wenn die TLS-Verbindung auf Seiten der Telefonanlage hergestellt ist, nimmt die 3CX Telefonanlage Anrufe über die bestehende Verbindung entgegen.

Nach Server Hello, Change Cipher Spec, Application Data sollte ein "Server key Exchange" erfolgen, Gamma sendet jedoch obige Meldung,

Etwas passt mit dem Zertifikat nicht.

 

[igmbh]

Nur ein wild guess:
Falls noch nicht geschehen, versuch mal das Zertifikat inkl. der vollen Zertifikatskette in die 3CX zu laden.

Welches meinst du? Das von Gamma im SIP-Trunk oder das Lets Encrypt unter Admin > Erweitert > Secure SIP?

Ich habe gerade mal das komplette Cert von Gamma im SIP-Trunk hinterlegt, leider auch ohne Erfolg. Das habe ich mir wie folgt besorgt und sieht auch gut aus:

> openssl s_client -connect customer.ngnetwork.de:5061 -servername customer.ngnetwork.de -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' > served-chain.pem
> openssl crl2pkcs7 -nocrl -certfile served-chain.pem | openssl pkcs7 -print_certs -noout
subject=CN=customer.ngnetwork.de
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36

subject=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46

subject=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
issuer=C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority

Unter Admin > Erweitert > Secure SIP habe ich von unserem Lets Encrypt Zertifikat die Fullchain + Priv Key hinterlegt. Wenn ich auf dem Server selbst schaue, sieht das aus meiner Sicht auch gut aus:

> openssl s_client -connect my-domain.de:5061 -showcerts > /dev/null
depth=3 C = US, O = Internet Security Research Group, CN = ISRG Root X2
verify return:1
depth=2 C = US, O = ISRG, CN = Root YE
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = YE1
verify return:1
depth=0 CN = my-domain.de
verify return:1

 

[igmbh]

Obige Meldung ist etwas was du mit dem Provider prüfen musst.
Meldung bekommst du von Gamma

Wenn die TLS-Verbindung auf Seiten der Telefonanlage hergestellt ist, nimmt die 3CX Telefonanlage Anrufe über die bestehende Verbindung entgegen.

Nach Server Hello, Change Cipher Spec, Application Data sollte ein "Server key Exchange" erfolgen, Gamma sendet jedoch obige Meldung,

Etwas passt mit dem Zertifikat nicht.

Ok gut, sehe ich ähnlich. Dann kläre ich das erstmal weiter mit Gamma.

 

[igmbh]

Ich habe auch schon Rückmeldung vom Gamma-Support erhalten. Ich zitiere hier einfach mal die Antwort:

Danke für den Mitschnitt, leider sehen wir auch in diesem den Verbindungsaufbau von der 3CX zu Gamma nicht.
Nur den umgekehrten Handshake konnten wir finden:
Gamma sendet Client Hello an die PBX, bekommt deren Zertifikat angezeigt und lehnt die Verbindung mit „Unknown CA“ ab.

Dieser Handshake sollte jedoch im Normalfall gar nicht stattfinden.

Bitte prüfen Sie, ob auf der 3cx Schalter wie z.B. „TCP/TLS connection re-use“ oder auch „alias“ (“VIA Header“) für den SIP-Trunk existieren, und aktivieren Sie diese(n) Schalter.

Da unser SBC „connection re-use“ nach RFC 5923 unterstützt, sollte nach Aufbau der Verbindung zwischen 3CX à Gamma
diese Verbindung auch für die Gegenrichtung verwendet werden, ohne die Notwendigkeit für die Gegenrichtung eine separate TLS Verbindung aufbauen zu müssen.

RFC 5923 ("Connection Reuse") wurde genau dafür geschaffen.

Ohne Connection Reuse:

A ----TLS----> B



B ----TLS----> A

B baut für eingehende SIP Requests (INVITE, NOTIFY, BYE usw.) eine neue Verbindung zu A auf.

Mit Connection Reuse:

A ----TLS----> B

<---- SIP Requests über dieselbe TLS-Session


Damit das funktioniert:

• Client A muss signalisieren, dass Reuse gewünscht ist (Parameter alias im Via-Header).
• Server B muss das RFC-5923-Verhalten unterstützen und die vorhandene TLS-Verbindung für ausgehende Requests wiederverwenden.

Ich habe bzgl. Connection Reuse in 3CX / im SIP Trunk nichts gefunden. Wird das von 3CX unterstützt?

 

[Claas Beyersdorf]

Connection Reuse ist auf jeden Fall supported. Kann da jetzt nur für Telekom Company Flex sprechen. Da baut die 3CX die TLS Session auf und anschließend läuft die ganze Kommunikation durch diese etablierte Verbindung.

Dann muss man theoretisch in der Firewall nicht mal die port Forwardings haben. Also für 5060 und 5061 die RTP ports natürlich schon.

Meine Frage wäre was für eine Firewall hängt dazwischen und macht die vielleicht TLS inspection bricht also die TLS Session auf und verursacht so eventuell den Fehler?

 

[avraammich_3CX]

Hi @igmbh,

zusätzlich zu @Claas Beyersdorf Infos, stelle sicher dass eine statische öffentliche IP verwendet wird keine Dynamische.
TLS/SRTP nur mit einer Statischen IPs.
Mich würde auch interessieren welches Provider Template hier genaue verwendet wird ?

 

[igmbh]

Hey @avraammich_3CX & @Claas Beyersdorf . Danke für eure Antworten!

> Meine Frage wäre was für eine Firewall hängt dazwischen und macht die vielleicht TLS inspection bricht also die TLS Session auf und verursacht so eventuell den Fehler?

Die Firewall dazwischen ist relativ dumm, ist einfach eine Linux-Kiste mit iptables / ferm-Regeln. Wir haben da keine Packet / TLS Inspection o.ä.

> stelle sicher dass eine statische öffentliche IP verwendet wird keine Dynamische. TLS/SRTP nur mit einer Statischen IPs.

Ist gesetzt



> Mich würde auch interessieren welches Provider Template hier genaue verwendet wird ?

Ich hatte den Generic VoIP Provider (Registration) genommen. Ich kann hierzu auch nochmal meine Konfig zeigen. Im SIP-Trunk selbst:



Da habe ich bei der Art der Authentifizierung auch schon einmal alles durchprobiert, sonst gibt es hier ja nicht viel. Unter Optionen dann:



Das Zertifikat ist gerade die Root-CA von Gamma. Ich habe da aber auch schon einmal Root-CA + Intermediate und Full Chain hinterlegt (habe ich hier als .zip mal mit angehängt). Leider ohne Erfolg. Hier habe ich dann noch Secure SIP aktiviert:



@Claas Beyersdorf muss ich für Connection Reuse in 3CX noch irgendwo einen Haken o.ä. setzen? Ich bin da bisher nicht fündig geworden.

 

[bitn2]

Versuchs mal mit dem Template

 

[avraammich_3CX]

muss ich für Connection Reuse in 3CX noch irgendwo einen Haken o.ä. setzen?

Nein musst du nicht.

@bitn2, das Template verwendet UDP TransportRestriction.
@igmbh möchte TLS haben.

Weiterführend für TLS ist SRTP voraussetzung:

<field name="SRTPMode">2</field>

​

 

[bitn2]

Nein musst du nicht.

@bitn2, das Template verwendet UDP TransportRestriction.
@igmbh möchte TLS haben.

Weiterführend für TLS ist SRTP voraussetzung:

<field name="SRTPMode">2</field>

​

Oh sorry, das hatte ich im vorwege nicht geprüft. Das dann entsprechend einmal anpassen. Der Rest sollte für HFO/Gamma passen.

 

[bitn2]

Hab noch ein aktuelleres Template für Gamma. Hier auch schon angepasst für TLS und SRTP

 

[igmbh]

Hab noch ein aktuelleres Template für Gamma. Hier auch schon angepasst für TLS und SRTP

Moin, danke dir für die Mühe! Leider klappt es mit der Vorlage auch nicht :/. Ich sehe beim verwenden der Vorlage dann auch keinerlei Traffic auf Port 5061. Hier meine Einstellungen unter Allgemein:



Ohne weitere Änderungen. Ich habe probehalber in der Vorlage noch aktiviert Zertifikate hinterlegen zu können, aber auch damit hat es dann nicht funktioniert.

 

[igmbh]

Braucht es dann überhaupt die Einstellung unter Erweitert > Secure SIP noch? Ist gerade bei mir noch gesetzt und das Zertifikat von der 3CX-Anlage (Lets Encrypt) hinterlegt. Nach meinem Verständnis findet in der Richtung dann ja gar kein Handshake statt.

 

[Claas Beyersdorf]

Also so wie ich es kenne, aktiviert die 3CX verschlüsseltes SIP nur wenn ein Zertifikat unter Erweitert -> Secure SIP eingespielt ist und halt auch aktiviert ansonsten fängt die 3CX nicht an sich zu registrieren.

Dann baut die 3CX aber auch die Verbindung zum Trunk auf und der Traffic läuft durch diese TCP/TLS Session.

Vermutlich würde bei einem nicht registrierten Trunk als bei Peering auch vom Provider eine Verbindung aufgebaut falls gerade keine aktive Verbindung besteht, kann mich aber gerade nicht erinnern ob ich das aktiv schon mal mit einer 3CX hatte.

Das Provider Zertifikat, das man in der 3CX einspielt im Trunk benutzt die 3CX dann um zu prüfen, ob das vom Provider zurück gelieferte Zertifikat valide ist.

Also im Grunde muss man nur schauen was liefert Gamma für ein Zertifikat mit welcher Chain zurück und das letzte Zertifikat in der Chain oder das Signierende Zertifikat dieses letzten Zertifikats muss die 3CX dann haben.

Im Grunde könnte man unter linux aus dem Netz der 3CX

openssl s_client -connect customer.ngnetwork.de:5061 -showcerts
mal schauen was gamma überhaupt für ein Zertifikat liefert. Weil die 3CX hat einen sehr kleinen Truststore ich glaube nur für Supportete Provider. Sprich wenn die Chain nicht validiert werden kann geht das nicht.

 

[Claas Beyersdorf]

Ich habe das mal gerade bei mir ausgeführt.

Also folgender Inhalt müsste dann per Texteditor in eine .pem Datei und dann für den Trunk als Zertifikat hochgeladen werden.

-----BEGIN CERTIFICATE-----
MIIGlTCCBH2gAwIBAgIRANJ/u8HeNZ5SFq1hSVhgmcQwDQYJKoZIhvcNAQEMBQAw
gYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK
ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYD
VQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTIx
MDMyMjAwMDAwMFoXDTM4MDExODIzNTk1OVowXzELMAkGA1UEBhMCR0IxGDAWBgNV
BAoTD1NlY3RpZ28gTGltaXRlZDE2MDQGA1UEAxMtU2VjdGlnbyBQdWJsaWMgU2Vy
dmVyIEF1dGhlbnRpY2F0aW9uIFJvb3QgUjQ2MIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEAk77VNlJ12AEjoBxHQknuY7a3If3EldVIKyZ8FFMQ2nn9K7ct
pNQs+uoy3UnCub0PSD17WphUr55dMXRPB/xQId2kz2hPGxJjbSWZTCqZ80gwYfqB
fB6nCErcPiscHxhMcao1jK34bug7StnllALWiYQTqm3ITzPMUJY3kjPcX4jnn1TZ
SPCYQ9Zm/Z8XOEPFAVEL1+MjDxRdWxTnS77d9MjaAzfR1jmhIVEwg7Bt1zBOlluR
8HAkq79FgWRDDb0hOi886Z4NyyC1QifM2m+b7mQwkDnNk2WBITG1I1AzNyLjOO34
MTDMRf5i+dFdMnlCh99qzFYZQE3Oqrv5tXZJlPEn+JGlg+UGs2MOgNzgElWApjtm
tDmHLcjw0NEU6eQNTQ72XVdyxTscR1ad4tX7gWGMzE2AkDRbt9cUddzYBEifwMEo
iLTpHMqnsfFWt3tJTFnlIBWohAIp+jiUaZpJBo/NH3kUFxIMg3reH7GX7vmXeCik
yESS6X0mBaZYcpt5E9gRX67FOGI0aLKGMI74kGGeMmz1BzbNokxu7Io27fLmmRVE
cMN8vJw5wLTha/eDJSNX2RKA5UnwdQ/vjescm1QotCE8/HwK/+97a3X/ix2gGQWr
+vgrgULoOLq7+6r9PeDzyt9Ol5cp7fMYVumllqy9w5CYsuD5otSmR0N8bc8CAwEA
AaOCASAwggEcMB8GA1UdIwQYMBaAFFN5v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1Ud
DgQWBBRWc1hklfmSGrASKgRieaFAFYghSTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEQYDVR0g
BAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRy
dXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDA1
BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVz
dC5jb20wDQYJKoZIhvcNAQEMBQADggIBADpvBIlq7bMU0cFDT/9P9+BsgCkRgQs0
S6Bf7vJSlWMHwby0VGvxCS0hrbi0K2BINZbEbsVsgpQq04431yyoVn3Hldorgq24
RldRDOOipEZDTFB9wC9HYt1thHF00XeG2C8KC1plwoEzKAIhPvefI/C3cT0CfTXJ
uFjUbKIgSwjNjw6YHtLgoy/hd5+JLUlLco/gzFX/qWbT7tEquOMYpsNKWZj8TLqP
q6zMiG4Na6feEZte6YPXGrMWlTWN341vDedc+yxQqSug79HJUQcOZs7KyDWztmae
QxsPE49UV/8XwrfZtZaYyrs4FpD94Z4Q8dzXGL8+qEJjxgcza7W6PROaClubavd1
VKPm8+aCW77u7SxpR2TFGL6kPdxsKyFijpcunR5V79sUyROfNdzjrAcFWZXK8sbb
9FlnwuVG677JLv+ZVTX5AxLvW5OB4zt5uS+zB62wJ/Wv+jXGAttSAcJec4iFgCWH
Rvdi/jJoSzRLa3nEzx6pFIzclSCnh0u1xCeLcUBypSiPga8W+6PkuoyQq8U9qs9E
oxG5NvrvlyshwUS9yvcZRGw7Ljlx4jJH/BhIPR8kIBCQj1vna9TziZOrw1Of8hDU
bHKFG9Pm8Dp2vbjz/2JH39qvxshPKVllGfq+5klPm7yZRUYTiCMAbqwNdL/nsqF2
Rnnyp58XRStJ
-----END CERTIFICATE-----

Das sollte das Zertifikat von USERTrust RSA Certification Authority sein und ist der letze Issuer in der CA Chain.
Das sollte dann auch weiter funktionieren, wenn Gamma dann
NotAfter: Mar 21 23:59:59 2027 GMT ihr Zertifikat erneuern müssen. Unter der Annahme das Sie weiterhin den Gleichen Anbieter für Zertifikate verwenden.

 

[igmbh]

Moin,
das Zertifikat hab ich in allen Formen schon probiert, leider hat es nichts gebracht. Ich bin zwischenzeitlich noch über ein Stück Doku von 3CX gestoßen. Gamma ist als Provider in UK gelisted:

https://www.3cx.com/partners/sip-trunks/uk/

Dort steht:

SIP TLS Support: No

Ich gehe einmal davon aus, dass man der Dokumentation an der Stelle trauen kann und (korrigiert mich gerne wenn nicht) und die Implementation von Gamma schlicht nicht mit 3CX kompatibel ist. Wir testen es vielleicht noch einmal mit einem anderen SIP Anbieter. Danke euch trotzdem für eure Unterstützung!