Verwenden Sie die untenstehende Konfiguration nicht für Reverse-Proxy-Setups, bitte lesen Sie dazu unsere Reverse-Proxy-Anleitung, die einen Redirect von HTTP zu HTTPS beinhaltet.
Öffne mailcow.conf und setze HTTP_BIND= - falls nicht bereits gesetzt.
Erstellen Sie eine neue Datei data/conf/nginx/redirect.conf und fügen Sie die folgende Serverkonfiguration in die Datei ein:
Let's Encrypt wird unserem Rewrite folgen, Zertifikatsanfragen in mailcow werden problemlos funktionieren.
+
Die hervorgehobenen Zeilen müssen beachtet werden.
+
<VirtualHost*:80>
+ServerNameZUMAILCOWHOSTNAMENÄNDERN
+ServerAliasautodiscover.*
+ServerAliasautoconfig.*
+RewriteEngineon
+
+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/
+ProxyPreserveHostOn
+ProxyAddHeadersOn
+RequestHeadersetX-Forwarded-Proto"http"
+</VirtualHost>
+<VirtualHost*:443>
+ServerNameZUMAILCOWHOSTNAMENÄNDERN
+ServerAliasautodiscover.*
+ServerAliasautoconfig.*
+
+# You should proxy to a plain HTTP session to offload SSL processing
+ProxyPass/Microsoft-Server-ActiveSynchttp://127.0.0.1:8080/Microsoft-Server-ActiveSyncconnectiontimeout=4000
+ProxyPassReverse/Microsoft-Server-ActiveSynchttp://127.0.0.1:8080/Microsoft-Server-ActiveSync
+ProxyPass/http://127.0.0.1:8080/
+ProxyPassReverse/http://127.0.0.1:8080/
+ProxyPreserveHostOn
+ProxyAddHeadersOn
+RequestHeadersetX-Forwarded-Proto"https"
+
+SSLCertificateFileMAILCOW_ORDNER/data/assets/ssl/cert.pem
+SSLCertificateKeyFileMAILCOW_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>
+
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:
Der Zertifikatspfad von Caddy variiert je nach Installationsart.
+Bei diesem Installationsbeispiel wurde Caddy mithilfe des Caddy Repos (weitere Informationen hier) installiert.
+
+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:
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:
-
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:
-
-
-
-
dockercomposeup-d
-
-
-
-
docker-composeup-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.
-
-
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.
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:
Let's Encrypt wird unserem Rewrite folgen, Zertifikatsanfragen in mailcow werden problemlos funktionieren.
-
Die hervorgehobenen Zeilen müssen beachtet werden.
-
<VirtualHost*:80>
-ServerNameZUMAILCOWHOSTNAMENÄNDERN
-ServerAliasautodiscover.*
-ServerAliasautoconfig.*
-RewriteEngineon
-
-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/
-ProxyPreserveHostOn
-ProxyAddHeadersOn
-RequestHeadersetX-Forwarded-Proto"http"
-</VirtualHost>
-<VirtualHost*:443>
-ServerNameZUMAILCOWHOSTNAMENÄNDERN
-ServerAliasautodiscover.*
-ServerAliasautoconfig.*
-
-# You should proxy to a plain HTTP session to offload SSL processing
-ProxyPass/Microsoft-Server-ActiveSynchttp://127.0.0.1:8080/Microsoft-Server-ActiveSyncconnectiontimeout=4000
-ProxyPassReverse/Microsoft-Server-ActiveSynchttp://127.0.0.1:8080/Microsoft-Server-ActiveSync
-ProxyPass/http://127.0.0.1:8080/
-ProxyPassReverse/http://127.0.0.1:8080/
-ProxyPreserveHostOn
-ProxyAddHeadersOn
-RequestHeadersetX-Forwarded-Proto"https"
-
-SSLCertificateFileMAILCOW_ORDNER/data/assets/ssl/cert.pem
-SSLCertificateKeyFileMAILCOW_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>
-
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 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, 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:
-
+
dockercomposeup-d
@@ -2837,7 +2648,7 @@ Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf<
name:traefik_acme
Starten Sie die neuen Container mit:
-
+
dockercomposeup-d
@@ -2854,93 +2665,13 @@ Dazu müssen wir SKIP_LETS_ENCRYPT=y in unserer mailcow.conf<
Sie können es über die Kommandozeile ausführen oder das hier 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.
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.
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:
Der Zertifikatspfad von Caddy variiert je nach Installationsart.
-Bei diesem Installationsbeispiel wurde Caddy mithilfe des Caddy Repos (weitere Informationen hier) installiert.
-
-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:
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:
-
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.
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.
+
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:
+
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:
+
+
+
+
dockercomposeup-d
+
+
+
+
docker-composeup-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 hierunter.
+
+
+
Warnung
+
Stellen Sie sicher, dass Sie generate_config.sh ausführen, bevor Sie die 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.
+
+
+
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 Konfigurationsbeispiele 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 hierunter.
+
+
Konfigurieren Sie Ihren lokalen Webserver als Reverse Proxy anhand folgender Konfigurationsbeispiele:
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:
+
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.