Ctrlk
WebsiteLoginKostenloser TestzugangCommunity
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Wie tausche ich in Enginsight ein selbst signiertes SSL/TLS-Zertifikat aus?

Wenn du für die gesicherte Verbindung zur Enginsight Benutzeroberfläche und/oder zum Enginsight SIEM ein selbst signiertes SSL/TLS-Zertifikat oder eine Windows PKI (Public Key Infrastructure) nutzt, musst du dieses manuell austauschen, wenn du ein neues Zertifikat hinterlegen möchtest. Dies ist bspw. dann der Fall, wenn das alte Zertifikat abgelaufen ist oder wenn du deine Domain geändert hast.

Wir zeigen dir im folgenden Artikel, welche Schritte du dafür vornehmen musst.

Austausch der Zertifikats-Dateien

1

Zertifikats-Dateien auf den Applikationsserver hochladen

Bitte beachte: Diese Schritte gelten nur für Linux- und macOS-Systeme. Unter Windows kannst du bspw. WinSCP (Windows Secure Copy) nutzen, um die Zertifikats-Dateien auf den Applikationsserver hochzuladen.

  1. Navigiere auf dem System, auf dem dein neues Zertifikat liegt, mit folgendem Befehl in den Ordner, der alle neuen Zertifikats-Dateien enthält:

cd /<BenutzerdefinierterVerzeichnispfad>/<OrdnerZertifikatsdateien>

Vergiss dabei nicht, <BenutzerdefinierterVerzeichnispfad> und <OrdnerZertifikatsdateien> entsprechend zu ersetzen.

  1. Lade die neuen Zertifikats-Dateien mit folgendem Befehl auf den Enginsight Applikationsserver in ein Zielverzeichnis deiner Wahl hoch:

<OrdnerZertifikatsdateien> % scp * <BenutzernameApplikationsserver>@<IPAdresseApplikationsserver>:<ZielverzeichnisApplikationsserver>

Vergiss dabei nicht, die Platzhalter in <> entsprechend zu ersetzen:

  • <OrdnerZertifikatsdateien>

  • <BenutzernameApplikationsserver>

  • <IPAdresseApplikationsserver>

  • <ZielverzeichnisApplikationsserver>

2

Optional: Zertifikats-Dateien in das PEM-Format umwandeln

Wenn du deine selbst signierten Zertifikats-Dateien im PFX-Format vorliegen hast, musst du diese nach dem Hochladen auf dem Applikationsserver ins PEM-Format konvertieren.

Du kannst dafür folgende Befehle nutzen:

  • Das Zertifikat ohne den privaten Schlüssel ins PEM-Format umwandeln:

openssl pkcs12 -in <ZertfikatsDateiname>.pfx -clcerts -nokeys -out <NeuerZertifikatsDateiname>.pem

  • Den privaten Schlüssel extrahieren und ins PEM-Format umwandeln:

openssl pkcs12 -in <ZertfikatsDateiname>.pfx -nocerts -out <PrivaterSchlüsselDateiname>.pem

  • Das Kennwort aus dem extrahierten Schlüssel entfernen:

openssl rsa -in <PrivaterSchlüsselDateiname>.pem -out server.key

Vergiss dabei nicht, die Platzhalter in <> entsprechend zu ersetzen:

  • <ZertfikatsDateiname>

  • <NeuerZertfikatsDateiname>

  • <PrivaterSchlüsselDateiname>

3

Zugriffsrechte der Zertifikats-Dateien anpassen

Da die hochgeladenen Zertifikats-Dateien bisher nur für den gerade angemeldeten Benutzer des Applikationsservers, aber nicht für den Webserver lesbar sind, müssen die Zugriffsrechte entsprechend angepasst werden.

Gib dafür folgenden Befehl ein:

sudo chown root: *.pem
4

nginx-Konfiguration anpassen

Nun kannst du die Konfiguration von nginx anpassen.

  1. Öffne dazu mit folgendem Befehl die nginx-Konfigurationsdatei:

sudo nano /etc/nginx/sites-available/ngs.conf

  1. Vergleiche folgende Vorlage mit der Konfigurationsdatei und bearbeite die markierten Zeilen wie folgt:

    • Setze für <EigenerVerzeichnispfad> jeweils den Pfad ein, der zu den neuen Zertifikats-Dateien führt.

    • Setze für <DateinameZertifikatsdatei> den Namen der neuen Zertifikatsdatei ein.

    • Setze für <DateinameSchlüsseldatei> den Namen der neuen Zertifikats-Schlüsseldatei ein.

Bitte beachte: Es muss die komplette Zertifikatskette aus Root-Zertifikat, Intermediate-Zertifikat (wenn vorhanden) und Server-Zertifikat in einer entsprechenden Datei hinterlegt sein!

Bitte beachte: Der Diffie-Hellman-Parameter (dhparam) ist nicht standardmäßig vorhanden und muss erst erstellt werden, da nginx sonst einen Fehler ausgibt.

In unserem Beispiel geben wir zudem eine Schlüssellänge von 2048 Bits an. Diese ist zwar sicher, wir empfehlen jedoch eine Schlüssellänge von 3072 Bits oder 4096 Bits. Passe die Schlüssellänge bei Bedarf entsprechend an. Wir weisen jedoch daraufhin, dass die Erstellung des Schlüssels in diesem Fall wesentlich mehr Zeit in Anspruch nimmt!

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name <DomainApp>;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "ECDHE+AESGCM+AES256";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Erstellung von dhparam.pem:
    #$ sudo mkdir /etc/nginx/ssl -p
    #$ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
    
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    
    ssl_certificate /<EigenerVerzeichnispfad>/<DateinameZertifikatsdatei>.pem;
    ssl_certificate_key /<EigenerVerzeichnispfad>/<DateinameSchlüsseldatei>.pem;

    client_max_body_size 200m;

    location / {
        proxy_pass http://127.0.0.1:81;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-Proto "https";
        proxy_set_header X-Forwarded-Ssl   "on";
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        $connection_upgrade;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name <DomainAPI>;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "ECDHE+AESGCM+AES256";
    ssl_ecdh_curve secp384r1;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Erstellung von dhparam.pem:
    #$ sudo mkdir /etc/nginx/ssl -p
    #$ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
    
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    
    ssl_certificate /<EigenerVerzeichnispfad>/<DateinameZertifikatsdatei>.pem;
    ssl_certificate_key /<EigenerVerzeichnispfad>/<DateinameSchlüsseldatei>.pem;

    client_max_body_size 200m;

    location / {
        proxy_pass http://127.0.0.1:82;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-Proto "https";
        proxy_set_header X-Forwarded-Ssl   "on";
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        $connection_upgrade;
    }
}

  1. Speichere die Änderungen in der Konfigurationsdatei (Strg + o) und bestätige den Speicherprozess. Schließe die Datei (Strg + x).

5

Änderungen an der nginx-Konfiguration überprüfen

Validiere die Änderungen an der nginx-Konfiguration mit folgendem Befehl:

sudo nginx -t

Wenn die Konfigurationsänderungen erfolgreich sind, erhältst du folgende Antwort:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
6

nginx neu starten

Starte nginx mit folgendem Befehl neu:

sudo systemctl restart nginx
7

Funktionalität der Domains überprüfen

Überprüfe nun, ob deine Domains für Benutzeroberfläche (App) und API wie gewünscht funktionieren.

Gib dazu folgende Befehle ein:

  • Benutzeroberfläche (App):

curl -IsS https://<DomainApp> |& head -n1

  • API:

curl -IsS https://<DomainAPI> |& head -n1

Vergiss dabei nicht, <DomainApp> und <DomainAPI> entsprechend zu ersetzen.

Wenn alles wie gewünscht funktioniert, solltest du eine der folgenden Antworten erhalten:

HTTP/1.1 200 OK

oder

 HTTP/2 200

Wenn das selbst signierte Zertifikat als nicht vertrauenswürdig eingestuft wird, wird folgendes ausgegeben:

curl: (60) SSL certificate problem: self signed certificate

Überprüfe in diesem Fall, ob tatsächlich die gesamte Zertifikatskette in der Zertifikatsdatei enthalten ist.

Führe zudem, falls sich auch das Root-Zertifikat geändert hat, die nachfolgenden Schritte zum Trusten des Root-Zertifikats aus.

Trusten des Root-Zertifikats

Wenn sich auch dein Root-Zertifikat geändert hat, musst du dieses auf dem Enginsight Applikationsserver und, wenn du das Enginsight SIEM verwendest, auf dem SIEM Management Server trusten, es also als vertrauenswürdig kennzeichnen.

Bitte beachte: Es werden ausschließlich Zertifikate im .crt-Format akzeptiert. Dateien mit anderen Endungen wie .pem oder .cer werden vom update-ca-certificates-Prozess ignoriert. Im Normalfall ist es möglich, Dateien mit der Endung .pem einfach entsprechend umzubenennen. Wichtig ist, dass das Zertifikat Base64-kodiert ist!

Nimm dazu folgende Schritte vor:

1

Root-Zertifikat in den CA-Store des Applikationsservers kopieren

  1. Logge dich auf dem Enginsight Applikationsserver ein.

  2. Kopiere das Root-Zertifikat mit einem der folgenden Befehle in den CA-Store.

Bitte beachte: Das Zertifikat muss Base64-kodiert sein!

Befehl für Dateien im .pem-Format:

sudo cp <RootZertifikatDateiname>.pem /usr/local/share/ca-certificates/<RootZertifikatDateiname>.crt

Befehl für Dateien im .crt-Format:

sudo cp <RootZertifikatDateiname>.crt /usr/local/share/ca-certificates/<RootZertifikatDateiname>.crt

Vergiss dabei nicht, <RootZertifikatDateiname> entsprechend zu ersetzen.

2

CA-Store des Applikationsservers aktualisieren

Aktualisiere den CA-Store des Applikationsservers mit folgendem Befehl:

sudo update-ca-certificates
3

Root-Zertifikat in den CA-Store des SIEM Management Servers kopieren

Wenn du das Enginsight SIEM verwendest, musst du das Root-Zertifikat auch auf dem SIEM Management Server hinterlegen.

  1. Logge dich auf dem SIEM Management Server ein.

  2. Kopiere das Root-Zertifikat mit einem der folgenden Befehle in den CA-Store.

Bitte beachte: Das Zertifikat muss Base64-kodiert sein!

Befehl für Dateien im .pem-Format:

sudo cp <RootZertifikatDateiname>.pem /usr/local/share/ca-certificates/<RootZertifikatDateiname>.crt

Befehl für Dateien im .crt-Format:

sudo cp <RootZertifikatDateiname>.crt /usr/local/share/ca-certificates/<RootZertifikatDateiname>.crt

Vergiss dabei nicht, <RootZertifikatDateiname> entsprechend zu ersetzen.

4

CA-Store des SIEM Management Servers aktualisieren

Aktualisiere den CA-Store des SIEM Management Servers mit folgendem Befehl:

sudo update-ca-certificates
5

Docker-Konfigurationsdatei auf dem Applikationsserver anpassen

  1. Gehe zurück zum Enginsight Applikationsserver.

  2. Navigiere mit folgendem Befehl in das Enginsight Installationsverzeichnis:

cd /opt/enginsight/enterprise

  1. Öffne mit folgendem Befehl die Docker-Konfigurationsdatei:

sudo nano docker-compose.yml

  1. Um das Root-Zertifikat im nötigen Docker-Container verfügbar zu machen, muss es dort entsprechend manuell eingebunden werden. Navigiere dazu im Docker-Container server-m2 zum Abschnitt volumes und ergänze diesen wie folgt:

volumes:
    - "/usr/local/share/ca-certificates/<RootZertifikatDateiname>:/etc/ssl/cert.crt"

Vergiss dabei nicht, <RootZertifikatDateiname> entsprechend zu ersetzen.

  1. Da Node.js nicht auf den System-Truststore zugreift, muss in den betroffenen Docker-Containern die Umgebungsvariable NODE_EXTRA_CA_CERTS gesetzt werden, um auf das Root-Zertifikat zu verweisen. Navigiere dazu im selben Docker-Container wie zuvor zum Abschnitt environment und ergänze diesen wie folgt:

environment:
    - NODE_EXTRA_CA_CERTS=/etc/ssl/cert.crt

  1. Speichere die Änderungen in der Konfigurationsdatei (Strg + o) und bestätige den Speicherprozess. Schließe die Datei (Strg + x).

6

Docker-Konfigurationsdatei auf dem SIEM Management Server anpassen

  1. Gehe zurück zum SIEM Management Server.

  2. Navigiere mit folgendem Befehl in das Enginsight Installationsverzeichnis:

cd /opt/enginsight/enterprise

  1. Öffne mit folgendem Befehl die Docker-Konfigurationsdatei:

sudo nano docker-compose.yml

  1. Um das Root-Zertifikat in den nötigen Docker-Containern verfügbar zu machen, muss es dort entsprechend manuell eingebunden werden. Navigiere dazu in den Docker-Containern solr, zookeeper und traicer zum Abschnitt volumes und ergänze diesen wie folgt:

volumes:
    - "/usr/local/share/ca-certificates/<RootZertifikatDateiname>:/etc/ssl/cert.crt"

Vergiss dabei nicht, <RootZertifikatDateiname> entsprechend zu ersetzen.

  1. Da Node.js nicht auf den System-Truststore zugreift, muss in den betroffenen Docker-Containern die Umgebungsvariable NODE_EXTRA_CA_CERTS gesetzt werden, um auf das Root-Zertifikat zu verweisen. Navigiere dazu in denselben Docker-Containern wie zuvor zum Abschnitt environment und ergänze diesen wie folgt:

environment:
    - NODE_EXTRA_CA_CERTS=/etc/ssl/cert.crt

  1. Speichere die Änderungen in der Konfigurationsdatei (Strg + o) und bestätige den Speicherprozess. Schließe die Datei (Strg + x).

7

Anpassungen auf dem Applikationsserver übernehmen

Nun musst du das Setup-Skript für den Applikationsserver noch einmal ausführen, um deine Anpassungen zu übernehmen.

  1. Gehe zurück zum Enginsight Installationsverzeichnis auf dem Applikationsserver.

  2. Führe mit folgendem Befehl das Setup-Skript neu aus und bestätige alle Abfragen mit der Enter-Taste:

sudo ./setup.sh

Weitere Ressourcen

VorherigeWie richte ich in Enginsight eine Field Level Encryption ein?NächsteWelche Aktivitäten werden im Benutzer-Log von Enginsight mitgeschnitten?

Zuletzt aktualisiert

War das hilfreich?