Schlagwörter: HTTPS; SSL
-
AutorBeiträge
-
-
12. Mai 2022 um 10:48 Uhr - Views: 938 #13205
Hallo zusammen,
Nach einem Upgrade von 10.0.16 auf 10.1.4 (Docker-Installation) erhalten wir in den Browsern Chrome/Edge (was soweit konsistent ist aufgrund der gleichen Engine) die Fehlermeldung „ERR_SSL_KEY_USAGE_INCOMPATIBLE“ für den Aufruf der Weboberfläche (gilt sowohl für Agenten, als auch Kundenansicht). In Firefox funktioniert soweit weiterhin alles. Kennt jemand dieses Problem und hat allenfalls einen Ansatz zur Lösung? Das eingesetzte SSL-Zertifikat ist ein mittels interner-CA Self-Signed Zertifikat dem seitens Client/Browser vertraut wird. Damit gab es bisher keine Probleme.
Die verwendete Docker-Compose Datei:
COMPOSE_PROJECT_NAME=otobo
COMPOSE_PATH_SEPARATOR=:
COMPOSE_FILE=docker-compose/otobo-base.yml:docker-compose/otobo-override-https.yml
OTOBO_DB_ROOT_PASSWORD=<password>
OTOBO_NGINX_SSL_CERTIFICATE=/etc/nginx/ssl/hd102.crt
OTOBO_NGINX_SSL_CERTIFICATE_KEY=/etc/nginx/ssl/hd102.key
OTOBO_ELASTICSEARCH_ES_JAVA_OPTS=-Xms512m -Xmx512m
OTOBO_SYNC_WITH_S3=0
-
12. Mai 2022 um 12:43 Uhr #13207
Hallo Pascal,
ich weiß, dass wir die SSL-Einstellungen in der OTOBO 10.1 verschärft haben und an aktuelle Standards angepasst haben. Hier würde ich ansetzen. In der 10.0 hat die Datei und somit die SSL Einstellungen so ausgesehen:
https://github.com/RotherOSS/otobo/blob/rel-10_0/scripts/nginx/snippets/ssl-params.conf
Unter 10.1 wie folgt:
https://github.com/RotherOSS/otobo/blob/rel-10_1/scripts/nginx/snippets/ssl-params.conf
Die Datei liegt im Docker NGINX Container unter /etc/nginx/snippets/ssl-params.conf
Hier würde ich ansetzen und danach den NGINX mit
nginx -s reload
testweise nur einem reload unterziehen, damit Deine Änderungen nicht wieder überschrieben werden.
Ansonsten würde ich schauen, was Chrome denn genau an den Zertifikat auszusetzen hat und eventuell die Schlüssellänge erhöhen.
Schöne Grüße,
Stefan
-
12. Mai 2022 um 13:58 Uhr #13208
Hallo Stefan,
Danke für die ausführliche und zügige Antwort. Ich werde das ganze asap überprüfen, testen und mich mit den Erkentnissen wieder melden.
-
29. September 2022 um 14:29 Uhr #13887
Hallo Stefan,
Und so schnell kann Mensch eine Sache verdrängen ;) Das Problem ist mittlerweile gelöst, lag aber wohl nicht (bzw. nicht nur) an der Schlüssellänge. Die zu grundeliegende Chromium-Engine verhält sich bei TLS 1.3 Zertifikaten wohl anderst als zuvor bei TLS 1.2 und auch anderst als Firefox. Damit Chrome/Edge selbst-signierte Zertifikate mit TLS 1.3 akzeptiert, müssen diese zwingend mit den Parametern „keyUsage = nonRepudiation, digitalSignature, keyEncipherment“ (Beispiel OpenSSL) erstellt werden. Ausführlich wird das ganze hier besprochen: https://superuser.com/a/1466427
In der Windows-CA Zertifikatsvorlage ist die gleiche Einstellung unter „Anforderungsverarbeitung“ –> „Zweck“ (Signatur und Verschlüsselung auswählen) zu finden. Was dann zu folgenden Eigenschaften führt im Zertifikat selbst:
-
29. September 2022 um 14:49 Uhr #13889
Hallo Pascal,
danke für die ausführliche Erklärung, so macht Forum Spaß!
Schöne Grüße,
Stefan
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.