SSL-Verschlüsselung mit Let’s Encrypt (Nginx)
An old documentation with Apache as reverse proxy can be found here.
This article (as of February 2022) technically refers to a standard package installation (in the example on Debian 11) of EGroupware in an environment shown here.
As reverse proxy, Nginx is installed/configured/used in the standard.
Access to EGroupware should ALWAYS be encrypted. This means that the web address should start with https://.
Reasons
- The communication between the web browser and the EGroupware server is tap-proof.
-
The access data is transmitted in encrypted form.
- The synchronisation with iOS requires SSL encryption
-
Communication of EGroupware with other services (Collabora Online, …) requires SSL encryption!
Thus, the reverse proxy (NOT the Nginx in the Docker container!, see Docker (in EGroupware 19.1)) must be equipped with an SSL configuration and a certificate. This should definitely also be taken into account if EGroupware is operated exclusively in a local network.
The SSL certificate must be able to be validated by remote stations! This concerns the web browsers as well as other installed services (Collabora Online, …). These have lists of trusted certificate issuers (CA) in their containers. Even signed certificates will not be recognised by these systems. They cannot! Unless you implant the root certificate anew in each container after each new container/update. You don’t want to do that to yourself…
The simplest solution in a standard installation is to use certificates from Let’s Encrypt. With the help of a client, the certificate is generated, copied to the server and the configuration of the web server is carried out.
Web browsers and systems in containers trust the certificates issued by Let’s Encrypt. Other certificates issued by public CAs can of course also be used.
The most common ACME client is certbot. With certbot, free certificates can be easily installed and regular updates are automated. That is why certbot is our recommendation.
Installation
Certbot needs a correct configuration of the web server with a (the) domain address (see below). In this case in the
/etc/egroupware-docker/nginx.conf
After the server name entry, Nginx must be restarted:
service nginx restart
In Debian (11/12), the Let’s Encrypt client (Certbot) can be installed directly:
apt install certbot python3-certbot-nginx
Then run Certbot:
certbot --nginx
An interactive query of some data follows. Finally, only the domain must be selected.
An e-mail address is requested. You should enter a valid e-mail address. This way, you will be notified if a certificate expires or other important things change. If you don’t want to do that, you can abort the job with c and call certbot without an email query:
certbot --nginx --register-unsafely-without-email.
EGroupware should now be accessible via https. The automatic forwarding to https should also work.
Domain(-name)
The prerequisite is ALWAYS that the EGroupware server can be reached under a domain name. An IP address does not work!
For this, it is advisable to book a package with a domain with a provider. This provider must allow that this domain or a created sub-domain can be assigned a fixed IP (A-Record) or that one can provide the domain with a dynamic address. This can be done by the local router or a software on the server (e.g. ddclient).
Let’s Encrypt issues domain-validated certificates. This means that Let’s Encrypt checks the reachability (on port 80, unencrypted) of the domain (therefore domain name, not IP).
Ports 80 and 443 must be forwarded on the router for the EGroupware server to be accessible.
If necessary, the geo-IP blocker for the USA must be deactivated on the router/firewall. The servers are located there.
Likewise, the firewall that may have been set up/activated on the server must be configured accordingly so that port 80 is also allowed through in addition to port 443.
The web server is configured by Certbot so that later requests under http are forwarded to https. This means that you do not need to enter https when typing in the address and prevents an unintentionally unencrypted connection.
The Let’s Encrypt certificates have a validity period of 3 months. Before expiry, the certificates must be renewed. This happens automatically with the installation described above. The prerequisite is that the service is not deactivated and the server can still be reached on port 80.
Before the deadline expires, you will receive a notification e-mail at the specified e-mail address that the certificate is about to expire. If the automatic function did not work or ports have to be opened manually.
Optional configuration
The connection between the web proxy and the web browser is now SSL-encrypted. However, the quality of the encryption can usually be increased.
The quality of the encryption can be tested here, for example:
https://www.ssllabs.com/ssltest/
With the standard settings, one already achieves a good A rating:
The settings are already very well chosen and do not necessarily have to be changed. The evaluation should be repeated from time to time. The evaluation criteria continue to develop and you can see if there is room for improvement.
If you now add HSTS in
/etc/egroupware-docker/nginx.conf
, you will get switch on:
add_header Strict-Transport-Security max-age=31536000; # 31536000sec=1year
(we have prepared: just comment)
an A+ rating is achievable:
Also in the
/etc/egroupware-docker/nginx.conf
you can switch on HTTP/2:
This brings speed advantages in the transmission to the browser.
For further suggestions, please create a topic here in the forum.
As always, make a backup of the web server configurations BEFORE!
No guarantee for the above! Things can change…
Further links:
Let’s Encrypt
Let’s Encrypt documentation
Certbot documentation
