...
 
Commits (2)
......@@ -80,14 +80,16 @@ precheck:masterchecks:
- '[[ ! -f enforce-insecure ]] || (echo "File enforce-insecure is not supported in master branch"; exit 99)'
- '[[ ! -f enforce-new-password ]] || (echo "File enforce-new-password is not supported in master branch"; exit 99)'
only:
refs:
- master
- master
- web
- schedules
build:stage:
extends: .tpl:build
except:
refs:
- master
- master
- web
- schedules
variables:
buildopts: '--config ./src/_config.yml,./src/_config_staging.yml --baseurl /${CI_COMMIT_REF_SLUG}'
distname: "stage"
......@@ -95,8 +97,9 @@ build:stage:
build:prod:
extends: .tpl:build
only:
refs:
- master
- master
- web
- schedules
variables:
buildopts: "--config ./src/_config.yml"
distname: "prod"
......@@ -112,8 +115,9 @@ deploy:stage:
only:
- branches
except:
refs:
- master
- master
- web
- schedules
variables:
secure: '1'
distname: "stage"
......@@ -125,8 +129,9 @@ deploy:live:
name: Live
url: "https://serverless.industries/"
only:
refs:
- master
- master
- web
- schedules
variables:
secure: '0'
distname: "prod"
......@@ -144,5 +149,7 @@ cleanup:stage:
- branches
except:
- master
- web
- schedules
variables:
remotedir: '${stagedir}/${CI_COMMIT_REF_SLUG}'
---
author: christian
title: NGINX und Certificate Chains Theorie
language: german
tags: [linux, http, nginx, tls]
---
Jeder Serverdienst welcher TLS Verbindungen verwendet muss
neben dem eigentlichen Server Zertifikat auch alle Intermediate
Zertifikate[^2] an den Client schicken, da diese nicht auf dem Client
installiert sind.
Dort ist nur das Root Zertifikat[^1] der genutzten
Certificate Authority[^3] installiert, durch das die gesamte Kette an
Zertifikaten geprüft werden kann.
Beispiel einer Zertifikatskette:
```
DigiCert Baltimore Root // <-- Root Cert (lokaler Store)
'- Microsoft IT TLS CA 4 // <-- Intermediate Cert (vom Server gesendet)
'- *.visualstudio.com // <-- Server Zertifikat (vom Server gesendet)
```
Welche Zertifikate vom Server gesendet werden, kann man
übrigens mit openssl prüfen:
```sh
openssl s_client -showcerts -connect sample.visualstudio.com:443
```
Für jedes Zertifikat gibt es in der Ausgabe folgende Passage:
```
# s = server certificate; i = intermediate certificate
Certificate chain
0 s:CN = visualstudio.com
i:C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = Microsoft IT, CN = Microsoft IT TLS CA 4
```
## Zertifikat für NGINX
NGINX erwartet eine einfache Textdatei welche neben dem
Serverzertifikat alle Intermediate Zertifikate enthält.
Die einzelnen Zertifikatsblöcke werden einfach untereinander
in die Datei eingefügt.
```sh
cat sample.visualstudio.com.pem microsoft-intermediate.pem > sample.visualstudio.com-bundle.pem
```
Alternativ zum Linux Werkzeug `cat` können die Zertifikate natürlich
manuell im Texteditor zusammenkopiert werden.
Die Bundle Datei wird dann wie folgt in NGINX eingebunden:
```
server {
server_name sample.visualstudio.com;
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_certificate /etc/ssl/sample.visualstudio.com-bundle.pem;
ssl_certificate_key /etc/ssl/sample.visualstudio.com-key.pem;
[...]
}
```
Viele andere Server Dienste machen das übrigens genauso.
-----
[^1]: **Root Certificate:** Selbstsigniertes Zertifikat welches
in den Browser importiert werden muss. Kann Zwischenzertifikate
und Server-/Clientzertifikate ausstellen.
[^2]: **Intermediate Certificate:** Zwischenzertifikat welches von
von einem anderen Zwischenzertifikat oder einem Root
Zertifikat signiert wurde. Kann je nach Festlegung bei Ausstellung
weitere Zwischenzertifikate und Server-/Clientzertifikate ausstellen.
[^3]: **Certificate Authority:** Eine Organisation welche für das signieren
von Zertifikaten zuständig ist. Die Organisation übernimmt die Aufgabe
der vertrauenwürdigen Stelle.
---
author: christian
title: NGINX Reverse Proxy durch Forward Proxy
language: german
tags: [http, nginx]
---
NGINX Webserver welche innerhalb eines Firmennetzwerks
laufen und mit einem Corporate Proxy vom Internet isoliert sind,
haben normalerweise keine direkte Verbindung zum Internet.
Möchte man nun einen Reverse Proxy erstellen, welcher Requests
auf externe APIs/Webservices cached, hilft folgender Hack:
```
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name webserviceproxy.serverless.industries;
ssl_certificate /etc/ssl/http/bundle_serverless.industries.cert;
ssl_certificate_key /etc/ssl/http/serverless.industries.key;
location / {
proxy_set_header Host webservice.example.com;
proxy_pass http://corporate-proxy.serverless.industries:8080;
}
}
```
Die eigentliche Verbindung wird direkt zum Proxy (`proxy_pass`) aufgebaut.
Allerdings wird mit der `proxy_set_header` Direktive der `Host`
Header überschrieben, sodass der Proxy weiß, an welchen
Service die eingehende Anfrage weitergeleitet werden muss.
Disclaimer: Ich habe das bisher nur mit RESTful APIs genutzt.
Keine Ahnung was passiert, wenn man so eine komplette Website
verarbeiten will.
---
author: christian
title: Query String Parameter in den Header mit NGINX
language: german
tags: [http, nginx]
---
Um Requests an eine externe API besser zu cachen
nutzen wir einen NGINX Reverse Proxy und haben Query
Parameter wie den API Key in den Header verschoben.
Egal wie viele unterschiedliche API Keys in Benutzung
sind, das Request wird nur einmalig ausgeführt und dann
gecached.
Der API Key wird vor der Ausführung des `proxy_pass`
an den Query String gehängt.
```
location / {
# Add the APP ID and the APP key to the query string
set $originalargs $args;
set $args $args&app_id=$http_x_app_id&app_key=$http_x_app_key;
# check for credencials in query string and abort
if ( $originalargs ~ "(.*)(app_id|app_key)=([^&]*)(.*)" ) {
# using the (debian/ubuntu) package libnginx-mod-http-headers-more-filter
more_set_headers "Content-Type: application/json; charset=UTF-8";
return 400 "{\"error\": \"app_id or app_key was specified as GET argument. These have to be specified with the X-App-ID and X-App-Key header instead.\"}";
}
proxy_cache awesomeapicache;
# append the querystring without credencials to the cache key
proxy_cache_key $request_uri$is_args$originalargs;
# Remove custom headers for upstream API
proxy_set_header X-App-ID "";
proxy_set_header X-App-Key "";
# Hide User-Agent for Upstream API
proxy_set_header User-Agent "curl/7.47.0";
# Forwarding of request
proxy_pass http://awesomeapi.example.com;
}
```