Schritt-für-Schritt-Anleitung zur Änderung der Domain

Bei der Änderung der Domain für On-Premises-Systeme ist es wichtig, eine strukturierte Vorgehensweise zu verfolgen, um eine reibungslose Umstellung zu gewährleisten. Folgen Sie dafür bitte unserer Anleitung.

Schritt 1: Erstellung einer neuen Domain und eines neuen Zertifikates.
Erstellen Sie eine neue Domain und generieren Sie anschließend ein neues Zertifikat für Ihre neue Domain.

Schritt 2: Hinterlegen Sie das neue Zertifikat auf dem App Server
Für eine reibungslose Umstellung, empfehlen wir das neue Zertifikat im gleichen Pfad wie das alte abzulegen.

Schritt 3: Öffnen Sie die nginx-Konfigurationsdatei
Um Ihre nginx-Konfigurationsdatei zu bearbeiten, öffnen Sie die Datei in einem Texteditor Ihrer Wahl. Sie können beispielsweise den Nano-Editor verwenden:

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

Schritt 4: Finden Sie die aktuellen Zertifikatseinträge
Innerhalb der Konfigurationsdatei suchen Sie nach den Zeilen, die Ihr derzeitiges SSL-Zertifikat und den privaten Schlüssel angeben. Diese sehen typischerweise wie folgt aus:

ssl_certificate /<Pfad>/fullchain.pem;

ssl_certificate_key /<Pfad>/privkey.pem;

Schritt 5: Tauschen Sie das Zertifikat aus

Ersetzen Sie die Pfade und gegebenenfalls die Dateinamen Ihrer Zertifikat-Dateien mit denen Ihres neuen Zertifikats. Achten Sie darauf, dass die vollständige Zertifikatskette (Webserver, Intermediate, Root-Zertifikat) im pem-Format hinterlegt ist.

Sollten Sie Ihr Zertifikat nur im PFX Format haben, können Sie dies wie folgt formatieren in pem.:

Mit folgenden Befehl können Sie den privaten Schlüssel aus einer PFX-Datei in eine PEM-Datei extrahieren:


# openssl pkcs12 -in filename.pfx -nocerts -out key.pem

Nur das Zertifikat exportieren:

# openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem

Entfernen des Kennworts aus dem extrahierten privaten Schlüssel:

# openssl rsa -in key.pem -out server.key

Denken Sie daran, dass Sie das für Ihre APP sowie API machen müssen!

Schritt 6: Speichern Sie die Konfiguration
Nachdem Sie die notwendigen Änderungen vorgenommen haben, speichern Sie die Konfigurationsdatei. In Nano können Sie dies mit

 CTRL+O

zum Speichern und

CTRL+X

zum Beenden tun.

Schritt 7: Überprüfen Sie die Konfiguration
Bevor Sie nginx neu starten, ist es wichtig, die Konfiguration auf Fehler zu überprüfen. Dies können Sie mit folgendem Befehl tun:

nginx -t

Falls Fehler gemeldet werden, überprüfen Sie die Änderungen und korrigieren Sie diese entsprechend.

Schritt 8: Neustart von nginx
Wenn die Konfiguration korrekt ist und keine Fehler gefunden wurden, starten Sie nginx neu, um die Änderungen zu übernehmen:

service nginx restart

Schritt 9: Prüfen Sie die Funktionalität Ihrer Domain

Hierfür können Sie curl nutzen:

curl - v <IhreDomain>

Sollte sich auch das root Zertifikat geändert haben, müssen Sie dieses noch auf den Linux Servern trusten:

Kopieren Sie das Root Zertifiakt nach /usr/local/share/ca-certificates/
Updaten Sie den CA Store: sudo update-ca-certificates

Schritt 10: Ändern des DNS-Eintrags
Melden Sie sich bei Ihrem DNS-Anbieter an und ändern Sie den DNS-Eintrag der neuen Domain so, dass er auf die IP-Adresse des App-Servers zeigt.

Schritt 11: Ausführen von setup.sh und Ändern der Domain:
Führen Sie die setup.sh aus und ändern Sie die Domain in den Konfigurationseinstellungen des Skripts auf die neue Domain.

Schritt 12: Ändern der Domain im Policy Manager für den Client:
Wechseln Sie abschließend in der Enginsight Plattform über Hosts in den Policy Manager und ändern Sie dort die Domain des Clients auf Ihre neue Domain.

Beachten Sie, dass die Agents sich nicht mehr melden können, wenn die alte Domain nicht mehr existiert!

Stellen Sie sicher, dass Sie beide Domains parallel für eine gewisse Zeit betreiben, um zu gewährleisten, dass alle Systeme reibungslos funktionieren.

Überprüfen Sie regelmäßig die Funktionsfähigkeit der Agenten, um sicherzustellen, dass sie erfolgreich mit der neuen Domain kommunizieren können.

Best Practice

Damit die beide API Domain für die Zeit der Umstellung erreichbar sind, können Sie die alte Domain parallel im nginx betreiben.

Die Konfiguration würde dann wie folgt aus sehen:

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

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

    server_name neue-ngs-app.domain.de;

    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384";
    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;

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /<PfadzurIhremZertifikat>/<NameZertifikat>.pem;
    ssl_certificate_key /<PfadzurIhremPrivateKey>/<NamePrivateKey>.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 neue-ngs-api.domain.de;

    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384";
    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;

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /<PfadzurIhremZertifikat>/<NameZertifikat>.pem;
    ssl_certificate_key /<PfadzurIhremPrivateKey>/<NamePrivateKey>.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;
    }
}

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

  server_name alte-ngs-api.domain.de;

    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384";
    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;

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /<PfadzurIhremAltenZertifikat>/<NameAltesZertifikat>.pem;
    ssl_certificate_key /<PfadzurIhremAltenPrivateKey>/<NameAlterPrivateKey>.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;
    }
}