Topic Resolution: Answered

Schlagwörter: 

Ansicht von 4 Antwort-Threads
  • Autor
    Beiträge
    • 12. Mai 2022 um 10:48 Uhr - Views: 1280 #13205
      Answered
      Pascal Stierli
      Teilnehmer

        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
        Stefan Rother
        Administrator

          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
          Pascal Stierli
          Teilnehmer

            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
            Best Answer
            Pascal Stierli
            Teilnehmer

              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
              Stefan Rother
              Administrator

                Hallo Pascal,

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

                Schöne Grüße,

                Stefan

            • Autor
              Beiträge
            Ansicht von 4 Antwort-Threads
            • Du musst angemeldet sein, um auf dieses Thema antworten zu können.