ERR_SSL_KEY_USAGE_INCOMPATIBLE nach Upgrade auf 10.1.4

[Pascal Stierli]

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

• This topic was modified 1 year ago by Pascal Stierli.

[Stefan Rother]

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

[Pascal Stierli]

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.

[Pascal Stierli]

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:

• This reply was modified 8 months ago by Pascal Stierli.

[Stefan Rother]

Hallo Pascal,

danke für die ausführliche Erklärung, so macht Forum Spaß!

Schöne Grüße,

Stefan

[Author]

Posts