MTA-STA extern

CK_beats

accolon
Okay. Vielen Dank für Deine Infos! Das bringt Licht ins Dunkel!
Ich benötige aber in jedem Fall ein gültiges Zertifikat für mta-sts.meinedomain.tld , oder?

Wir lassen die Zertifikate zwar über ACME erzeugen, jedoch nicht auf der Mailcow.
Wird von OPNsense für die Subdomains erzeugt und an Mailcow übergeben.
Ich hatte das Problem, dass trotz angelegtem CNAME die Zertifikatsabfrage fehlschlug.
Ohne erkennbaren Grund.

HTTP/S ist bei uns von außen nur über SSL Inspection nach innen möglich.
Was ist hier dem Reverse-Proxy mitzugeben, damit Mailcow mit der mta-sts.txt Richtlinie antwortet?
Die Abfrage von innen heraus https://ip-der-mailcow/./well-known/mta-sts.txt war ebenfalls nicht möglich.

Oder sollte ich besser die Datei mta-sts.txt statisch auf unserem Webserver veröffentlichen?

Viele Grüße
Constantin

D4niel

CK_beats Eigentlich musst du dem Reverse Proxy lediglich sagen, dass er mta-sts.domain.tld an die Mailcow weiterleiten soll und mta-sts.domain.tld als alternativen Namen für das Mailcow-Zertifikat hinzufügen. Die Textdatei erstellt Mailcow selbst und den DNS-Record musst du halt noch anlegen.

Ist denke ich die einfachste Lösung. Natürlich kannst du mta-sts.domain.tld auch auf einen eigenen Webserver routen, der die Textdatei ausliefert.

CK_beats

D4niel
Super! So hatte ich mir das auch gedacht!
Ein Zertifikat für die Subdomain mta-sts.meinedomain.tld anfordern und sämtliche Anfragen über diese Domain über den Reverse-Proxy per HTTPS Offload an den Mailcow weitergeben.

Nur leider existiert der Pfad https://10.199.1.4/./well-known/mta-sts.txt (10.199.1.4 ist unsere Mailcow) nicht einmal im lokalen Netz.
Ich habe ewig gesucht, weil sämtlich externen Prüfungen immer fehlschlugen. Bis mir auffiel, dass Mailcow den Pfad so nicht bereitstellt.
Wird Standard HTTPS Port 443 verwendet oder ein alternativer Port?
Die GUI / Sogo wird über Port 443 erreicht, an der Grundkonfiguration wurde nichts verändert.

Viele Grüße
Costa fast gar nix 😅

D4niel

Nur leider existiert der Pfad https://10.199.1.4/./well-known/mta-sts.txt (10.199.1.4 ist unsere Mailcow) nicht einmal im lokalen Netz.

Der Pfad ist/.well-known/mta-sts.txt nicht /./well-known/mta-sts.txt
Der Webserver der Mailcow wird auch ziemlich sicher nur auf die Domain hören und nicht auf die IP, da die mta-sts.txt ja pro Domain erstellt wird im GUI.

CK_beats

D4niel
… stimmt natürlich!
Der Pfad ist /.well-known/mta-sts.txt.

Gerade nochmals geprüft.

Ich bin mir relativ sicher, dass die übergebene Domain nicht relevant ist.
Die MTA-STS.txtist ja von überall einsehbar und enthält nur statische Informationen.

D4niel

Die Domain ist relevant 🙂 Die Datei wird nur über mta-sts.domain.tld ausgeliefert.

Die MTA-STS.txtist ja von überall einsehbar und enthält nur statische Informationen.

Es geht ja darum, welche Anfragen der Webserver der Mailcow annimmt.

CK_beats

D4niel
Danke für die Info. Verstehe.
Dann muss ich zuerst unseren OPNsense ACME Client umbauen, damit ich ein Wildcard Zertifikat erhalte.
Nutzen die HTTP-Challenge, die kein Wildcard Zertifikat erstellen lässt.
Erst danach kann ich sauber den CNAME https://sta-sts.meinedomain.tld über HAproxy an Mailcow weitergeben.
Vielen Dank für Deine Hilfe.
Das muss ich in Ruhe angehen.

CK_beats

D4niel

Kleines Update und Entschuldigung!
Du hattest natürlich Recht! Voraussetzung für eine erfolgreiche Bereitstellung desmta-sts.txtist ein für den CNAME mta-sts.meinedomain.tld Zertifikat.
Anschließend stellt Mailcow die Textdatei erfolgreich bereit.

Ich habe nun auf allen 3 von Mailcow verwalteten Domains die entsprechenden CNAME, sowie TXT-Einträge gem. den DNS-Vorgaben von Mailcow eingerichtet.

Über ACME konnte ich dann valide Zertifikate für mta-sts.meinedomain.tld erstellen lassen und per Push an Mailcow ausliefern.
1x Postfix restart und es läuft! 😍

Mxtoolbox gefällt das! 😅

Ich hatte einen Fehler in der Konfiguration des HAProxy, der die Challanges für ACME / Let’s Encrypt verwaltet / bereitstellt.
Daher war ich die ganze Zeit auf dem Trip mit dem Wildcard Zertifikat. Ich ging davon aus, dass für die Subdomain mta-sts kein Zertifikat erstellt werden kann.
Nach ewigem Suchen bemerkte ich dann, dass auch die übrigen Zertifikate nicht erneuerbar sind. Fehler gesucht, Fehler gefunden, Fehler verloren, macht zusammen 3 Stunden! 😅😅
Konnte endlich die Zertifikate signieren lassen und schon läuft es.
Sind jetzt auf “Enforce”.

… und “knallt” so richtig:
Trusted TLS connection established to xxx-de01b.mail.protection.outlook.com[2a01:111:f403:ca09::1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256

stefan21

CK_beats CNAME mta-sts.meinedomain.tld Zertifikat.

Wenn eine statische business ipv4 vorhanden ist, dann geht auch ein “A” -record.

mlcwuser

Ja, ein A-Record müsste technisch ebenfalls funktionieren.

Der Vorteil von CNAME-Records ist halt, dass wenn du z.B. deinen deinen E-Mail-Server umziehst, nur den A-Record für „mail.deinedomain.tld” ändern musst. Dann verweisen automatisch auch alle anderen Subdomains (autodiscover, autoconfig, mta-sts etc.) auf die neue IP-Adresse. Verwendest du A-Records für die anderen Subdomains, musst du jeden dieser A Records einzeln ändern.

stefan21

A-Record funktioniert.

IMVHO macht ein dedicated mail-server mit einer statischen business IP auf den mta-sts am wenigsten Probleme bei email-Zustellungen. Im B2B-Bereich nur mit dem Port 25. Keine Probleme mit irgendwas.

mlcwuser

stefan21 Es geht mir hier nicht darum eine dynamische IP Adresse mit irgendwelchen DynDNS Diensten zu verwenden. Und ja, mail.domain.de, also die Subdomain auf die auch der MX Record zeigt, sollte definitiv als A Record auf die öffentliche IP des Mailservers zeigen. Alle weiteren Subdomains (autodiscover, autoconfig, mta-sts etc.) kannst du aber problemlos via CNAME auf mail.domain.de zeigen lassen. Macht null Unterschied was die Zuverlässigkeit betrifft. aber u.U. das Mangement der DNS Records etwas klarer und einfacher.

CK_beats

So handhaben wir es letztendlich auch. Sollte sich etwas an der öffentlichen IP oder der IPv6 des Mailservers ändern reicht der AAAA bzw A-Eintrag in der Subdomain für den Mailserver.

Zudem ist die Anzahl max. Subdomains bei uns begrenzt. Alleine mit Mail, autodiscover, mta-sts etc. wäre schon einiges belegt. Letztendlich zeigen aber alle auf den gleichen Server.
Es werden schließlich auch noch Subdomains für andere Dienste benötigt.

Was mir aber heute Nacht aufgefallen ist:
Ngix hat wohl das Zertifikat gewechselt.
Anscheinend kann es nicht unterschiedliche Zertifikate handhaben und den verschiedenen Anfragen bereitstellen.
Letztendlich war die GUI intern nicht mehr erreichbar, da das mta-sts Zertifikat präsentiert wurde.
Dank HSTS war keine Verbindung mehr möglich.
Von außen hat man es gar nicht bemerkt, da HAProxy SSL Abladung betreibt und das benötigte Zertifikat für die Subdomain mitliefert.

Musste alle für Mailcow benötigten DNS-Adressen zusammenfassen und als ein Zertifikat ausstellen und exportieren lassen.
Dann funktionierte wieder alles.

Vielleicht hierzu ein kleiner Hinweis in der Anleitung?