nickslowinski/mailcow-dockerized-docs
1
0
Fork 0
Code Issues Pull-Requests Projekte Releases Pakete Wiki Aktivität

Create new folder structure

Quellcode durchsuchen 
No modification of content.
Dieser Commit ist enthalten in:
Raphael 2023-06-13 23:49:47 +02:00
Ursprung 539a9189e1
Commit 2f185bc37c
Es konnte kein GPG-Schlüssel zu dieser Signatur gefunden werden
GPG-Schlüssel-ID: 61F3C93A86B43337
14 geänderte Dateien mit 782 neuen und 783 gelöschten Zeilen
Statistiken anzeigen Patch-Datei herunterladen Diff-Datei herunterladen Alle Dateien ausklappen Alle Dateien einklappen

390
docs/post_installation/firststeps-rp.de.md
Datei anzeigen

@ -1,390 +0,0 @@
Sie müssen die Nginx-Seite, die mit mailcow: dockerized geliefert wird, nicht ändern.
mailcow: dockerized vertraut auf das Standard-Gateway IP 172.22.1.1 als Proxy.
1\. Stellen Sie sicher, dass Sie HTTP_BIND und HTTPS_BIND in `mailcow.conf` auf eine lokale Adresse ändern und die Ports entsprechend einstellen, zum Beispiel:
``` bash
HTTP_BIND=127.0.0.1
HTTP_PORT=8080
HTTPS_BIND=127.0.0.1
HTTPS_PORT=8443
```
Dadurch werden auch die Bindungen innerhalb des Nginx-Containers geändert! Dies ist wichtig, wenn Sie sich entscheiden, einen Proxy innerhalb von Docker zu verwenden.
**WICHTIG:** Verwenden Sie nicht Port 8081, 9081 oder 65510!
Erzeugen Sie die betroffenen Container neu, indem Sie den folgenden Befehl ausführen:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
**Wichtige Informationen, bitte lesen Sie diese sorgfältig durch!**
!!! info
Wenn Sie planen, einen Reverse-Proxy zu verwenden und einen anderen Servernamen als **MAILCOW_HOSTNAME** verwenden wollen, müssen Sie **Zusätzliche Servernamen für mailcow UI** am Ende dieser Seite hinzufügen.
!!! warning "Warnung"
Stellen Sie sicher, dass Sie `generate_config.sh` ausführen, bevor Sie die untenstehenden Konfigurationsbeispiele aktivieren.
Das Skript `generate_config.sh` kopiert die Snake-oil Zertifikate an den richtigen Ort, so dass die Dienste nicht aufgrund fehlender Dateien nicht starten können.
!!! warning "Warnung"
Wenn Sie TLS SNI aktivieren (`ENABLE_TLS_SNI` in mailcow.conf), **müssen** die Zertifikatspfade in Ihrem Reverse-Proxy mit den korrekten Pfaden in data/assets/ssl/{hostname} übereinstimmen. Die Zertifikate werden in `data/assets/ssl/{hostname1,hostname2,etc}` aufgeteilt und werden daher nicht funktionieren, wenn Sie die Beispiele von unten kopieren, die auf `data/assets/ssl/cert.pem` etc. zeigen.
!!! info
Die Verwendung der untenstehenden Site-Konfigurationen wird **acme-Anfragen an mailcow** weiterleiten und es die Zertifikate selbst verwalten lassen.
Der Nachteil der Verwendung von mailcow als ACME-Client hinter einem Reverse-Proxy ist, dass Sie Ihren Webserver neu laden müssen, nachdem acme-mailcow das Zertifikat geändert/erneuert/erstellt hat. Sie können entweder Ihren Webserver täglich neu laden oder ein Skript schreiben, um die Datei auf Änderungen zu überwachen.
Auf vielen Servern wird logrotate den Webserver sowieso täglich neu laden.
Wenn Sie eine lokale Certbot-Installation verwenden möchten, müssen Sie die SSL-Zertifikatsparameter entsprechend ändern.
**Stellen Sie sicher, dass Sie ein Post-Hook-Skript** ausführen, wenn Sie sich entscheiden, externe ACME-Clients zu verwenden. Ein Beispiel finden Sie am Ende dieser Seite.
2\. Konfigurieren Sie Ihren lokalen Webserver als Reverse Proxy:
### Apache 2.4
Erforderliche Module:
```
a2enmod rewrite proxy proxy_http headers ssl
```
Let's Encrypt wird unserem Rewrite folgen, Zertifikatsanfragen in mailcow werden problemlos funktionieren.
**Die hervorgehobenen Zeilen müssen beachtet werden**.
``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
<VirtualHost *:80>
ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
ServerAlias autodiscover.*
ServerAlias autoconfig.*
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>
<VirtualHost *:443>
ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
ServerAlias autodiscover.*
ServerAlias autoconfig.*
# You should proxy to a plain HTTP session to offload SSL processing
ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "https"
SSLCertificateFile MAILCOW_ORDNER/data/assets/ssl/cert.pem
SSLCertificateKeyFile MAILCOW_ORDNER/data/assets/ssl/key.pem
# Wenn Sie einen HTTPS-Host als Proxy verwenden möchten:
#SSLProxyEngine On
# Wenn Sie einen Proxy für einen nicht vertrauenswürdigen HTTPS-Host einrichten wollen:
#SSLProxyVerify none
#SSLProxyCheckPeerCN off
#SSLProxyCheckPeerName off
#SSLProxyCheckPeerExpire off
</VirtualHost>
```
### Nginx
Let's Encrypt folgt unserem Rewrite, Zertifikatsanfragen funktionieren problemlos.
**Achten Sie auf die hervorgehobenen Zeilen**.
``` hl_lines="4 10 12 13 25 39"
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Siehe https://ssl-config.mozilla.org/#server=nginx für die neuesten Empfehlungen zu ssl-Einstellungen
# Ein Beispiel für eine Konfiguration ist unten angegeben
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
ssl_prefer_server_ciphers off;
location /Microsoft-Server-ActiveSync {
proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 75;
proxy_send_timeout 3650;
proxy_read_timeout 3650;
proxy_buffers 64 512k; # Seit dem 2022-04 Update nötig für SOGo
client_body_buffer_size 512k;
client_max_body_size 0;
}
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 0;
# Die folgenden Proxy-Buffer müssen gesetzt werden, wenn Sie SOGo nach dem Update 2022-04 (April 2022) verwenden wollen
# Andernfalls wird ein Login wie folgt fehlschlagen: https://github.com/mailcow/mailcow-dockerized/issues/4537
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
}
}
```
### HAProxy (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Community Beitrag. Korrekturen sind immer erwünscht!
**Wichtig/Fix erwünscht**: Dieses Beispiel leitet nur HTTPS-Verkehr weiter und benutzt nicht den in mailcow eingebauten ACME-Client.
```
frontend https-in
bind :::443 v4v6 ssl crt mailcow.pem
default_backend mailcow
backend mailcow
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
server mailcow 127.0.0.1:8080 check
```
### Traefik v2 (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Community Beitrag. Korrekturen sind immer erwünscht!
**Wichtig**: Diese Konfiguration deckt nur das "Reverseproxing" des Webpanels (nginx-mailcow) unter Verwendung von Traefik v2 ab. Wenn Sie auch die Mail-Dienste wie dovecot, postfix... reproxen wollen, müssen Sie die folgende Konfiguration an jeden Container anpassen und einen [EntryPoint](https://docs.traefik.io/routing/entrypoints/) in Ihrer `traefik.toml` oder `traefik.yml` (je nachdem, welche Konfiguration Sie verwenden) für jeden Port erstellen.
In diesem Abschnitt gehen wir davon aus, dass Sie Ihren Traefik 2 `[certificatesresolvers]` in Ihrer Traefik-Konfigurationsdatei richtig konfiguriert haben und auch acme verwenden. Das folgende Beispiel verwendet Lets Encrypt, aber Sie können es gerne auf Ihren eigenen Zertifikatsresolver ändern. Eine grundlegende Traefik 2 toml-Konfigurationsdatei mit allen oben genannten Elementen, die für dieses Beispiel verwendet werden kann, finden Sie hier [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml), falls Sie eine solche Datei benötigen oder einen Hinweis, wie Sie Ihre Konfiguration anpassen können.
Zuallererst werden wir den acme-mailcow-Container deaktivieren, da wir die von traefik bereitgestellten Zertifikate verwenden werden.
Dazu müssen wir `SKIP_LETS_ENCRYPT=y` in unserer `mailcow.conf` setzen und den folgenden Befehl ausführen, um die Änderungen zu übernehmen:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Dann erstellen wir eine `docker-compose.override.yml` Datei, um die Hauptdatei `docker-compose.yml` zu überschreiben, die sich im mailcow-Stammverzeichnis befindet.
```yaml
version: '2.1'
services:
nginx-mailcow:
networks:
# Traefiks Netzwerk hinzufügen
web:
labels:
- traefik.enable=true
# Erstellt einen Router namens "moo" für den Container und richtet eine Regel ein, um den Container mit einer bestimmten Regel zu verknüpfen,
# in diesem Fall eine Host-Regel mit unserer MAILCOW_HOSTNAME-Variable.
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
# Aktiviert tls über den zuvor erstellten Router.
- traefik.http.routers.moo.tls=true
# Gibt an, welche Art von Cert-Resolver wir verwenden werden, in diesem Fall le (Lets Encrypt).
- traefik.http.routers.moo.tls.certresolver=le
# Erzeugt einen Dienst namens "moo" für den Container und gibt an, welchen internen Port des Containers
# Traefik die eingehenden Daten weiterleiten soll.
- traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
# Gibt an, welchen Eingangspunkt (externer Port) traefik für diesen Container abhören soll.
# Websecure ist Port 443, siehe die Datei traefik.toml wie oben.
- traefik.http.routers.moo.entrypoints=websecure
# Stellen Sie sicher, dass traefik das Web-Netzwerk verwendet, nicht das mailcowdockerized_mailcow-network
- traefik.docker.network=traefik_web
certdumper:
image: humenius/traefik-certs-dumper
command: --restart-containers ${COMPOSE_PROJECT_NAME}-postfix-mailcow-1,${COMPOSE_PROJECT_NAME}-nginx-mailcow-1,${COMPOSE_PROJECT_NAME}-dovecot-mailcow-1
network_mode: none
volumes:
# Binden Sie das Volume, das Traefiks `acme.json' Datei enthält, ein
- acme:/traefik:ro
# SSL-Ordner von mailcow einhängen
- ./data/assets/ssl/:/output:rw
# Binden Sie den Docker Socket ein, damit traefik-certs-dumper die Container neu starten kann
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
environment:
# Ändern Sie dies nur, wenn Sie eine andere Domain für mailcows Web-Frontend verwenden als in der Standard-Konfiguration
- DOMAIN=${MAILCOW_HOSTNAME}
networks:
web:
external: true
# Name des externen Netzwerks
name: traefik_web
volumes:
acme:
external: true
# Name des externen Docker Volumes, welches Traefiks `acme.json' Datei enthält
name: traefik_acme
```
Starten Sie die neuen Container mit:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Da Traefik 2 ein acme v2 Format verwendet, um ALLE Zertifikaten von allen Domains zu speichern, müssen wir einen Weg finden, die Zertifikate auszulagern. Zum Glück haben wir [diesen kleinen Container] (https://hub.docker.com/r/humenius/traefik-certs-dumper), der die Datei `acme.json` über ein Volume und eine Variable `DOMAIN=example. org`, und damit wird der Container die `cert.pem` und `key.pem` Dateien ausgeben, dafür lassen wir einfach den `traefik-certs-dumper` Container laufen, binden das `/traefik` Volume an den Ordner, in dem unsere `acme.json` gespeichert ist, binden das `/output` Volume an unseren mailcow `data/assets/ssl/` Ordner, und setzen die `DOMAIN=example.org` Variable auf die Domain, von der wir die Zertifikate ausgeben wollen.
Dieser Container überwacht die Datei `acme.json` auf Änderungen und generiert die Dateien `cert.pem` und `key.pem` direkt in `data/assets/ssl/`, wobei der Pfad mit dem `/output`-Pfad des Containers verbunden ist.
Sie können es über die Kommandozeile ausführen oder das [hier](https://hub.docker.com/r/humenius/traefik-certs-dumper) gezeigte docker-compose.yml verwenden.
Nachdem wir die Zertifikate übertragen haben, müssen wir die Konfigurationen aus unseren Postfix- und Dovecot-Containern neu laden und die Zertifikate überprüfen. Wie das geht, sehen Sie [hier](https://mailcow.github.io/mailcow-dockerized-docs/de/post_installation/firststeps-ssl/#ein-eigenes-zertifikat-verwenden).
Und das sollte es gewesen sein 😊, Sie können überprüfen, ob der Traefik-Router einwandfrei funktioniert, indem Sie das Dashboard von Traefik / traefik logs / über https auf die eingestellte Domain zugreifen, oder / und HTTPS, SMTP und IMAP mit den Befehlen auf der zuvor verlinkten Seite überprüfen.
### Caddy v2 (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Communitybeitrag. Korrekturen sind immer erwünscht!
Die Konfiguration von Caddy mit mailcow ist sehr simpel.
In der Caddyfile muss einfach nur ein Bereich für den E-Mailserver angelegt werden.
Bspw:
``` hl_lines="1 3 13"
MAILCOW_HOSTNAME autodiscover.MAILCOW_HOSTNAME autoconfig.MAILCOW_HOSTNAME {
log {
output file /var/log/caddy/MAILCOW_HOSTNAME.log {
roll_disabled
roll_size 512M
roll_uncompressed
roll_local_time
roll_keep 3
roll_keep_for 48h
}
}
reverse_proxy 127.0.0.1:HTTP_BIND
}
```
Dies erlaubt es Caddy automatisch die Zertifikate zu erstellen und den Traffic für diese erwähnten Domains anzunehmen und an mailcow weiterzuleiten.
**Wichtig**: Der ACME Client der mailcow muss deaktiviert sein, da es sonst zu Fehlern seitens mailcow kommt.
Da Caddy sich direkt selbst um die Zertifikate kümmert, können wir mit dem folgenden Skript die Caddy generierten Zertifikate in die mailcow inkludieren:
```bash
#!/bin/bash
MD5SUM_CURRENT_CERT=($(md5sum /opt/mailcow-dockerized/data/assets/ssl/cert.pem))
MD5SUM_NEW_CERT=($(md5sum /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt))
if [ $MD5SUM_CURRENT_CERT != $MD5SUM_NEW_CERT ]; then
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.key /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
else
echo "Certs not copied from Caddy (Not needed)"
fi
```
!!! warning "Achtung"
Der Zertifikatspfad von Caddy variiert je nach Installationsart.<br>
Bei diesem Installationsbeispiel wurde Caddy mithilfe des Caddy Repos ([weitere Informationen hier](https://caddyserver.com/docs/install#debian-ubuntu-raspbian)) installiert.<br>
<br>
Um den Caddy Zertifikatspfad auf Ihrem System herauszufinden, genügt ein `find / -name "certificates"`.
Dieses Skript könnte dann als Cronjob jede Stunde aufgerufen werden:
```bash
0 * * * * /bin/bash /path/to/script/deploy-certs.sh >/dev/null 2>&1
```
### Optional: Post-Hook-Skript für nicht-mailcow ACME-Clients
Die Verwendung eines lokalen Certbots (oder eines anderen ACME-Clients) erfordert den Neustart einiger Container, was Sie mit einem Post-Hook-Skript erledigen können.
Stellen Sie sicher, dass Sie die Pfade entsprechend ändern:
```
#!/bin/bash
cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
```
### Hinzufügen weiterer Servernamen für mailcow UI
Wenn Sie vorhaben, einen Servernamen zu verwenden, der nicht `MAILCOW_HOSTNAME` in Ihrem Reverse-Proxy ist, stellen Sie sicher, dass Sie diesen Namen zuerst in mailcow.conf über `ADDITIONAL_SERVER_NAMES` einpflegen. Die Namen müssen durch Kommas getrennt werden und **dürfen** keine Leerzeichen enthalten. Wenn Sie diesen Schritt überspringen, kann es sein, dass mailcow auf Ihren Reverse-Proxy mit einer falschen Seite antwortet.
```
ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
```
Führen Sie zum Anwenden folgendes aus:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```

393
docs/post_installation/firststeps-rp.en.md
Datei anzeigen

@ -1,393 +0,0 @@
You don't need to change the Nginx site that comes with mailcow: dockerized.
mailcow: dockerized trusts the default gateway IP 172.22.1.1 as proxy.
1\. Make sure you change HTTP_BIND and HTTPS_BIND in `mailcow.conf` to a local address and set the ports accordingly, for example:
``` bash
HTTP_BIND=127.0.0.1
HTTP_PORT=8080
HTTPS_BIND=127.0.0.1
HTTPS_PORT=8443
```
This will also change the bindings inside the Nginx container! This is important, if you decide to use a proxy within Docker.
**IMPORTANT:** Do not use port 8081, 9081 or 65510!
Recreate affected containers by running the command:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
**Important information, please read them carefully!**
!!! info
If you plan to use a reverse proxy and want to use another server name that is **not** MAILCOW_HOSTNAME, you need to read **Adding additional server names for mailcow UI** at the bottom of this page.
!!! warning
Make sure you run `generate_config.sh` before you enable any site configuration examples below.
The script `generate_config.sh` copies snake-oil certificates to the correct location, so the services will not fail to start due to missing files.
!!! warning
If you enable TLS SNI (`ENABLE_TLS_SNI` in mailcow.conf), the certificate paths in your reverse proxy **must** match the correct paths in data/assets/ssl/{hostname}. The certificates will be split into `data/assets/ssl/{hostname1,hostname2,etc}` and therefore will not work when you copy the examples from below pointing to `data/assets/ssl/cert.pem` etc.
!!! info
Using the site configs below will **forward ACME requests to mailcow** and let it handle certificates itself.
The downside of using mailcow as ACME client behind a reverse proxy is, that you will need to reload your webserver after acme-mailcow changed/renewed/created the certificate. You can either reload your webserver daily or write a script to watch the file for changes.
On many servers logrotate will reload the webserver daily anyway.
If you want to use a local certbot installation, you will need to change the SSL certificate parameters accordingly.
**Make sure you run a post-hook script** when you decide to use external ACME clients. You will find an example at the bottom of this page.
2\. Configure your local webserver as reverse proxy:
### Apache 2.4
Required modules:
```
a2enmod rewrite proxy proxy_http headers ssl
```
Let's Encrypt will follow our rewrite, certificate requests in mailcow will work fine.
**Take care of highlighted lines.**
``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
<VirtualHost *:80>
ServerName CHANGE_TO_MAILCOW_HOSTNAME
ServerAlias autodiscover.*
ServerAlias autoconfig.*
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>
<VirtualHost *:443>
ServerName CHANGE_TO_MAILCOW_HOSTNAME
ServerAlias autodiscover.*
ServerAlias autoconfig.*
# You should proxy to a plain HTTP session to offload SSL processing
ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "https"
SSLCertificateFile MAILCOW_PATH/data/assets/ssl/cert.pem
SSLCertificateKeyFile MAILCOW_PATH/data/assets/ssl/key.pem
# If you plan to proxy to a HTTPS host:
#SSLProxyEngine On
# If you plan to proxy to an untrusted HTTPS host:
#SSLProxyVerify none
#SSLProxyCheckPeerCN off
#SSLProxyCheckPeerName off
#SSLProxyCheckPeerExpire off
</VirtualHost>
```
### Nginx
Let's Encrypt will follow our rewrite, certificate requests will work fine.
**Take care of highlighted lines.**
``` hl_lines="4 10 12 13 25 39"
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# See https://ssl-config.mozilla.org/#server=nginx for the latest ssl settings recommendations
# An example config is given below
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
ssl_prefer_server_ciphers off;
location /Microsoft-Server-ActiveSync {
proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 75;
proxy_send_timeout 3650;
proxy_read_timeout 3650;
proxy_buffers 64 512k; # Needed since the 2022-04 Update for SOGo
client_body_buffer_size 512k;
client_max_body_size 0;
}
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 0;
# The following Proxy Buffers has to be set if you want to use SOGo after the 2022-04 (April 2022) Update
# Otherwise a Login will fail like this: https://github.com/mailcow/mailcow-dockerized/issues/4537
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
}
}
```
### HAProxy (community supported)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
**Important/Fixme**: This example only forwards HTTPS traffic and does not use mailcows built-in ACME client.
```
frontend https-in
bind :::443 v4v6 ssl crt mailcow.pem
default_backend mailcow
backend mailcow
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
server mailcow 127.0.0.1:8080 check
```
### Traefik v2 (community supported)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
**Important**: This config only covers the "reverseproxing" of the webpannel (nginx-mailcow) using Traefik v2, if you also want to reverseproxy the mail services such as dovecot, postfix... you'll just need to adapt the following config to each container and create an [EntryPoint](https://docs.traefik.io/routing/entrypoints/) on your `traefik.toml` or `traefik.yml` (depending which config you use) for each port.
For this section we'll assume you have your Traefik 2 `[certificatesresolvers]` properly configured on your traefik configuration file, and also using acme, also, the following example uses Lets Encrypt, but feel free to change it to your own cert resolver. You can find a basic Traefik 2 toml config file with all the above implemented which can be used for this example here [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml) if you need one, or a hint on how to adapt your config.
So, first of all, we are going to disable the acme-mailcow container since we'll use the certs that traefik will provide us.
For this we'll have to set `SKIP_LETS_ENCRYPT=y` on our `mailcow.conf`, and run the following command to apply the changes:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Then we'll create a `docker-compose.override.yml` file in order to override the main `docker-compose.yml` found in your mailcow root folder.
```yaml
version: '2.1'
services:
nginx-mailcow:
networks:
# Add Traefik's network
web:
labels:
- traefik.enable=true
# Creates a router called "moo" for the container, and sets up a rule to link the container to certain rule,
# in this case, a Host rule with our MAILCOW_HOSTNAME var.
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
# Enables tls over the router we created before.
- traefik.http.routers.moo.tls=true
# Specifies which kind of cert resolver we'll use, in this case le (Lets Encrypt).
- traefik.http.routers.moo.tls.certresolver=le
# Creates a service called "moo" for the container, and specifies which internal port of the container
# should traefik route the incoming data to.
- traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
# Specifies which entrypoint (external port) should traefik listen to, for this container.
# websecure being port 443, check the traefik.toml file liked above.
- traefik.http.routers.moo.entrypoints=websecure
# Make sure traefik uses the web network, not the mailcowdockerized_mailcow-network
- traefik.docker.network=traefik_web
certdumper:
image: humenius/traefik-certs-dumper
command: --restart-containers ${COMPOSE_PROJECT_NAME}-postfix-mailcow-1,${COMPOSE_PROJECT_NAME}-nginx-mailcow-1,${COMPOSE_PROJECT_NAME}-dovecot-mailcow-1
network_mode: none
volumes:
# Mount the volume which contains Traefik's `acme.json' file
# Configure the external name in the volume definition
- acme:/traefik:ro
# Mount mailcow's SSL folder
- ./data/assets/ssl/:/output:rw
# Mount docker socket to restart containers
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
environment:
# only change this, if you're using another domain for mailcow's web frontend compared to the standard config
- DOMAIN=${MAILCOW_HOSTNAME}
networks:
web:
external: true
# Name of the external network
name: traefik_web
volumes:
acme:
external: true
# Name of the external docker volume which contains Traefik's `acme.json' file
name: traefik_acme
```
Start the new containers with:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Now, there's only one thing left to do, which is setup the certs so that the mail services can use them as well, since Traefik 2 uses an acme v2 format to save ALL the license from all the domains we have, we'll need to find a way to dump the certs, lucky we have [this tiny container](https://hub.docker.com/r/humenius/traefik-certs-dumper) which grabs the `acme.json` file through a volume, and a variable `DOMAIN=example.org`, and with these, the container will output the `cert.pem` and `key.pem` files, for this we'll simply run the `traefik-certs-dumper` container binding the `/traefik` volume to the folder where our `acme.json` is saved, bind the `/output` volume to our mailcow `data/assets/ssl/` folder, and set up the `DOMAIN=example.org` variable to the domain we want the certs dumped from.
This container will watch over the `acme.json` file for any changes, and regenerate the `cert.pem` and `key.pem` files directly into `data/assets/ssl/` being the path binded to the container's `/output` path.
You can use the command line to run it, or use the docker-compose.yml shown [here](https://hub.docker.com/r/humenius/traefik-certs-dumper).
After we have the certs dumped, we'll have to reload the configs from our postfix and dovecot containers, and check the certs, you can see how [here](https://mailcow.github.io/mailcow-dockerized-docs/firststeps-ssl/#how-to-use-your-own-certificate).
Aaand that should be it 😊, you can check if the Traefik router works fine through Traefik's dashboard / traefik logs / accessing the setted domain through https, or / and check HTTPS, SMTP and IMAP through the commands shown on the page linked before.
### Caddy v2 (supported by the community)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
The configuration of Caddy with mailcow is very simple.
In the caddyfile you just have to create a section for the mailserver.
For example
``` hl_lines="1 3 13"
MAILCOW_HOSTNAME autodiscover.MAILCOW_HOSTNAME autoconfig.MAILCOW_HOSTNAME {
log {
output file /var/log/caddy/MAILCOW_HOSTNAME.log {
roll_disabled
roll_size 512M
roll_uncompressed
roll_local_time
roll_keep 3
roll_keep_for 48h
}
}
reverse_proxy 127.0.0.1:HTTP_BIND
}
```
This allows Caddy to automatically create the certificates and accept traffic for these mentioned domains and forward them to mailcow.
**Important**: The ACME client of mailcow must be disabled, otherwise mailcow will fail.
Since Caddy takes care of the certificates itself, we can use the following script to include the Caddy generated certificates into mailcow:
```bash
#!/bin/bash
MD5SUM_CURRENT_CERT=($(md5sum /opt/mailcow-dockerized/data/assets/ssl/cert.pem))
MD5SUM_NEW_CERT=($(md5sum /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt))
if [ $MD5SUM_CURRENT_CERT != $MD5SUM_NEW_CERT ]; then
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.key /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
else
echo "Certs not copied from Caddy (Not needed)"
fi
```
!!! warning "Attention"
Caddy's certificate path varies depending on the installation type.<br>
In this installation example, Caddy was installed using the Caddy repo ([more informations here](https://caddyserver.com/docs/install#debian-ubuntu-raspbian)).<br>
<br>
To find out the Caddy certificate path on your system, just run a `find / -name "certificates"`.
This script could be called as a cronjob every hour:
```bash
0 * * * * /bin/bash /path/to/script/deploy-certs.sh >/dev/null 2>&1
```
### Optional: Post-hook script for non-mailcow ACME clients
Using a local certbot (or any other ACME client) requires to restart some containers, you can do this with a post-hook script.
Make sure you change the paths accordingly:
```
#!/bin/bash
cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
```
### Adding additional server names for mailcow UI
If you plan to use a server name that is not `MAILCOW_HOSTNAME` in your reverse proxy, make sure to populate that name in mailcow.conf via `ADDITIONAL_SERVER_NAMES` first. Names must be separated by commas and **must not** contain spaces. If you skip this step, mailcow may respond to your reverse proxy with an incorrect site.
```
ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
```
Run the following command to apply:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```

53
docs/post_installation/reverse-proxy/r_p-apache24.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,53 @@
### Apache 2.4
Erforderliche Module:
```
a2enmod rewrite proxy proxy_http headers ssl
```
Let's Encrypt wird unserem Rewrite folgen, Zertifikatsanfragen in mailcow werden problemlos funktionieren.
**Die hervorgehobenen Zeilen müssen beachtet werden**.
``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
<VirtualHost *:80>
ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
ServerAlias autodiscover.*
ServerAlias autoconfig.*
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>
<VirtualHost *:443>
ServerName ZU MAILCOW HOSTNAMEN ÄNDERN
ServerAlias autodiscover.*
ServerAlias autoconfig.*
# You should proxy to a plain HTTP session to offload SSL processing
ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "https"
SSLCertificateFile MAILCOW_ORDNER/data/assets/ssl/cert.pem
SSLCertificateKeyFile MAILCOW_ORDNER/data/assets/ssl/key.pem
# Wenn Sie einen HTTPS-Host als Proxy verwenden möchten:
#SSLProxyEngine On
# Wenn Sie einen Proxy für einen nicht vertrauenswürdigen HTTPS-Host einrichten wollen:
#SSLProxyVerify none
#SSLProxyCheckPeerCN off
#SSLProxyCheckPeerName off
#SSLProxyCheckPeerExpire off
</VirtualHost>
```

53
docs/post_installation/reverse-proxy/r_p-apache24.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,53 @@
### Apache 2.4
Required modules:
```
a2enmod rewrite proxy proxy_http headers ssl
```
Let's Encrypt will follow our rewrite, certificate requests in mailcow will work fine.
**Take care of highlighted lines.**
``` apache hl_lines="2 10 11 17 22 23 24 25 30 31"
<VirtualHost *:80>
ServerName CHANGE_TO_MAILCOW_HOSTNAME
ServerAlias autodiscover.*
ServerAlias autoconfig.*
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R=301,L]
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>
<VirtualHost *:443>
ServerName CHANGE_TO_MAILCOW_HOSTNAME
ServerAlias autodiscover.*
ServerAlias autoconfig.*
# You should proxy to a plain HTTP session to offload SSL processing
ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync connectiontimeout=4000
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto "https"
SSLCertificateFile MAILCOW_PATH/data/assets/ssl/cert.pem
SSLCertificateKeyFile MAILCOW_PATH/data/assets/ssl/key.pem
# If you plan to proxy to a HTTPS host:
#SSLProxyEngine On
# If you plan to proxy to an untrusted HTTPS host:
#SSLProxyVerify none
#SSLProxyCheckPeerCN off
#SSLProxyCheckPeerName off
#SSLProxyCheckPeerExpire off
</VirtualHost>
```

65
docs/post_installation/reverse-proxy/r_p-caddy2.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,65 @@
### Caddy v2 (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Communitybeitrag. Korrekturen sind immer erwünscht!
Die Konfiguration von Caddy mit mailcow ist sehr simpel.
In der Caddyfile muss einfach nur ein Bereich für den E-Mailserver angelegt werden.
Bspw:
``` hl_lines="1 3 13"
MAILCOW_HOSTNAME autodiscover.MAILCOW_HOSTNAME autoconfig.MAILCOW_HOSTNAME {
log {
output file /var/log/caddy/MAILCOW_HOSTNAME.log {
roll_disabled
roll_size 512M
roll_uncompressed
roll_local_time
roll_keep 3
roll_keep_for 48h
}
}
reverse_proxy 127.0.0.1:HTTP_BIND
}
```
Dies erlaubt es Caddy automatisch die Zertifikate zu erstellen und den Traffic für diese erwähnten Domains anzunehmen und an mailcow weiterzuleiten.
**Wichtig**: Der ACME Client der mailcow muss deaktiviert sein, da es sonst zu Fehlern seitens mailcow kommt.
Da Caddy sich direkt selbst um die Zertifikate kümmert, können wir mit dem folgenden Skript die Caddy generierten Zertifikate in die mailcow inkludieren:
```bash
#!/bin/bash
MD5SUM_CURRENT_CERT=($(md5sum /opt/mailcow-dockerized/data/assets/ssl/cert.pem))
MD5SUM_NEW_CERT=($(md5sum /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt))
if [ $MD5SUM_CURRENT_CERT != $MD5SUM_NEW_CERT ]; then
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.key /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
else
echo "Certs not copied from Caddy (Not needed)"
fi
```
!!! warning "Achtung"
Der Zertifikatspfad von Caddy variiert je nach Installationsart.<br>
Bei diesem Installationsbeispiel wurde Caddy mithilfe des Caddy Repos ([weitere Informationen hier](https://caddyserver.com/docs/install#debian-ubuntu-raspbian)) installiert.<br>
<br>
Um den Caddy Zertifikatspfad auf Ihrem System herauszufinden, genügt ein `find / -name "certificates"`.
Dieses Skript könnte dann als Cronjob jede Stunde aufgerufen werden:
```bash
0 * * * * /bin/bash /path/to/script/deploy-certs.sh >/dev/null 2>&1
```

63
docs/post_installation/reverse-proxy/r_p-caddy2.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,63 @@
### Caddy v2 (supported by the community)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
The configuration of Caddy with mailcow is very simple.
In the caddyfile you just have to create a section for the mailserver.
For example
``` hl_lines="1 3 13"
MAILCOW_HOSTNAME autodiscover.MAILCOW_HOSTNAME autoconfig.MAILCOW_HOSTNAME {
log {
output file /var/log/caddy/MAILCOW_HOSTNAME.log {
roll_disabled
roll_size 512M
roll_uncompressed
roll_local_time
roll_keep 3
roll_keep_for 48h
}
}
reverse_proxy 127.0.0.1:HTTP_BIND
}
```
This allows Caddy to automatically create the certificates and accept traffic for these mentioned domains and forward them to mailcow.
**Important**: The ACME client of mailcow must be disabled, otherwise mailcow will fail.
Since Caddy takes care of the certificates itself, we can use the following script to include the Caddy generated certificates into mailcow:
```bash
#!/bin/bash
MD5SUM_CURRENT_CERT=($(md5sum /opt/mailcow-dockerized/data/assets/ssl/cert.pem))
MD5SUM_NEW_CERT=($(md5sum /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt))
if [ $MD5SUM_CURRENT_CERT != $MD5SUM_NEW_CERT ]; then
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.crt /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/your.domain.tld/your.domain.tld.key /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
else
echo "Certs not copied from Caddy (Not needed)"
fi
```
!!! warning "Attention"
Caddy's certificate path varies depending on the installation type.<br>
In this installation example, Caddy was installed using the Caddy repo ([more informations here](https://caddyserver.com/docs/install#debian-ubuntu-raspbian)).<br>
<br>
To find out the Caddy certificate path on your system, just run a `find / -name "certificates"`.
This script could be called as a cronjob every hour:
```bash
0 * * * * /bin/bash /path/to/script/deploy-certs.sh >/dev/null 2>&1
```

19
docs/post_installation/reverse-proxy/r_p-haproxy.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,19 @@
### HAProxy (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Community Beitrag. Korrekturen sind immer erwünscht!
**Wichtig/Fix erwünscht**: Dieses Beispiel leitet nur HTTPS-Verkehr weiter und benutzt nicht den in mailcow eingebauten ACME-Client.
```
frontend https-in
bind :::443 v4v6 ssl crt mailcow.pem
default_backend mailcow
backend mailcow
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
server mailcow 127.0.0.1:8080 check
```

19
docs/post_installation/reverse-proxy/r_p-haproxy.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,19 @@
### HAProxy (community supported)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
**Important/Fixme**: This example only forwards HTTPS traffic and does not use mailcows built-in ACME client.
```
frontend https-in
bind :::443 v4v6 ssl crt mailcow.pem
default_backend mailcow
backend mailcow
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
server mailcow 127.0.0.1:8080 check
```

59
docs/post_installation/reverse-proxy/r_p-nginx.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,59 @@
### Nginx
Let's Encrypt folgt unserem Rewrite, Zertifikatsanfragen funktionieren problemlos.
**Achten Sie auf die hervorgehobenen Zeilen**.
``` hl_lines="4 10 12 13 25 39"
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name ZU MAILCOW HOSTNAMEN ÄNDERN autodiscover.* autoconfig.*;
ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Siehe https://ssl-config.mozilla.org/#server=nginx für die neuesten Empfehlungen zu ssl-Einstellungen
# Ein Beispiel für eine Konfiguration ist unten angegeben
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
ssl_prefer_server_ciphers off;
location /Microsoft-Server-ActiveSync {
proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 75;
proxy_send_timeout 3650;
proxy_read_timeout 3650;
proxy_buffers 64 512k; # Seit dem 2022-04 Update nötig für SOGo
client_body_buffer_size 512k;
client_max_body_size 0;
}
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 0;
# Die folgenden Proxy-Buffer müssen gesetzt werden, wenn Sie SOGo nach dem Update 2022-04 (April 2022) verwenden wollen
# Andernfalls wird ein Login wie folgt fehlschlagen: https://github.com/mailcow/mailcow-dockerized/issues/4537
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
}
}
```

59
docs/post_installation/reverse-proxy/r_p-nginx.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,59 @@
### Nginx
Let's Encrypt will follow our rewrite, certificate requests will work fine.
**Take care of highlighted lines.**
``` hl_lines="4 10 12 13 25 39"
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name CHANGE_TO_MAILCOW_HOSTNAME autodiscover.* autoconfig.*;
ssl_certificate MAILCOW_PATH/data/assets/ssl/cert.pem;
ssl_certificate_key MAILCOW_PATH/data/assets/ssl/key.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# See https://ssl-config.mozilla.org/#server=nginx for the latest ssl settings recommendations
# An example config is given below
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5:!SHA1:!kRSA;
ssl_prefer_server_ciphers off;
location /Microsoft-Server-ActiveSync {
proxy_pass http://127.0.0.1:8080/Microsoft-Server-ActiveSync;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 75;
proxy_send_timeout 3650;
proxy_read_timeout 3650;
proxy_buffers 64 512k; # Needed since the 2022-04 Update for SOGo
client_body_buffer_size 512k;
client_max_body_size 0;
}
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 0;
# The following Proxy Buffers has to be set if you want to use SOGo after the 2022-04 (April 2022) Update
# Otherwise a Login will fail like this: https://github.com/mailcow/mailcow-dockerized/issues/4537
proxy_buffer_size 128k;
proxy_buffers 64 512k;
proxy_busy_buffers_size 512k;
}
}
```

104
docs/post_installation/reverse-proxy/r_p-traefik2.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,104 @@
### Traefik v2 (von der Community unterstützt)
!!! warning "Warnung"
Dies ist ein nicht unterstützter Community Beitrag. Korrekturen sind immer erwünscht!
**Wichtig**: Diese Konfiguration deckt nur das "Reverseproxing" des Webpanels (nginx-mailcow) unter Verwendung von Traefik v2 ab. Wenn Sie auch die Mail-Dienste wie dovecot, postfix... reproxen wollen, müssen Sie die folgende Konfiguration an jeden Container anpassen und einen [EntryPoint](https://docs.traefik.io/routing/entrypoints/) in Ihrer `traefik.toml` oder `traefik.yml` (je nachdem, welche Konfiguration Sie verwenden) für jeden Port erstellen.
In diesem Abschnitt gehen wir davon aus, dass Sie Ihren Traefik 2 `[certificatesresolvers]` in Ihrer Traefik-Konfigurationsdatei richtig konfiguriert haben und auch acme verwenden. Das folgende Beispiel verwendet Lets Encrypt, aber Sie können es gerne auf Ihren eigenen Zertifikatsresolver ändern. Eine grundlegende Traefik 2 toml-Konfigurationsdatei mit allen oben genannten Elementen, die für dieses Beispiel verwendet werden kann, finden Sie hier [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml), falls Sie eine solche Datei benötigen oder einen Hinweis, wie Sie Ihre Konfiguration anpassen können.
Zuallererst werden wir den acme-mailcow-Container deaktivieren, da wir die von traefik bereitgestellten Zertifikate verwenden werden.
Dazu müssen wir `SKIP_LETS_ENCRYPT=y` in unserer `mailcow.conf` setzen und den folgenden Befehl ausführen, um die Änderungen zu übernehmen:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Dann erstellen wir eine `docker-compose.override.yml` Datei, um die Hauptdatei `docker-compose.yml` zu überschreiben, die sich im mailcow-Stammverzeichnis befindet.
```yaml
version: '2.1'
services:
nginx-mailcow:
networks:
# Traefiks Netzwerk hinzufügen
web:
labels:
- traefik.enable=true
# Erstellt einen Router namens "moo" für den Container und richtet eine Regel ein, um den Container mit einer bestimmten Regel zu verknüpfen,
# in diesem Fall eine Host-Regel mit unserer MAILCOW_HOSTNAME-Variable.
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
# Aktiviert tls über den zuvor erstellten Router.
- traefik.http.routers.moo.tls=true
# Gibt an, welche Art von Cert-Resolver wir verwenden werden, in diesem Fall le (Lets Encrypt).
- traefik.http.routers.moo.tls.certresolver=le
# Erzeugt einen Dienst namens "moo" für den Container und gibt an, welchen internen Port des Containers
# Traefik die eingehenden Daten weiterleiten soll.
- traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
# Gibt an, welchen Eingangspunkt (externer Port) traefik für diesen Container abhören soll.
# Websecure ist Port 443, siehe die Datei traefik.toml wie oben.
- traefik.http.routers.moo.entrypoints=websecure
# Stellen Sie sicher, dass traefik das Web-Netzwerk verwendet, nicht das mailcowdockerized_mailcow-network
- traefik.docker.network=traefik_web
certdumper:
image: humenius/traefik-certs-dumper
command: --restart-containers ${COMPOSE_PROJECT_NAME}-postfix-mailcow-1,${COMPOSE_PROJECT_NAME}-nginx-mailcow-1,${COMPOSE_PROJECT_NAME}-dovecot-mailcow-1
network_mode: none
volumes:
# Binden Sie das Volume, das Traefiks `acme.json' Datei enthält, ein
- acme:/traefik:ro
# SSL-Ordner von mailcow einhängen
- ./data/assets/ssl/:/output:rw
# Binden Sie den Docker Socket ein, damit traefik-certs-dumper die Container neu starten kann
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
environment:
# Ändern Sie dies nur, wenn Sie eine andere Domain für mailcows Web-Frontend verwenden als in der Standard-Konfiguration
- DOMAIN=${MAILCOW_HOSTNAME}
networks:
web:
external: true
# Name des externen Netzwerks
name: traefik_web
volumes:
acme:
external: true
# Name des externen Docker Volumes, welches Traefiks `acme.json' Datei enthält
name: traefik_acme
```
Starten Sie die neuen Container mit:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Da Traefik 2 ein acme v2 Format verwendet, um ALLE Zertifikaten von allen Domains zu speichern, müssen wir einen Weg finden, die Zertifikate auszulagern. Zum Glück haben wir [diesen kleinen Container] (https://hub.docker.com/r/humenius/traefik-certs-dumper), der die Datei `acme.json` über ein Volume und eine Variable `DOMAIN=example. org`, und damit wird der Container die `cert.pem` und `key.pem` Dateien ausgeben, dafür lassen wir einfach den `traefik-certs-dumper` Container laufen, binden das `/traefik` Volume an den Ordner, in dem unsere `acme.json` gespeichert ist, binden das `/output` Volume an unseren mailcow `data/assets/ssl/` Ordner, und setzen die `DOMAIN=example.org` Variable auf die Domain, von der wir die Zertifikate ausgeben wollen.
Dieser Container überwacht die Datei `acme.json` auf Änderungen und generiert die Dateien `cert.pem` und `key.pem` direkt in `data/assets/ssl/`, wobei der Pfad mit dem `/output`-Pfad des Containers verbunden ist.
Sie können es über die Kommandozeile ausführen oder das [hier](https://hub.docker.com/r/humenius/traefik-certs-dumper) gezeigte docker-compose.yml verwenden.
Nachdem wir die Zertifikate übertragen haben, müssen wir die Konfigurationen aus unseren Postfix- und Dovecot-Containern neu laden und die Zertifikate überprüfen. Wie das geht, sehen Sie [hier](https://mailcow.github.io/mailcow-dockerized-docs/de/post_installation/firststeps-ssl/#ein-eigenes-zertifikat-verwenden).
Und das sollte es gewesen sein 😊, Sie können überprüfen, ob der Traefik-Router einwandfrei funktioniert, indem Sie das Dashboard von Traefik / traefik logs / über https auf die eingestellte Domain zugreifen, oder / und HTTPS, SMTP und IMAP mit den Befehlen auf der zuvor verlinkten Seite überprüfen.

108
docs/post_installation/reverse-proxy/r_p-traefik2.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,108 @@
### Traefik v2 (community supported)
!!! warning
This is an unsupported community contribution. Feel free to provide fixes.
**Important**: This config only covers the "reverseproxing" of the webpannel (nginx-mailcow) using Traefik v2, if you also want to reverseproxy the mail services such as dovecot, postfix... you'll just need to adapt the following config to each container and create an [EntryPoint](https://docs.traefik.io/routing/entrypoints/) on your `traefik.toml` or `traefik.yml` (depending which config you use) for each port.
For this section we'll assume you have your Traefik 2 `[certificatesresolvers]` properly configured on your traefik configuration file, and also using acme, also, the following example uses Lets Encrypt, but feel free to change it to your own cert resolver. You can find a basic Traefik 2 toml config file with all the above implemented which can be used for this example here [traefik.toml](https://github.com/Frenzoid/TraefikBasicConfig/blob/master/traefik.toml) if you need one, or a hint on how to adapt your config.
So, first of all, we are going to disable the acme-mailcow container since we'll use the certs that traefik will provide us.
For this we'll have to set `SKIP_LETS_ENCRYPT=y` on our `mailcow.conf`, and run the following command to apply the changes:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Then we'll create a `docker-compose.override.yml` file in order to override the main `docker-compose.yml` found in your mailcow root folder.
```yaml
version: '2.1'
services:
nginx-mailcow:
networks:
# Add Traefik's network
web:
labels:
- traefik.enable=true
# Creates a router called "moo" for the container, and sets up a rule to link the container to certain rule,
# in this case, a Host rule with our MAILCOW_HOSTNAME var.
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
# Enables tls over the router we created before.
- traefik.http.routers.moo.tls=true
# Specifies which kind of cert resolver we'll use, in this case le (Lets Encrypt).
- traefik.http.routers.moo.tls.certresolver=le
# Creates a service called "moo" for the container, and specifies which internal port of the container
# should traefik route the incoming data to.
- traefik.http.services.moo.loadbalancer.server.port=${HTTP_PORT}
# Specifies which entrypoint (external port) should traefik listen to, for this container.
# websecure being port 443, check the traefik.toml file liked above.
- traefik.http.routers.moo.entrypoints=websecure
# Make sure traefik uses the web network, not the mailcowdockerized_mailcow-network
- traefik.docker.network=traefik_web
certdumper:
image: humenius/traefik-certs-dumper
command: --restart-containers ${COMPOSE_PROJECT_NAME}-postfix-mailcow-1,${COMPOSE_PROJECT_NAME}-nginx-mailcow-1,${COMPOSE_PROJECT_NAME}-dovecot-mailcow-1
network_mode: none
volumes:
# Mount the volume which contains Traefik's `acme.json' file
# Configure the external name in the volume definition
- acme:/traefik:ro
# Mount mailcow's SSL folder
- ./data/assets/ssl/:/output:rw
# Mount docker socket to restart containers
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: always
environment:
# only change this, if you're using another domain for mailcow's web frontend compared to the standard config
- DOMAIN=${MAILCOW_HOSTNAME}
networks:
web:
external: true
# Name of the external network
name: traefik_web
volumes:
acme:
external: true
# Name of the external docker volume which contains Traefik's `acme.json' file
name: traefik_acme
```
Start the new containers with:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
Now, there's only one thing left to do, which is setup the certs so that the mail services can use them as well, since Traefik 2 uses an acme v2 format to save ALL the license from all the domains we have, we'll need to find a way to dump the certs, lucky we have [this tiny container](https://hub.docker.com/r/humenius/traefik-certs-dumper) which grabs the `acme.json` file through a volume, and a variable `DOMAIN=example.org`, and with these, the container will output the `cert.pem` and `key.pem` files, for this we'll simply run the `traefik-certs-dumper` container binding the `/traefik` volume to the folder where our `acme.json` is saved, bind the `/output` volume to our mailcow `data/assets/ssl/` folder, and set up the `DOMAIN=example.org` variable to the domain we want the certs dumped from.
This container will watch over the `acme.json` file for any changes, and regenerate the `cert.pem` and `key.pem` files directly into `data/assets/ssl/` being the path binded to the container's `/output` path.
You can use the command line to run it, or use the docker-compose.yml shown [here](https://hub.docker.com/r/humenius/traefik-certs-dumper).
After we have the certs dumped, we'll have to reload the configs from our postfix and dovecot containers, and check the certs, you can see how [here](https://mailcow.github.io/mailcow-dockerized-docs/firststeps-ssl/#how-to-use-your-own-certificate).
Aaand that should be it 😊, you can check if the Traefik router works fine through Traefik's dashboard / traefik logs / accessing the setted domain through https, or / and check HTTPS, SMTP and IMAP through the commands shown on the page linked before.

90
docs/post_installation/reverse-proxy/r_p.de.md Normale Datei
Datei anzeigen

@ -0,0 +1,90 @@
Sie müssen die Nginx-Seite, die mit mailcow: dockerized geliefert wird, nicht ändern.
mailcow: dockerized vertraut auf das Standard-Gateway IP 172.22.1.1 als Proxy.
1\. Stellen Sie sicher, dass Sie HTTP_BIND und HTTPS_BIND in `mailcow.conf` auf eine lokale Adresse ändern und die Ports entsprechend einstellen, zum Beispiel:
``` bash
HTTP_BIND=127.0.0.1
HTTP_PORT=8080
HTTPS_BIND=127.0.0.1
HTTPS_PORT=8443
```
Dadurch werden auch die Bindungen innerhalb des Nginx-Containers geändert! Dies ist wichtig, wenn Sie sich entscheiden, einen Proxy innerhalb von Docker zu verwenden.
**WICHTIG:** Verwenden Sie nicht Port 8081, 9081 oder 65510!
Erzeugen Sie die betroffenen Container neu, indem Sie den folgenden Befehl ausführen:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
**Wichtige Informationen, bitte lesen Sie diese sorgfältig durch!**
!!! info
Wenn Sie planen, einen Reverse-Proxy zu verwenden und einen anderen Servernamen als **MAILCOW_HOSTNAME** verwenden wollen, müssen Sie **Zusätzliche Servernamen für mailcow UI** am Ende dieser Seite hinzufügen.
!!! warning "Warnung"
Stellen Sie sicher, dass Sie `generate_config.sh` ausführen, bevor Sie die untenstehenden Konfigurationsbeispiele aktivieren.
Das Skript `generate_config.sh` kopiert die Snake-oil Zertifikate an den richtigen Ort, so dass die Dienste nicht aufgrund fehlender Dateien nicht starten können.
!!! warning "Warnung"
Wenn Sie TLS SNI aktivieren (`ENABLE_TLS_SNI` in mailcow.conf), **müssen** die Zertifikatspfade in Ihrem Reverse-Proxy mit den korrekten Pfaden in data/assets/ssl/{hostname} übereinstimmen. Die Zertifikate werden in `data/assets/ssl/{hostname1,hostname2,etc}` aufgeteilt und werden daher nicht funktionieren, wenn Sie die Beispiele von unten kopieren, die auf `data/assets/ssl/cert.pem` etc. zeigen.
!!! info
Die Verwendung der untenstehenden Site-Konfigurationen wird **acme-Anfragen an mailcow** weiterleiten und es die Zertifikate selbst verwalten lassen.
Der Nachteil der Verwendung von mailcow als ACME-Client hinter einem Reverse-Proxy ist, dass Sie Ihren Webserver neu laden müssen, nachdem acme-mailcow das Zertifikat geändert/erneuert/erstellt hat. Sie können entweder Ihren Webserver täglich neu laden oder ein Skript schreiben, um die Datei auf Änderungen zu überwachen.
Auf vielen Servern wird logrotate den Webserver sowieso täglich neu laden.
Wenn Sie eine lokale Certbot-Installation verwenden möchten, müssen Sie die SSL-Zertifikatsparameter entsprechend ändern.
**Stellen Sie sicher, dass Sie ein Post-Hook-Skript** ausführen, wenn Sie sich entscheiden, externe ACME-Clients zu verwenden. Ein Beispiel finden Sie am Ende dieser Seite.
2\. Konfigurieren Sie Ihren lokalen Webserver als Reverse Proxy:
### Optional: Post-Hook-Skript für nicht-mailcow ACME-Clients
Die Verwendung eines lokalen Certbots (oder eines anderen ACME-Clients) erfordert den Neustart einiger Container, was Sie mit einem Post-Hook-Skript erledigen können.
Stellen Sie sicher, dass Sie die Pfade entsprechend ändern:
```
#!/bin/bash
cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
```
### Hinzufügen weiterer Servernamen für mailcow UI
Wenn Sie vorhaben, einen Servernamen zu verwenden, der nicht `MAILCOW_HOSTNAME` in Ihrem Reverse-Proxy ist, stellen Sie sicher, dass Sie diesen Namen zuerst in mailcow.conf über `ADDITIONAL_SERVER_NAMES` einpflegen. Die Namen müssen durch Kommas getrennt werden und **dürfen** keine Leerzeichen enthalten. Wenn Sie diesen Schritt überspringen, kann es sein, dass mailcow auf Ihren Reverse-Proxy mit einer falschen Seite antwortet.
```
ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
```
Führen Sie zum Anwenden folgendes aus:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```

90
docs/post_installation/reverse-proxy/r_p.en.md Normale Datei
Datei anzeigen

@ -0,0 +1,90 @@
You don't need to change the Nginx site that comes with mailcow: dockerized.
mailcow: dockerized trusts the default gateway IP 172.22.1.1 as proxy.
1\. Make sure you change HTTP_BIND and HTTPS_BIND in `mailcow.conf` to a local address and set the ports accordingly, for example:
``` bash
HTTP_BIND=127.0.0.1
HTTP_PORT=8080
HTTPS_BIND=127.0.0.1
HTTPS_PORT=8443
```
This will also change the bindings inside the Nginx container! This is important, if you decide to use a proxy within Docker.
**IMPORTANT:** Do not use port 8081, 9081 or 65510!
Recreate affected containers by running the command:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```
**Important information, please read them carefully!**
!!! info
If you plan to use a reverse proxy and want to use another server name that is **not** MAILCOW_HOSTNAME, you need to read **Adding additional server names for mailcow UI** at the bottom of this page.
!!! warning
Make sure you run `generate_config.sh` before you enable any site configuration examples below.
The script `generate_config.sh` copies snake-oil certificates to the correct location, so the services will not fail to start due to missing files.
!!! warning
If you enable TLS SNI (`ENABLE_TLS_SNI` in mailcow.conf), the certificate paths in your reverse proxy **must** match the correct paths in data/assets/ssl/{hostname}. The certificates will be split into `data/assets/ssl/{hostname1,hostname2,etc}` and therefore will not work when you copy the examples from below pointing to `data/assets/ssl/cert.pem` etc.
!!! info
Using the site configs below will **forward ACME requests to mailcow** and let it handle certificates itself.
The downside of using mailcow as ACME client behind a reverse proxy is, that you will need to reload your webserver after acme-mailcow changed/renewed/created the certificate. You can either reload your webserver daily or write a script to watch the file for changes.
On many servers logrotate will reload the webserver daily anyway.
If you want to use a local certbot installation, you will need to change the SSL certificate parameters accordingly.
**Make sure you run a post-hook script** when you decide to use external ACME clients. You will find an example at the bottom of this page.
2\. Configure your local webserver as reverse proxy:
### Optional: Post-hook script for non-mailcow ACME clients
Using a local certbot (or any other ACME client) requires to restart some containers, you can do this with a post-hook script.
Make sure you change the paths accordingly:
```
#!/bin/bash
cp /etc/letsencrypt/live/my.domain.tld/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem
cp /etc/letsencrypt/live/my.domain.tld/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem
postfix_c=$(docker ps -qaf name=postfix-mailcow)
dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
nginx_c=$(docker ps -qaf name=nginx-mailcow)
docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
```
### Adding additional server names for mailcow UI
If you plan to use a server name that is not `MAILCOW_HOSTNAME` in your reverse proxy, make sure to populate that name in mailcow.conf via `ADDITIONAL_SERVER_NAMES` first. Names must be separated by commas and **must not** contain spaces. If you skip this step, mailcow may respond to your reverse proxy with an incorrect site.
```
ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
```
Run the following command to apply:
=== "docker compose (Plugin)"
``` bash
docker compose up -d
```
=== "docker-compose (Standalone)"
``` bash
docker-compose up -d
```