(zettel (meta (back "00001010000000 00001018000000") (backward "00001004010000 00001010000000 00001018000000") (box-number "1") (created "20210126175322") (forward "00001003000000 00001004010000") (modified "20220217180826") (published "20220217180826") (role "manual") (syntax "zmk") (tags "#configuration #encryption #manual #security #zettelstore") (title "External server to encrypt message transport")) (rights 4) (encoding "") (content "Since Zettelstore does not encrypt the messages it exchanges with its clients, you may need some additional software to enable encryption.\n\n=== Public-key encryption\nTo enable encryption, you probably use some kind of encryption keys.\nIn most cases, you need to deploy a \"\"public-key encryption\"\" process, where your side publish a public encryption key that only works with a corresponding private decryption key.\nTechnically, this is not trivial.\nAny client who wants to communicate with your Zettelstore must trust the public encryption key.\nOtherwise the client cannot be sure that it is communication with your Zettelstore.\nThis problem is solved in part with [[Let's Encrypt|https://letsencrypt.org/]],\n\"\"a free, automated, and open certificate authority (CA), run for the public’s benefit.\nIt is a service provided by the [[Internet Security Research Group|https://www.abetterinternet.org/]]\"\".\n\nAlternatively, you can buy these keys for public-key encryption at \"\"certificate authorities\"\" or its dealers.\n\n=== Server software for encryption\nThe solution of placing a server for encryption in front of an encryption-unaware server is a relatively old one.\nThere are many different alternatives to choose.\n\nFirst, there are web servers.\nBusiness-grade web servers must enable encryption.\nMost of them allow to forward a request unencrypted to another web server.\nSome examples:\n\n* [[Apache Web Server|https://httpd.apache.org/]]: enable [[mod_proxy|http://httpd.apache.org/docs/current/mod/mod_proxy.html]] and configure a reverse proxy.\n* [[nginx|https://nginx.org/]]: set-up a reverse proxy with the [[''proxy_pass''|https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass]] directive.\n* [[Caddy|https://caddyserver.com/]]: see below for details.\n\nOther software is also possible.\nThere exists software dedicated for this task of handling the encryption part.\nSome examples:\n\n* [[stunnel|https://www.stunnel.org/]] (\"\"a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code.\"\")\n* [[Traefik|https://traefik.io/]]: set-up a [[router|https://docs.traefik.io/routing/routers/]].\n\n=== Example configuration for Caddy\nFor the inexperienced owner of a Zettelstore, [[Caddy|https://caddyserver.com/]] is a good option[^In fact, the [[server-based installation procedure|00001003000000]] of Zettelstore was inspired by Caddy.].\nCaddy has the capability to automatically fetch appropriately encryption key from Let's Encrypt, without any further configuration.\nThe only requirement of doing this is that the server must be publicly accessible.\n\nHere is the base configuration for the main site for Zettelstore at [[https://zettelstore.de/]]:\n```\nzettelstore.de {\n  reverse_proxy localhost:23123\n}\n```\nThat's all!\n\nIf you want to add some additional content on the server, you could change the configuration as follows:\n```\nzettelstore.de {\n  file_server * {\n    root /var/www/html\n  }\n  route /manual/* {\n    reverse_proxy localhost:23123\n  }\n}\n```\nThis will forwards requests with the prefix \"\"/manual/\"\" to the running Zettelstore.\nAll other requests will be handled by Caddy itself.\n\nIn this case you must specify the [[startup configuration key ''url-prefix''|00001004010000#url-prefix]] with the value \"\"/manual/\"\".\nThis is to allow Zettelstore to ignore the prefix while reading web requests and to give the correct URLs with the given prefix when sending a web response."))