Frage, CNAME und Lets Encrypt

Die Basics sind mir bekannt, aber ich versuche es mal anders...

Du bist Serverbetreiber, hast einen Server,
- server01.thunderbyte.tld

Du hast X Domains von Freunden, Bekannten, Kunden etc. bei dir auf dem Server (server01.thunderbyte.tld),
- bekannter01.tld

Welche DNS Einträge hast du hinterlegt und was sagst du dem Inhaber von bekannter01.tld, was er in seinem E-Mail Client (z.B. Outlook, Thunderbird, iPhone etc.) eintragen soll??

Gruß, Domi

Nachtrag: Ich bin übrigens Inhaber von bekannter01.tld, um es vielleicht besser zu gestalten.
 
Domi said:
Spannend wird es allerdings, wenn der E-Mail Client (z.B. Outlook) auf mail.domain.tld eingerichtet ist und der Endanwender unbedingt SSL/TLS verwenden möchte, diese "alternativen" Domains nicht im Zertifikat hinterlegt ist, da dieses ja nur auf srv01.domain.tld läuft.
Click to expand...
Was spricht gegen ein Zertifikat, welches auf mail.domain.tld ausgestellt ist? domain.tld ist die "Provider"-Domain für den Serverbetrieb. Bei mir sind noch ein paar mehr Subdomains von domain.tld drin, da ich von Lets Encrypt nur ein Zertifikat erzeugen lasse, dass ich in verschiedenen Diensten einbinde.

Domi said:
Und darum hatte ich mir angewöhnt in das Zertifikat welches auf srv01.domain.tld läuft, auch die ganzen mail.kunde1.tld, mail.kunde2.tld zu hinterlegen.
Click to expand...
Nein, keine Kundendomains im Zertifikat verwenden. Damit erziehst du dir deine Kunden und am besten legst du auch A-Records wie mail.kunde.tld gar nicht erst an. Und umgehst das Datenschutzproblem.
Domi said:
Und somit kam ich dann auf die Idee einen Reverse Proxy dazwischen zu schalten.
Click to expand...
Dein Problem mit Zertifikaten für mehrere Kundendomains löst das aber nicht.
Du must bei der Verwendung von FQDNs ein wenig nach dem Zweck unterscheiden:
srv01.domain.tld verwendest du, wenn du ein bestimmtes System ansprechen willst, z.B. per SSH zum Management.
mail.domain.tld verwendest du, wenn einen DIenst ansprechen willst - im Beispiel des Mailserver.
 
Domi said:
Die Basics sind mir bekannt, aber ich versuche es mal anders...

Du bist Serverbetreiber, hast einen Server,
- server01.thunderbyte.tld
Click to expand...
Du kannst auch tausende A Records anlegen, oder auch einen Catchall. Daher ist es doch völlig wurscht, wie man sich den Server benennt, der kann gerne einen A Record für server01.domain.tld haben UND auch mail.domain.tld. Ich mache mit mail.domain.tld weiter, weil das das eingängigste Beispiel ist.

EINE Subdomain mit einem passenden A Record wird als MX Record für domain.tld eingetragen, z.B. mail.domain.tld. Zudem muss sich der Serverbetreiber um einen passenden reverse Eintrag kümmmern (s.o.).

Und ALLE ANDEREN Domains / Domaininhaber auf dem (Mail)server tragen den gleichen Mailserver ein, also

MX Record von bekannter01.tld -> mail.domain.tld
MX Record von bekannter02.tld -> mail.domain.tld
MX Record von bekannter03.tld -> mail.domain.tld
MX Record von bekannter04.tld -> mail.domain.tld

Andere Domaineinträge werden bei diesen Domains nicht benötigt. Und wie der MX Record natürlich auch die Einträge in den Mailclients, d.h. Bekannter01 trägt als IMAP/SMTP Server für die Domain bekannter01.tld dann mail.domain.tld ein.

Ein SSL Zertifikat holt sich der Serverbetreiber ausschließlich und alleine für mail.domain.tld . Dieses gilt dann aufgrund der dargestellten ausschließlichen Verwendung dieser Subdomain für ggfalls Webinterface sowie Absicherung von IMAP(S) und SMTP(S) für ALLE Maildomains. Es braucht dann kein separates Zertifikat für bekannter.01.tld oder sonst jemanden und es werden auch nicht alle Domains ins Zertifikat aufgenommen.

Dieses Schema läuft bei mir seit Jahrzehnten.
 
Ein Träumchen, alles klar wir sind uns einig... ich drücke mich vermutlich wieder falsch aus :rolleyes:

Das gute bei deinem Beispiel ist, wenn du nun von server01.domain.tld zu server02.domain.tld schwenkst, brauchst du nur den A-Record mail.domain.tld umstellen, fertig ist. Hier wäre es allerdings eine Art "Rip & Replace".

Wie handhabst du es denn wenn es nun nicht nur ein Server sondern zwei sind?
- server01.domain.tld
- server02.domain.tld

und einer der beiden durch server03.domain.tld später komplett abgelöst wird?

Vielleicht denke ich hier auch nur falsch oder zu kompliziert und die Durchführung ist super simple :confused:
 
Nochmals: solche Namen wie server01.domain.tld und server02.domain.tld sind erst einmal komplett irrelevant, wenn sie lediglich zur Zuteilung DNS Name -> IP verwendet werden (z.B. damit Du in Deinem SSH Client keine IPs eingeben musst). Relevant sind erst einmal ausschließlich IP Adressen und die DNS Konfiguration für den Mailserver.

Wenn Du zwei Server mit zwei Mailservern darauf hast, dann richtest Du halt auf beiden ein passendes Setup ein, z.B.:

Erster Server mit Clients:
A Record mail.domain.tld -> IP 1.2.3.4
Reverse Record IP 1.2.3.4 -> mail.domain.tld
MX Record für domain.tld -> mail.domain.tld
MX Record bekannter01.tld -> mail.domain.tld
MX Record bekannter02.tld -> mail.domain.tld
SSL Zertifikat für mail.domain.tld

Mail Programm für alle Domains auf diesem Server: mail.domain.tld

Zweiter Server mit Clients:
A Record mail2.domain.tld -> IP 1.2.3.4
Reverse Record IP 1.2.3.4 -> mail2.domain.tld
MX Record für domain.tld -> mail2.domain.tld
MX Record bekannter03.tld -> mail2.domain.tld
MX Record bekannter04.tld -> mail2.domain.tld
SSL Zertifikat für mail2.domain.tld

Mail Programm für alle Domains auf diesem Server: mail2.domain.tld
 
Thunderbyte said:
Nochmals: solche Namen wie server01.domain.tld und server02.domain.tld sind erst einmal komplett irrelevant
Click to expand...
Mea culpa... ich hätte vielleicht nur Server 1 und Server 2 sagen sollen, aber hey, so ergibt es einen gut strukturierten Sinn.

Ob man nun mail.domain.tld oder aufgrund eines Monks im Kopf (wie bei mir) denen sofort Nummern gibt mail01.domain.tld, mail02.domain.tld, mail03.domain.tld etc., spielt ja dann keine Rolle.

Löst man nun Server 1 ab, macht einen weiteren Server in der Nummerierung (z.B. server05.domain.tld), ist der erste A-Record für den FQDN des Servers selbst und dann macht man noch einen A-Record für die Mails (z.B. mail05.domain.tld) und fertig ist.

Für beide Adressen (server05.domain.tld und mail05.domain.tld) kann man dann ein SSL Zertifikat ausrollen lassen und wäre unabhängig. Nächster Vorteil wäre, man könnte für den Übergang (wenn Server 1 abgeschaltet wird) sogar noch mittels "-d mail01.domain.tld" das Zertifikat für die mail05.domain.tld erweitern.

Ist vom Gedanken her super einfach, ich hab es nur vom Gedanken her komplexer gemacht als gedacht.
 
Klar, mail01.domain.tld und mail02.domain.tld geht natürlich auch, ist durchaus "hübscher".

Du brauchst eigentlich kein SSL Zertifikat für server.05.domain.tld , wenn Du diesen Namen weder in MX Records noch für eine Website verwenden willst.
Zu Zertifikaten: wenn Du Let's Encrypt einsetzen willst, kannst Du Dir mit der DNS Auth Methode (mit einem geeigneten DNS Server wie Cloudflare) auch ein Wildcardzertifikat für *.domain.tld holen. Ein Reverse Proxy wie Nginx Proxy Manager könnte das Zertifikate erneuern übernehmen, allerdings ist es kein Selbstläufer, das aktualisierte Zertifikat in den Mailserver einzuspielen. Daher ist im Mailserver doch wohl ein 1jähriges oder noch längeres Zertifikat besser.
 
Thunderbyte said:
Ein Reverse Proxy wie Nginx Proxy Manager könnte das Zertifikate erneuern übernehmen, allerdings ist es kein Selbstläufer, das aktualisierte Zertifikat in den Mailserver einzuspielen
Click to expand...
Hä? Was ist so schwer daran, nach dem Reload/Restart des NginxProxy ein Reload/Restart des Mailservers (automatisiert) durchzuführen?
 
Last edited:
Auf dem einen meiner Server ist ein ISPconfig drauf.

Das System hat mal "certbot" verwendet und nun verwendet es acme.sh für Lets Encrypt... das tat immer und tut eigentlich noch was es soll und da ist ein Cronjob hinterlegt. Dieser Cronjob läuft eigentlich jeden Tag alle X Stunden, ich hab ihn aber selbst auf Sonntags umgestellt! Grund war, weil es mich mal geärgert hat dass jemand direkt über Denic seine Domain weg gezogen hatte (auf einem Mittwoch) Lets Encrypt eine Abfrage machte und bei dem "--post-hook" der Apache (oder andere Dienste) nicht mehr hoch kamen.

An diesem Tag war ich auch super eingespannt bei einem Kunden vor Ort und ich bekam E-Mails mit "hilfe hilfe, hier geht was nicht" und da bin ich an einem Sonntag dann flexibler. Notebook war dabei, ich konnte es relativ zügig klären, aber es hätte auch schlimmer kommen können.

Warum hab ich ein ISPconfig im Einsatz?

Ich hatte damals alles via SSH erledigt, E-Mail Adressen via MySQL eingetragen, Domains händisch via Copy & Paste angelegt im Apache Verzeichnis etc., aber irgendwann wollten die Leute selbst steuern können. cPanel war damals eine Variante und irgendwas noch, aber ISPconfig hat damals echt viel direkt mit den Mitteln out-of-the-box gemacht, dass fand ich toll. Nicht so wie Plesk was damals echt viel ganz anders machte und mich noch mehr verwirrte, weil man die Dienste nicht so kennen lernt wie sie eigentlich im Ursprung sind.
 
Joe User said:
Hä? Was ist so schwer daran, nach dem Reload/Restart des NginxProxy ein Reload/Restart des Mailservers (automatisiert) durchzuführen?
Click to expand...
NPM holt sich selbst die Zertifikate irgendwann, für den normalen Betrieb ist das ja auch egal. Den Restart des Mailservers daran auszurichten fällt schwer. Mit nem anderen Nginx könnte man das vermutlich eher timen.
 
Thunderbyte said:
Daher ist im Mailserver doch wohl ein 1jähriges oder noch längeres Zertifikat besser.
Click to expand...
Moin... ich hab eines vergessen... Zertifikate mit einem Jahr sind wohl OK, aber einer meiner Kollegen in der Firma (wo ich mittlerweile seit Ende 2021 arbeite) sagte vor ein paar Wochen, dass Zertifikate mit einer längeren Laufzeit als 1 Jahr wohl nicht mehr von Apple (Apple Geräte) akzeptiert werden.

Wir sind da nur drauf gekommen, weil ich fragte wieso wir uns kein Wildcard Zertifikat für mehrere Jahre holen, da wir unser Zertifikat immer um die Weihnachtszeit austauschen müssen.

Ich hatte es einmal mit irgend einer Suche bei den Suchmaschinen gefunden, wo so etwas bestätigt wurde, finde es aber nicht wieder.

Falls jemand was genaueres darüber weiß und das stimmt, dann müsste man dieses für die Zukunft bedenken und wenn das nicht stimmt, müsste ich da eventuell mal mit meinen Kollegen drüber sprechen. Vielleicht kann man ja dann doch mal zu einem anderen Zeitpunkt ein Wildcard Zertifikat mit längerer Laufzeit ordern :D
 
Domi said:
Moin... ich hab eines vergessen... Zertifikate mit einem Jahr sind wohl OK, aber einer meiner Kollegen in der Firma (wo ich mittlerweile seit Ende 2021 arbeite) sagte vor ein paar Wochen, dass Zertifikate mit einer längeren Laufzeit als 1 Jahr wohl nicht mehr von Apple (Apple Geräte) akzeptiert werden.
Click to expand...
Apple ist da nur bedingt dran schuld, denn das CA/Browser Forum hatte zuvor schon darüber diskutiert, die maximale Laufzeit auf ein Jahr zu verkürzen - auf Grund eines entsprechenden Vorschlags von Google. Apple hat dann den Beschluss vorweggenommen und im März 2020 angekündigt, ab September 2020 (Ausstelldatum) nur noch Zertifikate mit max. 1 Jahr Laufzeit (genauer 397 Tage) zu akzeptieren - Google und Mozilla haben im Juni 2020 nachgezogen (siehe https://heise.de/-4796599 ). Zertifikate, die vor dem 01.09.2020 ausgestellt wurden, durften noch 2 Jahre gültig sein (genauer 825 Tage).
Das bedeutet, dass auch Google Chrome und Mozillas Firefox/Thunderbird längere Zertifikate nicht mehr akzeptieren und vermutlich die meisten Chromium-basierten Browser ebenfalls nicht.
 
Alles klar, vielen Dank nochmals für die Aufklärung / Bestätigung.

Aber dafür sind wir ja hier um uns auszutauschen ;)
 
You must log in or register to reply here.
Back
Top