# keel-web: the default site with Anubis in front of it (handbook
# decisions 0030, 0041 step 7, and 0079). Linked from sites-enabled/ in
# place of keel-web's `keel-default` while the anubis overlay is enabled,
# by /usr/lib/keel/overlays/anubis/state.d/50keel-web, which keel spec
# apply runs; never by hand, and never at installation.
#
# The pipeline of 0030: Nginx takes the request (Coraza, when its overlay
# is enabled, inspects it here, in the http block), Anubis decides, and
# what it allows comes back to Nginx on a unix socket, where the content
# is served. Anubis keys on the client's address, which the snippet passes
# in X-Real-IP; the socket trusts that header from unix: only, so nothing
# outside the machine can set it (0042, "Real client IP"). The servers
# that take requests (port 80, port 443, the loopback addresses of port
# 80) include /etc/nginx/snippets/keel-web-front.conf; the server on the
# socket includes /etc/nginx/snippets/keel-web-site.conf, the content of
# keel-default.
#
# Port 80 (decision 0079): while the machine's certificate is self-signed,
# port 80 serves the site through Anubis as 443 does, with no redirect,
# and /usr/lib/keel-web/http-mode has Anubis set its cookies without
# Secure (/etc/anubis/keel-web-http.env): a browser keeps a Secure cookie
# from HTTPS pages only, and without the cookie it never passes the
# challenge. When the certificate is one that a certificate authority
# issued, http-mode links /etc/nginx/keel-web/http-redirect.conf, which
# the public server on port 80 includes, and Anubis's cookies are Secure
# again: port 80 redirects to HTTPS (0042, redirect_http), except ACME's
# http-01 challenges.
#
# ACME's http-01 challenges on port 80 (keel-web 0.4.3): http-mode links
# /etc/nginx/keel-web/front-acme.conf to keel-web's own location for them,
# /etc/nginx/snippets/keel-web-acme.conf, unless a file of
# /etc/nginx/keel-front.d (which this server includes through
# keel-web-front.conf) has a prefix location for
# /.well-known/acme-challenge: a route that serves the challenge itself
# keeps it, and Nginx refuses two such locations in one server. The routes
# of keel-default.d are in the server on keel-app.sock, not here, so they
# do not count for this site.
#
# The loopback addresses of port 80 are this site's (default_server), not
# those of keel-overlay-nginx's conf.d/keel-health.conf, which listens
# there too and gets only a request with no Host. They share the server of
# port 443, which never redirects: so http://127.0.0.1/ reaches the
# application through Anubis, whatever the certificate. Only /keel-health
# is answered without Anubis, 204, and to the loopback only, for the
# manifest's check.
#
# The certificate is the machine's, the `default` of 0042: self-signed by
# keel-host-keys at the first boot until the confconsole Certificate
# screen issues one through ACME, at the same paths. So no HSTS here: over
# a self-signed certificate it locks visitors out (0042, tls.hsts). By
# name or by IP alike: the default server serves both, as the usage screen
# shows the IP. Anubis redirects a solved challenge only to the origin the
# request came to (anubis 1.27.0-0+keel3, REDIRECT_DOMAINS left empty), so
# any name the site is reached by works and no other host can be reached
# through it.
#
# Until keel renders sites of its own (0042), this is the one site Keel
# Web serves in the cloud modes: the pages of keel-default, the default
# site of a simple installation, from /var/www/keel-default, with its 404
# and 50x pages (on the front too, for the errors Nginx answers itself)
# and no server version. The two sites are never enabled together.

server {
	listen [::]:80 default_server;
	listen 80 default_server;
	server_name _;
	server_tokens off;

	# http-redirect.conf while a CA's certificate is in place, else no file
	include /etc/nginx/keel-web/http-*.conf;
	# front-acme.conf, keel-web's location for ACME's challenges, unless a
	# route of keel-front.d has its own; else no file
	include /etc/nginx/keel-web/front-acme*.conf;

	include /etc/nginx/snippets/keel-web-front.conf;
}

server {
	listen [::]:443 ssl default_server;
	listen 443 ssl default_server;
	listen [::1]:80 default_server;
	listen 127.0.0.1:80 default_server;
	http2 on;
	server_name _;
	server_tokens off;

	ssl_certificate /usr/local/share/ca-certificates/cert.crt;
	ssl_certificate_key /etc/ssl/private/cert.key;
	# As common's conf/turnkey.d/zz-ssl-ciphers sets them for every web
	# server of an appliance (Mozilla's "intermediate"): TLS 1.2 and 1.3,
	# and for 1.2 forward secret ciphers only.
	ssl_protocols TLSv1.2 TLSv1.3;
	ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305';
	ssl_prefer_server_ciphers off;

	# TODO(Keel-Linux/tracker#51, decision 0042 tls.hsts): add
	# Strict-Transport-Security once the confconsole Certificate screen has
	# issued a CA's certificate through ACME; never over the self-signed one.
	#
	# A tls-passthrough site of 0042 needs the stream front on port 443:
	# then the two listen lines of port 443 must go, and this server
	# listens behind it on unix:/run/nginx/keel-https.sock
	# (Keel-Linux/tracker#51).

	location = /keel-health {
		allow ::1;
		allow 127.0.0.1;
		deny all;
		# try_files, not return, as keel-health.conf has it: return
		# answers in the rewrite phase, before Coraza sees the request.
		# No file has this name, so the answer is always the 204.
		try_files /.keel-health-is-no-file =204;
	}

	include /etc/nginx/snippets/keel-web-front.conf;
}

server {
	listen unix:/run/nginx/keel-app.sock;
	server_name _;
	server_tokens off;
	set_real_ip_from unix:;
	real_ip_header X-Real-IP;

	include /etc/nginx/snippets/keel-web-site.conf;
}
