Ich setze den NGINX ja gerne sowohl als Web Server als auch als Reverse Proxy ein – fast genauso gerne setzte ich mittlerweile die Let´s Encrypt Zertifikate ein.

Ich hab jab hier schon eine Anleitung geschrieben wie man das auf Ubuntu einrichtet – aber mittlerweile mach ich hauptsächlich Server mit Debian – deshalb hier eine kleine Anleitung wie ich das immer unter Debian konfiguriere:

1) Erstellen eines NGINX-Config-Snippet

wir erstellen einen Config-Datei

vim /etc/nginx/snippets/letsencrypt.conf

und dort einfügen (gegebenfalls das Verzeichnis unter root ändern):

location ^~ /.well-known/acme-challenge/ {
default_type „text/plain“;
root /var/www/letsencrypt;
allow all;
}

und mit :wq abspeichern.

2) Anpassen der bestehenden NGINX-Konfig

Ich konfiguriere eigentlich meine Webseiten immer als HTTPS-only – das heißt jede Anfrage auf Port 80 (HTTP) auf 443 (HTTPS) umgeleitet.

Da die Domänen-Verifizierung von Let´s Encrypt über einen HTTP Aufruf gemacht wird, müssen wir allerdings hier eine Ausnahme erstellen.

Dazu passen wir unsere Webseiten Konfig an:

vim /etc/nginx/sites-available/meineseite

und fügen unser Snippet mittels include in dem Serverteil für HTTP hinzu:

server {
        listen 80;
        listen [::]:80;

        server_name www.meineseite.de;

	include /etc/nginx/snippets/letsencrypt.conf;

        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://www.meineseite.de;}

        error_log  /var/log/nginx/meineseite-error.log;
        access_log /var/log/nginx/meineseite-access.log;
}

Der Serverteil für HTTPS braucht hier nichts angegeben werden – wir haben ja auch noch keine Zertifikate 😉

3) Installieren des Let´s Encrypt Clients

Installation unter Debian 9 (Stretch):

sudo apt-get install certbot

Installation unter Debian 8 (Jessie):

Bei Debian 8 muss der Client über die Backports installiert werden.

Dazu müssen zuerst die Backports in den Apt-Sources eingetragen werden:

sudo vim /etc/apt/sources.list

und dort die Zeile

deb http://ftp.debian.org/debian jessie-backports main

ans Ende anfügen und mit :wq speichern und den vim verlassen.

Danach die Sources updaten:

sudo apt-get update

und mit

sudo apt-get install certbot -t jessie-backports

4) erstellen des root-Verzeichnises für Let´s Encrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Ich vergebe auch noch entsprechende Rechte (meistens läuft der NGINX ja als www-data User bzw. der User ist in der www-data-Gruppe)

sudo chown -R www-data:www-data /var/www/letsencrypt

5) NGINX reload

sudo systemctl reload nginx

6) Let´s Encrypt Client auführen

Jetzt kann der Client ausgeführt werden – hier als Beispiel für die Domänen meineseite.de und www.meineseite.de (mittels -d domain.tld können noch weitere Domains – falls benötigt – hinzugefügt werden)

sudo certbot certonly --webroot -w /var/www/letsencrypt -d meineseite.de -d www.meineseite.de

dann gibt man eine Mail-Adresse ein und bestätigt mit A die Lizenz-Bedingungen.

Falls alles geklappt hat werden jetzt die Zertifikate ausgestellt – zu finden sind die Zertifikate unter /etc/letsencrypt/live/www.meineseite.de

7) HTTPS-Konfig am NGINX

Jetzt müssen wir noch die HTTPS-Konfig mit unseren neuen Zertifikaten hinzufügen bzw. anpassen.

vim /etc/nginx/sites-available/meineseite

und die Zertifikate im der HTTPS Konfiguration angeben

ssl_certificate /etc/letsencrypt/live/www.meineseite.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.meineseite.de/privkey.pem;

mit :wq speichern.

jetzt noch die Konfiguration am NGINX neu laden

systemctl reload nginx

und wir müssten jetzt die Seite mit einem wunderbaren Zertifikat öffnen können 🙂

8) Renew automatisieren

Die Let´s Encrypt Zertifikate haben die Einschränkung, dass sie nur 90 Tage gültig sind. Man kann hier aber über einen cron-job Abhilfe leisten:

sudo crontab -e

und die folgenden Zeilen hinzufügen

30 2 * * 1 certbot renew >> /var/log/le-renew.log
35 2 * * 1 systemctl reload nginx

so wird automatisch das Zertifikat verlängert und die Konfig des NGINX aktualisiert

9) fertig 🙂

Quelle: https://certbot.eff.org/

Wenn man einen UniFi Controller hinter einen ReverseProxy (in meinem Fall einen nginx) betreibt bekommt man oft nach dem einloggen einen WebSocket connection error

Das lässt sich einfach mit einer kleinen Konfig-Änderung am nginx-ReverseProxy beheben:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection „upgrade“;

Diese Zeilen bewirken ein sauberes Weiterleiten von WebSocket-Aufrufen. Nachdem diese Zeilen die die Konfiguration eingetragen und der nginx seine Konfiguration neu geladen hat funktioniert der Aufruf ohne den Fehler 🙂

Hier noch meine nginx-Konfig:

server {
        listen 80;
        listen [::]:80;
 
        server_name unifi.domain.net;
 
        include /etc/nginx/snippets/letsencrypt.conf;
 
        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://unifi.domain.net;}
 
        error_log  /var/log/nginx/unifi-error.log;
        access_log /var/log/nginx/unifi-access.log;
}

server {
listen 443;
listen [::]:443;
server_name unifi.domain.net;

#cipers
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
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 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

# Enable SSL
ssl on;
ssl_certificate /etc/letsencrypt/live/unifi.domain.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/unifi.domain.net/privkey.pem;
ssl_session_timeout 5m;

# Set global proxy settings
proxy_read_timeout      360;

proxy_http_version 1.1;
proxy_pass_request_headers on;

proxy_pass_header       Date;
proxy_pass_header       Server;

proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        Accept-Encoding "";

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

location / {proxy_pass https://localhost:8443;}

error_log /var/log/nginx/unifi-error.log;
access_log /var/log/nginx/unifi-access.log;
}

Quelle: nginx.org

Wenn man einen Nginx als ReverseProxy für einen Upstream-Server verwendet der SNI verwendet (egal ob Apache, IIS, etc) , muss man dies in der Konfiguration des Nginx beachten – sonst klappt die Verbindung nicht und wirft 502-Errors.

Die Konfiguration ist allerdings ganz einfach:

location / {
    proxy_pass https://upstream-server;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
  }

So wird dem Upstream-Server „sauber“ mitgeteilt welche Webseite aufgerufen werden soll.

Und schon klappt der Aufruf über einen Nginx ReverseProxy 🙂

Hier eine kleine Beispiel-Komplett-Konfig:

server {
    listen                  443 ssl; 
    server_name             www.domain.com;
    ssl_certificate         /etc/nginx/ssl/domain/server.crt; 
    ssl_certificate_key     /etc/nginx/ssl/domain/server.key; 

    proxy_read_timeout      360;
    proxy_pass_header       Date;
    proxy_pass_header       Server;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        Accept-Encoding "";


    location / {
    proxy_pass https://1.2.3.4;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
    }

    error_log /var/log/nginx/domain-error.log;
    access_log /var/log/nginx/domain-access.log;
}

Quelle: serverfault.com

Ich setze den NGINX ja gerne sowohl als Web Server als auch als Reverse Proxy ein – fast genauso gerne setzte ich mittlerweile die Let´s Encrypt Zertifikate ein.

Hier eine kleine Anleitung wie ich das immer konfiguriere (Webroot unter Ubuntu):

1) Erstellen eines NGINX-Config-Snippet

wir erstellen einen Config-Datei

vim /etc/nginx/snippets/letsencrypt.conf

und dort einfügen (gegebenfalls das Verzeichnis unter root ändern):

location ^~ /.well-known/acme-challenge/ {
default_type „text/plain“;
root /var/www/letsencrypt;
allow all;
}

und mit :wq abspeichern

2) Anpassen der bestehenden NGINX-Konfig

Ich konfiguriere eigentlich meine Webseiten immer als HTTPS-only – das heißt jede Anfrage auf Port 80 (HTTP) auf 443 (HTTPS) umgeleitet.

Da die Domänen-Verifizierung von Let´s Encrypt über einen HTTP Aufruf gemacht wird, müssen wir allerdings hier eine Ausnahme erstellen.

Dazu passen wir unsere Webseiten Konfig an:

vim /etc/nginx/sites-available/meineseite

und fügen unser Snippet mittels include in dem Serverteil für HTTP hinzu:

server {
        listen 80;
        listen [::]:80;

        server_name www.meineseite.de;

	include /etc/nginx/snippets/letsencrypt.conf;

        # Redirect any HTTP request to HTTPS
        location / {
        return 301 https://www.meineseite.de;}

        error_log  /var/log/nginx/meineseite-error.log;
        access_log /var/log/nginx/meineseite-access.log;
}

Im Serverteil für HTTPS braucht hier nichts angepasst werden 🙂

3) Installieren des Let´s Encrypt Clients

Installation unter Ubuntu ist super einfach:

sudo apt-get install letsencrypt

4) erstellen des root-Verzeichnises für Let´s Encrypt

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Ich vergebe auch noch entsprechende Rechte (meistens läuft der NGINX ja als www-data User bzw. der User ist in der www-data-Gruppe)

sudo chown -R www-data:www-data /var/www/letsencrypt

5) NGINX reload

sudo systemctl reload nginx

6) Let´s Encrypt Client auführen

letsencrypt certonly –webroot -w /var/www/letsencrypt -d www.meineseite.de -d meinerseite.de –email email@meineseite.de –agree-tos

mittels -d domain.tld können noch weitere Domains – falls benötigt – hinzugefügt werden und unbedingt die Email nicht vergessen anzupassen!

Falls alles geklappt hat werden jetzt die Zertifikate ausgestellt – zu finden sind die Zertifikate unter /etc/letsencrypt/live/www.meineseite.de

7) HTTPS-Konfig anpassen

Jetzt müssen wir noch die neuen Zertifikate in die HTTPS-Konfig hinzufügen

vim /etc/nginx/sites-available/meineseite

und die Zertifikate angeben

ssl_certificate /etc/letsencrypt/live/www.meineseite.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.meineseite.de/privkey.pem;

mit :wq speichern – und wir sind fast fertig 🙂

8) Renew automatisieren

Die Let´s Encrypt Zertifikate haben die Einschränkung, dass sie nur 90 Tage gültig sind. Man kann hier aber über einen cron-job Abhilfe leisten:

sudo crontab -e

und die folgenden Zeilen hinzufügen

30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
35 2 * * 1 /bin/systemctl reload nginx

so wird automatisch das Zertifikat verlängert und die Konfig des NGINX aktualisiert

9) fertig 🙂

Quellen:
letsencrypt.org
GitHub

Ich habe ja mal hier beschrieben wie man einen NGNIX-ReverseProxy für EAS (Exchange ActiveSync) und OWA (OutlookWebApp) konfiguriert.

Mit Exchange 2013 wurde MAPI over HTTP eingeführt und spätestens mit Exchange 2016 wird dieses Protokoll für die Verbindung mit Outlook verwendet. Mit wenig Aufwand kann man jetzt den NGINX auch dafür verwenden um externe Outlooks anzubinden – egal ob Outlook 2010, 2013 und auch das neue Outlook 2016.

Damit das sauber – auch über Autodiscover (wichtig für Outlook 2016) – funktioniert sind folgende Vorarbeiten zu beachten:

1) Autodiscover konfigurieren

Ich empfehle die URLs der Virtuellen Verzeichnisse und von Autodiscover auf einen DNS-Namen zu setzten der intern und extern auflösbar ist – z.B. outlook.domain.de und autodiscover.domain.de.

Die URLs am Exchange kann man folgendermaßen am Exchange über die Exchange Management Shell konfigurieren:

Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -ExternalURL „https://outlook.domain.de/OWA“
Set-OWAVirtualDirectory –Identity „OWA (default web site)“ -InternalURL „https://outlook.domain.de/OWA“

Set-OABVirtualDirectory –Identity „OAB (default web site)“ -ExternalURL „https://outlook.domain.de/OAB“
Set-OABVirtualDirectory –Identity „OAB (default web site)“ -InternalURL „https://outlook.domain.de/OAB“

Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -ExternalURL „https://outlook.domain.de/ECP“
Set-ECPVirtualDirectory –Identity „ECP (default web site)“ -InternalURL „https://outlook.domain.de/ECP“

Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -ExternalUrl „https://outlook.domain.de/ews/exchange.asmx“
Set-WebServicesVirtualDirectory –Identity „EWS (default web site)“ -InternalUrl „https://outlook.domain.de/ews/exchange.asmx“

Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -ExternalURL „https://outlook.domain.de/Microsoft-Server-ActiveSync“
Set-ActiveSyncVirtualDirectory –Identity „Microsoft-Server-ActiveSync (default web site)“ -InternalURL https://outlook.domain.de/Microsoft-Server-ActiveSync

Set-ClientAccessServer -AutoDiscoverServiceInternalUri „https://autodiscover.domain.de/Autodiscover/Autodiscover.xml“

Im Zertifikat des Exchanges müssen natürlich auch diese beiden DNS-Namen stehen – in diesem Beispiel also outlook.domain.de und autodiscover.domain.de.

Im internen DNS und im externen DNS müssen die beiden DNS-Namen strong>outlook.domain.de und autodiscover.domain.de eingetragen werden – im internen DNS direkt auf euren Exchange-Server und im externen auf die öffentliche IP des ReverseProxys.

2) IIS am Exchange konfigurieren

Damit über den ReverseProxy z.B. auch der Abwesenheitsassistent (Out of Office) und die E-Mail-Infos funktionieren, muss am IIS des Exchanges im EWS und im MAPI die Standardauthentifizierung aktiviert werden:

EWS-Standardauth-aktivieren

3) NGINX-Konfig

Die Grundinstallation ist ja schon hier beschreiben.

Für mein Beispiel muss das Zertifikat für den NGINX muss outlook.domain.de und autodiscover.domain.de enthalten. Der interne Exchange ist hier im Beispiel der exch2016.test.local.

Hier ist dann die Konfig für den ReverseProxy:


#Abschnitt 1
server {
        listen       80;
        server_name outlook.domain.de autodiscover.domain.de;

        # Redirect any HTTP request to HTTPS
        return 301 https://$server_name$request_uri;

        error_log  /var/log/nginx/exchange-error.log;
        access_log /var/log/nginx/exchange-access.log;
}

#Abschnitt 2
server {
        listen       443;
        server_name outlook.domain.de autodiscover.domain.de;

        # Enable SSL
        ssl                     on;
        ssl_certificate         /etc/nginx/certs/cert.crt;
        ssl_certificate_key     /etc/nginx/certs/cert.key;
        ssl_session_timeout     5m;

        # Set global proxy settings
        proxy_read_timeout      360;

        proxy_http_version 1.1;
        proxy_pass_request_headers on;

        proxy_pass_header       Date;
        proxy_pass_header       Server;

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Accept-Encoding "";

        more_set_input_headers 'Authorization: $http_authorization';
        proxy_set_header Accept-Encoding "";
        more_set_headers -s 401 'WWW-Authenticate: Basic realm="exch2016.test.local"';

        location /owa           { proxy_pass https://exch2016.test.local/owa; }
        location /OWA           { proxy_pass https://exch2016.test.local/owa; }        
        location /EWS          { proxy_pass https://exch2016.test.local/EWS; }
        location /ews          { proxy_pass https://exch2016.test.local/EWS; }        
        location /Microsoft-Server-ActiveSync { proxy_pass https://exch2016.test.local/Microsoft-Server-ActiveSync; }
        location /mapi           { proxy_pass https://exch2016.test.local/mapi; }
        location /MAPI          { proxy_pass https://exch2016.test.local/mapi; }        
        location /rpc           { proxy_pass https://exch2016.test.local/Rpc; }
        location /RPC           { proxy_pass https://exch2016.test.local/Rpc; }        
        location /oab            { proxy_pass https://exch2016.test.local/OAB; }
        location /OAB            { proxy_pass https://exch2016.test.local/OAB; }        
        location /autodiscover           { proxy_pass https://exch2016.test.local/Autodiscover; }
        location /Autodiscover           { proxy_pass https://exch2016.test.local/Autodiscover; }

        error_log /var/log/nginx/exchange-ssl-error.log;
        access_log /var/log/nginx/exchange-ssl-access.log;
}

Damit hab ich ein Outlook 2016 an einen Exchange 2016 angebunden. Alles funktioniert – auch der Abwesenheitsassistent 🙂

Hilfreiche Quellen:
FrankysWeb
blog.kempkens.io

Ich verwende den Nginx ja wirklich gerne – auch als Reverse Proxy (z.B. für andere Webserver, CMS, und natürlich auch für Exchange).
Dort setzte ich auch gerne Clientzertifikate zur Absicherung ein.
Doch manchmal muss/soll von einer IP der Seitenaufruf aber ohne Clientzertifikat möglich sein…

Ich habe das mit einer if-Abfrage gelöst:

if ($remote_addr = 1.2.3.4 ) 
   {
    proxy_pass http://10.10.10.1; 
    break; 
   }

if ($ssl_client_verify != "SUCCESS") 
   { return 403; }

Hier wird der Aufruf von der IP 1.2.3.4 direkt auf den Webserver mit der IP 10.10.10.1 weitergeleitet und mit dem break wird die weitere Verarbeitung abgebrochen.
Falls die Anfrage nicht von der IP 1.2.3.4 kommt wird überprüft ob eine Authentifizierung mit einem Clientzertifikat stattgefunden hat – und falls das nicht der Fall ist wird eine 403-Seite gezeigt.
Vorraussetztung ist, dass in der Clientzertifikateskonfiguration der Wert ssl_verify_client auf optional steht;

Hier ist eine komplette Beispielkonfiguration für einen Reverse Proxy mit Clientzertifikaten inkl. IP-Ausnahme:

server {
    listen                  443 ssl; 
    server_name             www.domain.com;
    ssl_certificate         /etc/nginx/ssl/domain/server.crt; 
    ssl_certificate_key     /etc/nginx/ssl/domain/server.key; 
    ssl_client_certificate  /etc/nginx/ssl/clients/client_ca.pem
    ssl_verify_client       optional;

    # Set global proxy settings
    proxy_read_timeout      360;
    proxy_pass_header       Date;
    proxy_pass_header       Server;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        Accept-Encoding "";


    location /
    {

    if ($remote_addr = 1.2.3.4 ) 
       {
        proxy_pass http://10.10.10.1; 
        break; 
       }

    if ($ssl_client_verify != "SUCCESS") 
       { return 403; }

    proxy_pass http://10.10.10.1;}

    error_log /var/log/nginx/domain-error.log;
    access_log /var/log/nginx/domain-access.log;
}

Funktioniert einwandfrei 🙂

Quelle: Serverfault

Bei einigen Zertifikaten die im Nginx verwendet werden, ist es notwendig die gesamte Zertifikatskette in dem Zertifikat mit anzugeben.

Das geht super einfach mit cat auf der Konsole:

cat domain.tld.crt sub-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca). Die Stammzertifizierungsstelle (Root-CA) wird meistens nicht benötigt.

Manchmal muss man aber doch auch das Root-CA mit in Kette mit aufnehmen (z.B. bei Zertifikate einer eigenen CA) – dann wäre es:

cat domain.tld.crt sub-ca.cer root-ca.cer > domain-bundle.crt

Erst also das eigentliche Zertifikat für die Domäne (domain.tld) – dann die Zwischenzertifizierungsstelle (sub-ca) und am Schluss die Stammzertifizierungsstelle (root-ca).

Wenn man die Zertifikate von Windows-Systemen bekommt, sollte man alle vorher mit

openssl x509 -inform der -in certificate.cer -out certificate.pem

umwandeln und dann eben mit

cat domain.tld.pem sub-ca.pem root-ca.pem > domain-bundle.crt

weiterverarbeiten.

In der Nginx-Config jetzt enfach das bundle.crt in der Zeile

ssl_certificate /etc/nginx/ssl/domain-bundle.crt;

angeben und nginx dann neustarten.

Seafile ist eine Open Source Software mit der man seine eigene (selbst gehostete) Cloud zum Austausch von Dateien, Zusammenarbeit mit Anderen und noch mehr betreiben kann – eine Alternative zu Diensten wie Dropbox, OneDrive oder Google Drive.

Ich werde hier die Einrichtung von Seafile auf einem Debian-System (aktuell 7.5) mit NGINX als Webserver und MySQL als Datenbank beschreiben. Dazu werde ich noch beschreiben wie man die Zugriffe mit SSL (HTTPS) verschlüsselt und so einen sicheren Zugriff auf die Daten gewährt. Ich mache das hier ein bischen ausführlicher und immer Schritt für Schritt – sollte so für jeden nachzubauen sein weiterlesen

Falls man ActiveSync und OWA anbieten will, sollte dies unbedingt über einen ReverseProxy gelöst werden. Diesen ReverseProxy für die Exchange-Dienste kann man auch mit dem Webserver NGINX auf Linux (in meinem fall Ubuntu Server) lösen. Da Microsoft den TMG eingestellt hat ist diese Kombination auch eine gute Alternative – wenn man auf OutlookAnywhere (RPC over HTTPS) verzichten kann. NGINX unterstützen kein RPCoverHTTPS – das neue MAPIoverHTTPS ist aber möglich – ActiveSync (DirectPush) und OWA funktionieren aber wunderbar.

Hier eine kleine Anleitung wie man dies implementiert.

weiterlesen