Erweitertes SSL
Let's Encrypt (wird mitgeliefert)¶
Der "acme-mailcow" Container wird versuchen, ein LE-Zertifikat für ${MAILCOW_HOSTNAME}, autodiscover.ADDED_MAIL_DOMAIN und autoconfig.ADDED_MAIL_DOMAIN zu erhalten.
Warnung
mailcow muss auf Port 80 verfügbar sein, damit der acme-Client funktioniert. Unsere Reverse Proxy Beispielkonfigurationen decken das ab. Sie können auch jeden externen ACME-Client (z.B. certbot) verwenden, um Zertifikate zu erhalten, aber Sie müssen sicherstellen, dass sie an den richtigen Ort kopiert werden und ein Post-Hook die betroffenen Container neu lädt. Weitere Informationen finden Sie in der Reverse Proxy-Dokumentation.
Standardmäßig, d.h. 0 Domains sind zu mailcow hinzugefügt, wird es versuchen, ein Zertifikat für ${MAILCOW_HOSTNAME} zu erhalten.
Für jede hinzugefügte Domain wird versucht, autodiscover.ADDED_MAIL_DOMAIN und autoconfig.ADDED_MAIL_DOMAIN in die IPv6-Adresse oder - falls IPv6 in der Domain nicht konfiguriert ist - in die IPv4-Adresse aufzulösen. Wenn dies gelingt, wird ein Name als SAN zur Zertifikatsanforderung hinzugefügt.
Nur Namen, die validiert werden können, werden als SAN hinzugefügt.
Für jede Domain, die Sie entfernen, wird das Zertifikat verschoben und ein neues Zertifikat angefordert. Es ist nicht möglich, Domains in einem Zertifikat zu behalten, wenn wir nicht in der Lage sind, die Challenge für diese zu validieren.
Wenn Sie den ACME-Client neu starten wollen, verwenden Sie den folgenden Befehl:
docker compose restart acme-mailcow
docker-compose restart acme-mailcow
Überwachen Sie die Logs mit:
docker compose logs --tail=200 -f acme-mailcow
docker-compose logs --tail=200 -f acme-mailcow
Zusätzliche Domain-Namen¶
Bearbeiten Sie "mailcow.conf" und fügen Sie einen Parameter ADDITIONAL_SAN wie folgt hinzu:
Verwenden Sie keine Anführungszeichen (") und keine Leerzeichen zwischen den Namen!
ADDITIONAL_SAN=smtp.*,cert1.example.com,cert2.example.org,whatever.*
Jeder Name wird anhand seiner IPv6-Adresse oder - wenn IPv6 in Ihrer Domäne nicht konfiguriert ist - anhand seiner IPv4-Adresse überprüft.
Ein Wildcard-Name wie smtp.* wird versuchen, ein smtp.DOMAIN_NAME SAN für jede zu mailcow hinzugefügte Domain zu erhalten.
Führen Sie den folgenden Befehl aus, um betroffene Container automatisch neu zu erstellen:
docker compose up -d
docker-compose up -d
Info
Die Verwendung anderer Namen als MAILCOW_HOSTNAME für den Zugriff auf das mailcow UI kann weitere Konfiguration erfordern.
Wenn Sie planen, einen anderen Servernamen als MAILCOW_HOSTNAME für den Zugriff auf die mailcow UI zu verwenden (z.B. durch Hinzufügen von mail.* zu ADDITIONAL_SAN), stellen Sie sicher, dass Sie diesen Namen in mailcow.conf über ADDITIONAL_SERVER_NAMES eintragen. Die Namen müssen durch Kommas getrennt sein und dürfen keine Leerzeichen enthalten. Wenn Sie diesen Schritt auslassen, kann mailcow mit einer falschen Seite antworten.
ADDITIONAL_SERVER_NAMES=webmail.domain.tld,other.example.tld
Führen Sie den folgenden Befehl aus, um es anzuwenden:
docker compose up -d
docker-compose up -d
Erneuerung erzwingen¶
Um eine Erneuerung zu erzwingen, müssen Sie eine Datei namens force_renew erstellen und den acme-mailcow Container neu starten:
cd /opt/mailcow-dockerized
touch data/assets/ssl/force_renew
docker compose restart acme-mailcow
# Prüfen Sie nun die Logs auf eine Erneuerung
docker compose logs --tail=200 -f acme-mailcow
cd /opt/mailcow-dockerized
touch data/assets/ssl/force_renew
docker-compose restart acme-mailcow
# Prüfen Sie nun die Logs auf eine Erneuerung
docker-compose logs --tail=200 -f acme-mailcow
Die Datei wird automatisch gelöscht.
Validierungsfehler und wie man die Validierung überspringt¶
Sie können die IP-Überprüfung überspringen, indem Sie SKIP_IP_CHECK=y in mailcow.conf setzen (keine Anführungszeichen). Seien Sie gewarnt, dass eine Fehlkonfiguration dazu führt, dass Sie von Let's Encrypt eingeschränkt werden! Dies ist vor allem für Multi-IP-Setups nützlich, bei denen der IP-Check die falsche Quell-IP-Adresse zurückgeben würde. Aufgrund der Verwendung von dynamischen IPs für acme-mailcow ist Source-NAT bei Neustarts nicht konsistent.
Wenn Sie Probleme mit der "HTTP-Validierung" haben, aber Ihre IP-Adressbestätigung erfolgreich ist, verwenden Sie höchstwahrscheinlich firewalld, ufw oder eine andere Firewall, die Verbindungen von br-mailcow zu Ihrem externen Interface verbietet. Sowohl firewalld als auch ufw lassen dies standardmäßig nicht zu. Es reicht oft nicht aus, diese Firewall-Dienste einfach zu stoppen. Sie müssen mailcow stoppen, den Firewall-Dienst stoppen, die Chains flushen und Docker neu starten.
Sie können diese Validierungsmethode auch überspringen, indem Sie SKIP_HTTP_VERIFICATION=y in "mailcow.conf" setzen. Seien Sie gewarnt, dass dies nicht zu empfehlen ist. In den meisten Fällen wird die HTTP-Überprüfung übersprungen, um unbekannte NAT-Reflection-Probleme zu umgehen, die durch das Ignorieren dieser spezifischen Netzwerk-Fehlkonfiguration nicht gelöst werden. Wenn Sie Probleme haben, TLSA-Einträge in der DNS-Übersicht innerhalb von mailcow zu generieren, haben Sie höchstwahrscheinlich Probleme mit NAT-Reflexion, die Sie beheben sollten.
Wenn Sie einen SKIP_* Parameter geändert haben, führen Sie den folgenden Befehl aus, um die Änderungen zu übernehmen:
docker compose up -d
docker-compose up -d
Deaktivieren Sie Let's Encrypt¶
Deaktivieren Sie Let's Encrypt vollständig¶
Setzen Sie SKIP_LETS_ENCRYPT=y in "mailcow.conf" und erstellen Sie "acme-mailcow" neu, mit dem folgenden Befehl:
docker compose up -d
docker-compose up -d
Alle Namen außer ${MAILCOW_HOSTNAME} überspringen¶
Fügen Sie ONLY_MAILCOW_HOSTNAME=y zu "mailcow.conf" hinzu und erstellen Sie "acme-mailcow" neu, mit dem folgenden Befehl:
docker compose up -d
docker-compose up -d
Das Let's Encrypt subjectAltName-Limit von 100 Domains¶
Let's Encrypt hat derzeit ein Limit von 100 Domainnamen pro Zertifikat.
Standardmäßig erstellt "acme-mailcow" ein einzelnes SAN-Zertifikat für alle validierten Domains (siehe den ersten Abschnitt und Zusätzliche Domainnamen). Dies bietet beste Kompatibilität, bedeutet aber, dass das Let's Encrypt-Limit überschritten wird, wenn Sie zu viele Domains zu einer einzelnen mailcow-Installation hinzufügen.
Um dies zu lösen, können Sie ENABLE_SSL_SNI so konfigurieren, dass es generiert wird:
- Ein Hauptserver-Zertifikat mit
MAILCOW_HOSTNAMEund allen voll qualifizierten Domainnamen in derADDITIONAL_SANKonfiguration - Ein zusätzliches Zertifikat für jede in der Datenbank gefundene Domain mit autodiscover., autoconfig. und jeder anderen in diesem Format konfigurierten
ADDITIONAL_SAN(subdomain.*). - Begrenzungen: Ein Zertifikatsname
ADDITIONAL_SAN=test.example.comwird als SAN zum Hauptzertifikat hinzugefügt. Ein separates Zertifikat/Schlüsselpaar wird für dieses Format nicht erzeugt.
Postfix, Dovecot und Nginx werden dann diese Zertifikate mit SNI bedienen.
Setzen Sie ENABLE_SSL_SNI=y in "mailcow.conf" und erstellen Sie "acme-mailcow" mit dem folgenden Befehl neu:
docker compose up -d
docker-compose up -d
Warnung
Nicht alle Clients unterstützen SNI, siehe Dovecot Dokumentation oder Wikipedia.
Sie sollten sicherstellen, dass diese Clients den MAILCOW_HOSTNAME für sichere Verbindungen verwenden, wenn Sie diese Funktion aktivieren.
Hier ist ein Beispiel:
MAILCOW_HOSTNAME=server.email.tldADDITIONAL_SAN=webmail.email.tld,mail.*- mailcow E-Mail-Domänen: "domain1.tld" und "domain2.tld"
Die folgenden Zertifikate werden generiert:
server.email.tld, webmail.email.tld-> dies ist das Standard-Zertifikat, alle Clients können sich mit diesen Domains verbindenmail.domain1.tld, autoconfig.domain1.tld, autodiscover.domain1.tld-> individuelles Zertifikat für domain1.tld, kann von Clients ohne SNI-Unterstützung nicht verwendet werdenmail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld-> individuelles Zertifikat für domain2.tld, kann von Clients ohne SNI-Unterstützung nicht verwendet werden
Ein eigenes Zertifikat verwenden¶
Stellen Sie sicher, dass Sie mailcows internen LE-Client deaktivieren (siehe oben).
Um Ihre eigenen Zertifikate zu verwenden, speichern Sie einfach das kombinierte Zertifikat (mit dem Zertifikat und der zwischengeschalteten CA/CA, falls vorhanden) unter data/assets/ssl/cert.pem und den entsprechenden Schlüssel unter data/assets/ssl/key.pem.
WICHTIG: Verwenden Sie keine symbolischen Links! Stellen Sie sicher, dass Sie die Zertifikate kopieren und sie nicht mit data/assets/ssl verknüpfen.
Starten Sie die betroffenen Dienste anschließend neu:
docker restart $(docker ps -qaf name=postfix-mailcow)
docker restart $(docker ps -qaf name=nginx-mailcow)
docker restart $(docker ps -qaf name=dovecot-mailcow)
Siehe Post-Hook-Skript für Nicht-mailcow-ACME-Clients für ein vollständiges Beispielskript.
Test gegen das ACME-Verzeichnis¶
Bearbeiten Sie mailcow.conf und fügen Sie LE_STAGING=y hinzu.
Führen Sie den folgenden Befehl aus, um Ihre Änderungen zu aktivieren:
docker compose up -d
docker-compose up -d
Benutzerdefinierte Verzeichnis-URL¶
Editieren Sie mailcow.conf und fügen Sie die entsprechende Verzeichnis-URL in die neue Variable DIRECTORY_URL ein:
DIRECTORY_URL=https://acme-custom-v9000.api.letsencrypt.org/directory
Sie können LE_STAGING nicht mit DIRECTORY_URL verwenden. Wenn beide gesetzt sind, wird nur LE_STAGING verwendet.
Führen Sie den folgenden Befehl aus, um Ihre Änderungen zu aktivieren:
docker compose up -d
docker-compose up -d
CAA-Einträge mit dem accounturi-Parameter¶
Let's Encrypt ermöglicht es, mithilfe des accounturi-Paramaters in CAA-Einträgen die Zertifikatsausstellung auf spezifische Account-IDs zu beschränken.
Sie können das Helper-Skript generate_caa_record.py verwenden, um einen CAA-Eintrag mit accounturi zu erstellen, welchen Sie dann bei Ihrem DNS-Anbieter eintragen können:
./helper-scripts/generate_caa_record.py --account-key data/assets/ssl/acme/account.pem --contact ihre_acme_email@beispiel.de
Überprüfen Sie Ihre Konfiguration¶
Führen Sie den folgenden Befehl aus, um herauszufinden, warum eine Validierung fehlschlägt:
docker compose logs --tail=200 acme-mailcow
docker-compose logs --tail=200 acme-mailcow
Um zu überprüfen, ob nginx das richtige Zertifikat verwendet, benutzen Sie einfach einen Browser Ihrer Wahl und überprüfen Sie das angezeigte Zertifikat.
Um das von Postfix, Dovecot und Nginx verwendete Zertifikat zu überprüfen, verwenden wir openssl:
# Verbindung über SMTP STARTTLS (587)
openssl s_client -starttls smtp -connect MAILCOW_HOSTNAME:587 | openssl x509 -noout -text
# Verbindung über SMTP (465)
openssl s_client -connect MAILCOW_HOSTNAME:465 | openssl x509 -noout -text
# Verbindung über IMAP STARTTLS (143)
openssl s_client -starttls imap -connect MAILCOW_HOSTNAME:143 | openssl x509 -noout -text
# Verbindung über IMAP (993)
openssl s_client -connect MAILCOW_HOSTNAME:993 | openssl x509 -noout -text
# Verbindung über HTTPS (443)
openssl s_client -connect MAILCOW_HOSTNAME:443 | openssl x509 -noout -text
Um die von openssl zurückgegebenen Verfallsdaten gegen MAILCOW_HOSTNAME zu validieren, können Sie unser Hilfsskript verwenden:
cd /opt/mailcow-dockerized
bash helper-scripts/expiry-dates.sh