nginx - ssl_ciphers und ssl_protocols modernisieren

[bitn2]

Noch was zum Thema GPO in einer Windows Domäne und einem Linux Client... Natürlich kannst du den per GPO verwalten und das solltest du wissen wenn du das schon so lange machst. Das dies nicht magisch passiert sondern konfiguriert werden muss ist hoffentlich klar.

 

[tkurbad]

Ich weiß aber 100%ig, dass mein Client nicht unter die GPO-Verwaltung fällt. Dass es geht, steht außer Frage, es ist so aber - ganz bewusst - nicht eingerichtet. Ich muss ja nicht nur auf 3CX zugreifen, sondern auch auf viele Seiten mit mir zunächst unbekannten Sicherheitseinstellungen.

Und ja, andere Webseiten, die nur <=TLSv1.2 anbieten, funktionieren. Das habe ich gestern erst getestet. 3CX wird in der Browsereinstellungen in keiner Weise besonders behandelt - und mein Client steht im selben Netz, es ist also keine Firewall o.ä. dazwischen, nur ein paar relativ dumme Switche, die lediglich IP-basierte ACLs beherrschen.

Aber wir drehen uns hier ohnehin nur im Kreis, denn das meiste davon hatte ich früher schon geschrieben.

 

[fxbastler]

Der Windows Server zieht keine GPO bzw. ganz sicher, dass das keine Auswirkungen auf die dort laufende 3CX hat?

 

[tkurbad]

Klar zieht der GPOs, Aber das tangiert doch die Kommunikation zwischen einem externen Client und dem Nicht-.Windows-nativen Nginx nicht.
Wenn 3CX auf IIS liefe, was es Gott sei Dank nicht tut, wäre ich bei dir...

Ich schaue mir jetzt aber mal unsere GPOs an. Wir sind im Wissenschaftsbetrieb. Ich kann mir kaum vorstellen, dass unser Windows-Admin sich freiwillig den Klotz ans Bein binden würde, TLS 1.2 abzuschalten.

 

[bitn2]

Da der Link in deinem Screenshot zu sehen ist, hab ich die Seite mal aufgerufen und das Zertifikat geprüft. Da ist alles ok. Das muss eine Einstellung in euren Browsern oder Virenscanner sein die das Problem verursacht. Am Zertifikat und der 3CX liegt es nicht.

 

[tkurbad]

Dann schlage ich ein Experiment vor: Ich aktiviere auf unserem Server die mitgelieferte 50-ssl-protocols.conf und du versuchst nochmals, die Seite aufzurufen. Gib mir 1 Minute.

 

[tkurbad]

Versuch bitte mal dein Glück.

PS: Habe lediglich TLSv1.3 deaktiviert. Zertifikat, etc. unverändert.

 

[fxbastler]

geht nicht

 

[bitn2]

Dann bekomme ich den von dir genannten Fehler. Das bleibt aber weiterhin ein Problem eurer Konfiguration. Ich habe diverse Anlagen mit 3CX Zertifikat als auch eigenen Zertifikaten und nirgends dieses Problem.

 

[tkurbad]

Bin mittlerweile unsere GPOs durchgegangen, an denen liegt es auch nicht. Da wird lediglich TLSv1.2 als Standard für .NET festgelegt, Cyphers usw. werden sonst nirgends angefasst.

Dann soll unser Service-Partner das mal durchchecken, mir fällt dazu nichts mehr ein.

 

[fxbastler]

Zusammengefasst: Windows Server (welche Version eigentlich?), sicherlich virtualisiert (welcher HV?), AD Mitglied, ohne sonstige Rollen, 3CX v18.0.9.31 mit HTTPS Port 5001, eigenes Zertifikat, nur NAT Weiterleitung von einer öffentlichen IP (kein offload?), Firewall Check läuft grün durch, 3CX Website zeigt ein cipher mismatch an so lange explizit kein TLS 1.3 Protokoll manuell aktiviert wird

Was mir auffällt: das ist ein SAN Zertifikat und der common name ist nicht der FQDN der 3CX, dieser steht erst in den alternativen drin. Was noch sein _kann_ und was ich so auf die Schnelle nicht überprüft habe: die angebotenen Algorithmen der Website und die Schlüsselerzeugung des Zertifikates - ob das zu TLS 1.2 und zu der von der 3CX in der v18 verwendeten .Net Version passen _kann_.

 

[tkurbad]

Zusammengefasst: Windows Server (welche Version eigentlich?),

2019 Standard (1809)

sicherlich virtualisiert (welcher HV?),

VMware ESXi 7.0.3 in einem vSphere Cluster

AD Mitglied, ohne sonstige Rollen, 3CX v18.0.9.31 mit HTTPS Port 5001, eigenes Zertifikat, nur NAT Weiterleitung von einer öffentlichen IP (kein offload?),

Genau, reines NAT

Firewall Check läuft grün durch, 3CX Website zeigt ein cipher mismatch an so lange explizit kein TLS 1.3 Protokoll manuell aktiviert wird

Genau.

Was mir auffällt: das ist ein SAN Zertifikat und der common name ist nicht der FQDN der 3CX, dieser steht erst in den alternativen drin.

Normalerweise rufen unsere Endanwender den Server unter seinem CN auf.

Was noch sein _kann_ und was ich so auf die Schnelle nicht überprüft habe: die angebotenen Algorithmen der Website und die Schlüsselerzeugung des Zertifikates - ob das zu TLS 1.2 und zu der von der 3CX in der v18 verwendeten .Net Version passen _kann_.

Das wäre tatsächlich untersuchenswert. Unsere Zertifikate stammen aus einem Rahmenvertrag des DFN mit Sectigo. Dabei haben wir nur relativ begrenzten Einfluss auf die Zertifikatsparameter. Dem werde ich mal nachgehen.

 

[bitn2]

Da kenne ich mich jetzt auch nicht perfekt aus, aber dein Zertifikat hat den Algorithmus X9.62-ECDSA-Signatur mit SHA-256 und das einer Standard 3cx PKCS #1 SHA-256 mit RSA-Verschlüsselung.

 

[tkurbad]

Dann erstelle ich mal ein neues Zertifikat mit RSA-Schlüssel.

 

[bitn2]

Hab gerade noch was dazu gefunden, das scheint wirklich euer Problem zu sein: https://www.3cx.com/community/threa...-fine-but-android-will-not.119818/post-560808

 

[tkurbad]

Et voila, das war's, vielen Dank!!! Das schreibe ich mir jetzt sehr prominent in die Doku. Tatsächlich gehört RSA vs. ECDSA Key zu den wenigen Zertifikatsparametern, die ich beeinflussen und beim Verlängern auch umstellen kann.

Danke nochmal für die Hilfe! Wieder was gelernt...

 

[bitn2]

Sauber! Dann hat sich das Problem nun gelöst.