E-Mail Server und DNS Setting bezüglich SSL

[Domi]

Hallo Leute, ich bin mir jetzt nicht sicher ob das Thema hier in die DNS Ecke, in die Ecke für E-Mail Server oder Zertifikat Ecke gehört. Ich fange mal an und vielleicht kann ein Moderator / Admin dann das Thema in die bessere Ecke schieben.

Ich betreibe mehrere Server (eigenes Gewerbe und Firma wo ich arbeite), die Hostnamen der Server haben immer das gleiche Schema...
- srv01.domain.tld
- srv02.domain.tld
- xxx.domain.tld

die Nummern sind fortlaufend und srv soll eine Abkürzung für "Server" sein. Da ich privat als auch bei uns in der Firma mit jeweils einem Server angefangen habe, machen die Server natürlich alles (Webserver und Mailserver) was an sich noch kein Problem darstellt.

Domain Reseller ist INWX, was auch seit Jahren problemlos funktioniert und auch da gab es noch keine Probleme. Ich versuche mal darzustellen, wie meine Settings dort aussehen...

Name	Typ	Wert		Prio	TTL
*	A	127.0.0.1		3600
mail	A	127.0.0.1		3600
www	A	127.0.0.1		3600
	A	127.0.0.1		3600
	MX	srv01.domain.tls  10	3600
	NS	ns.inwx.de		86400

Den SOA sowie die weiteren NS habe ich jetzt einmal aus der Liste weg gelassen um das ganze nicht unnötig zu füllen, aber insgesamt sind fünf NS Einträge vorhanden, falls das von Interesse ist.

Wenn ich jetzt meinen srv01 (oder einen anderen) einrichte, hinterlege ich mittlerweile ein SSL Zertifikat von Letsencrypt, vorher war es ein Zertifikat von StartSSL was aufgrund der Wildcard und SAN Einträge sehr nett war

Problem ist ja nun, wenn ich einem Bekannten, Kunden (what ever) die Serverdaten gebe, müssten diese srv01.domain.tld eingeben um SSL / TLS nutzen zu können ohne das der Client meckert.

Für meine eigene Domain habe ich auch mail.domain.tld mit in das Zertifikat gepackt. Jetzt kommt die Kernfrage, wie machen das die größeren Anbieter wie z.B. Telekom? Für den Abruf gebe ich nur secureimap.t-online.de ein und irgendwo bei denen muss ja ein Server dazwischen sitzen der das koordiniert wohin die Anfragen gehen.

Nach was suche ich denn da um ein ähnliches Prinzip zu nutzen oder welche Verfahren benutzt ihr? Es geht zum Beispiel darum, wenn Server 1 stirbt und ich nun Server 2 in Betrieb nehme, müssten ja alle Leute die E-Mails von meinem Server abrufen von srv01.domain.tld auf srv02.domain.tld umstellen.

Oder stellt ihr dann einfach den A-Record um und fertig ist?! Das ist vermutlich eher eine Grundlegende Thematik, dass Problem stellte sich bis dato auch noch nicht, aber wenn mal der worst-case eintrifft, ich einen Server abstellen und einen neuen in Betrieb nehme, alles umstellen muss, wären ein paar Ansätze von Vorteil.

Gruß, Domi

 

[danton]

Genau dafür erstellt mal funktionsbasierte Subdomains, z.B. mail.domain.de für einen Mailserver und stellt die Zertifikate auch entsprechend für mail.domain.de aus. Wechselt man den Server, braucht man nur den A-Record umbiegen (und Zertifikat/Private-Key auf den neuen Server übertragen).
Alternativ kann man auch ein Wildcard-Zertifikat für seine Domain nehmen oder ein Multi-Domain-Zertifikat - Wildcards gehen aber bei LetsEncrypt m.W. nicht.

 

[Domi]

Ja, soweit ist mir das ja auch bekannt. Dann ein anderes Beispiel, ich habe mehrere Domains bei all-inkl.com gebucht. Mit Letsencrypt mag das ein anderes Thema sein, aber lassen wir das mal weg.

All Inkl wird ja nun nicht, weil ich der liebe nette Domi bin, und über mail.domain1.tld, mail.domain2.tld etc. die E-Mails gesichert abrufen will, für jede Domain ein SSL Zertifikat zur Verfügung stellen.

Wenn du Webhosting machst, mehrere Domains auf deinem Server abgelegt hast, erstellst du doch auch nicht für jede mail.domain.tld sofort ein Zertifikat weil der "Kunde" die E-Mails verschlüsselt abrufen will, oder etwa doch?

Dazu kommt (wenn ich mich jetzt nicht irre) in Dovecot kann man hinterlegen das für jede unterschiedliche Domain ein anderes Zertifikat angesprochen werden soll, glaube aber bei Postfix geht das nicht.

Die funktionsbasierten Sub-Domains existieren ja, aber wenn ich einen Server in Betrieb nehme und auf diesem ein Zertifikat erstelle mit srv04.domain.tld weiß ich ja noch nicht welche mail.domain.tld ich alles anlegen muss oder welche noch kommen werden.

Na klar, im Nachhinein könnte ich ein lieber netter Typ sein und für jeden dann sofort ein mail.domain.tld SSL Zertifikat via Letsencrypt anlegen, aber so viel Langeweile habe ich dann auch nicht und ich glaube auch nicht dass das jeder macht

Ich hoffe, die Grundlage konnte ich einigermaßen verständlich erklären.
Gruß, Domi

 

[danton]

Ja, soweit ist mir das ja auch bekannt. Dann ein anderes Beispiel, ich habe mehrere Domains bei all-inkl.com gebucht. Mit Letsencrypt mag das ein anderes Thema sein, aber lassen wir das mal weg.

All Inkl wird ja nun nicht, weil ich der liebe nette Domi bin, und über mail.domain1.tld, mail.domain2.tld etc. die E-Mails gesichert abrufen will, für jede Domain ein SSL Zertifikat zur Verfügung stellen.

Sofern du damit jetzt meinst, dass All Inkl die Webseiten für dich hostet und die Mail-Dienste bereistellt (halt ein typisches Webspace-Paket), dann bekommst du vielleicht ein Zertifikat für deine Webseite von denen (sofern im Paket enthalten). Für Mails ist das gar nicht notwendig, denn es wird nicht mail.kundendomain.de verwendet, sondern mail.providerdomain.de und der Kunde ruft die Mails auch nicht von mail.kundendomain.de ab, sondern von mail.providerdomain.de

Dazu kommt (wenn ich mich jetzt nicht irre) in Dovecot kann man hinterlegen das für jede unterschiedliche Domain ein anderes Zertifikat angesprochen werden soll, glaube aber bei Postfix geht das nicht.

Unterschiedliche Zertifikate auf der gleichen IP und dem gleichen Port funktionieren bei Webseiten, dort aber auch nur, wenn SNI unterstützt wird. Bei den mir bekannten anderen Protokollen klappt dies nicht.

 

[Domi]

Sofern du damit jetzt meinst, dass All Inkl die Webseiten für dich hostet...

Nein, da ich aber das eine oder andere Webhosting Paket kenne, habe ich die als Beispiel verwendet.

Für Mails ist das gar nicht notwendig, denn es wird nicht mail.kundendomain.de verwendet, sondern mail.providerdomain.de und der Kunde ruft die Mails auch nicht von mail.kundendomain.de ab, sondern von mail.providerdomain.de

Okay, da ticken wir ja dann schon mal gleich. Ich bin nun der Provider! Also muss ich meinen Kunden sagen, verwende für POP / IMAP sowie SMTP srv01.providerdomain.tld oder halt mail.providerdomain.tld, nun also zu meiner Frage... Ich habe mehrere Server und nicht jede Domain auf dem gleichen Server. Wenn ich nun zu meinen "Kunden" sage, das sie mail.providerdomain.tld verwenden sollen, leitet der A-Record ja nur auf eine IP Adresse.

Mich würde nun mal interessieren wie ihr das handhabt. Ich bin jetzt kein Rechenzentrum und habe nur drei Server, aber ich kann ja nicht jedem sagen das er mail.providerdomain.tld verwenden soll, wenn ein oder zwei E-Mail Domains auf Server 1 und welche auf Server 2 sind.

Zusätzlich kommt ja dann noch das Zertifikat. Konnte ich meine Frage nun besser erklären? Mir geht es darum, wie löst man das am geschicktesten ohne auch noch zig Zertifikate erstellen zu müssen.

Es geht also nur um E-Mail, nicht das übliche Webhosting. Da hast du ja schon SNI erwähnt und das funktioniert wunderbar. Außer es kommt vermutlich jemand mit einem alten Win XP System auf meinen Server, da gibt es dann halt Probleme.

 

[killerbees19]

Viele Provider machen das genau so: Da musst Du den FQDN vom Server nehmen (z.B. foobar.kasserver.com), wenn Du SSL/TLS ohne Warnmeldungen im Mailclient nutzen möchtest. Afaik ist das auch bei all-inkl.com so, sofern sich in den letzten Jahren nichts geändert hat.

Bei einigen größeren Betreibern (z.B. domainFACTORY, GMX, ...) gibt es einen zentralen Cluster, der auf sslin.df.eu o.ä. reagiert. Da stehen zig Server dahinter, die es an den entsprechenden Backendserver weiterleiten. Das kann je nach Setup immer ein bestimmter oder irgendein zufälliger aus dem ganzen Pool sein.

Das ist z.B. mit Dovecot realisierbar oder über einen Reverse-Proxy für IMAP/POP3 wie z.B. Nginx. Für eine handvoll Server oder Kunden dürfte sich der Aufwand aber nicht lohnen, da an vorderster Front entsprechende Ressourcen parat stehen müssen.


MfG Christian

PS: SNI bei Dovecot kannst Du vergessen, das unterstützt glaube ich noch kein einziges Mailprogramm.

 

[danton]

Mich würde nun mal interessieren wie ihr das handhabt. Ich bin jetzt kein Rechenzentrum und habe nur drei Server, aber ich kann ja nicht jedem sagen das er mail.providerdomain.tld verwenden soll, wenn ein oder zwei E-Mail Domains auf Server 1 und welche auf Server 2 sind.

Ja, und wenn SSL nicht wäre, würde es in der Tat ausreichen, eine mail-Subdomain für jede Domain anzulegen und den Kunden zu sagen, dass sie die zur eMail-Adresse passende mail.domain.de im eMail-Programm verwenden sollen.

Zusätzlich kommt ja dann noch das Zertifikat. Konnte ich meine Frage nun besser erklären? Mir geht es darum, wie löst man das am geschicktesten ohne auch noch zig Zertifikate erstellen zu müssen.

Mehrere Möglichkeiten:

1. Den Kunden sagen, sie sollen srv01.providerdomain.de, srv2.providerdomain.de usw. verwenden, abhängig davon wo die Mails gerade auflaufen. Kompliziert für den Kunden und wenn du den Kunden auf einen anderen Server umziehst, mußt er was ändern.
2. Mail und Webserver trennen. Dann kannst du wieder mail.providerdomain.de verwenden. Außerdem weniger Angriffsfläche, da auf den jeweiligen Servern weniger Dienste gleichzeitig laufen.
3. Ein Frontend-Mailserver, der alle Verbindungen annimmt und dann wie ein Proxy auf verschiedene Server verteilt - auch hier kann wieder mail.providerdomain.de verwendet werden.

Ich persönlich habe derzeit nur einen Server, würde aber bei mehreren erst Punkt 2 umsetzen und falls ein Server für Mail nicht mehr ausreicht, Punkt 2 und 3 kombinieren.
Bei dem ganzen noch nicht in Betracht gezogen ist Ausfallsicherheit - wenn du über Clustering nachdenkst (was man ab einer gewissen Größe tun sollte), bist du aber auch wieder bei mail.providerdomain.de angekommen und hast dein Zertifikatsproblem nicht mehr.

 

[Domi]

Moin moin ihr beiden, vielen vielen Dank. Manchmal sieht man den Wald vor lauter Bäumen nicht. Ein Cluster war das Wort was ich unter anderem Gesucht hatte.

Aber stimmt schon, dass würde sich dann erst lohnen wenn ich ganz viele Domains hosten würde. Auch wenn das nett wäre, so viel muss es dann doch nicht sein. Daher ist die Variante mit dem Trennen der Dienste (Mail- und Webserver) eine sehr gute Idee.

Klar macht es dann auch Sinn, wenn ich mail.provider.tld hinterlege und diese dann den Kunden mitteile wenn sie SSL / TLS verwenden wollen. Andernfalls können sie auch mail.kunde.tld verwenden und gut ist.

Viele Provider machen das genau so: Da musst Du den FQDN vom Server nehmen (z.B. foobar.kasserver.com), wenn Du SSL/TLS ohne Warnmeldungen im Mailclient nutzen möchtest. Afaik ist das auch bei all-inkl.com so, sofern sich in den letzten Jahren nichts geändert hat.

So ist es auch aktuell noch. Einer meiner IT Kunden, dessen EDV ich betreue hat seine Domain + E-Mail bei all-inkl.com und da gebe ich die kasserver.com Adresse ein, wenn ich TLS verwenden ohne das die Meldung mit dem Zertifikat kommt, weil dieses nicht passt

Gruß, Domi

Nachtrag: Nach welchen Kriterien skalierst du denn die Serverleistung? Bei Webanwendung kann man ja grob abschätzen was gebraucht wird. Kommt ein Forum drauf das gut besucht ist, kann mehr Leistung (CPU + RAM) nicht schaden. Aber bei 15 - 20 E-Mail Domains und 25GB benötigtem Speicher (zur Zeit) könnte ja auch ein CX20 / CX30 von Hetzner vollkommen ausreichend sein.