Mail verschlüsseln und Https

  • Debian 9 mit aktuellem PDA


    Ich habe ein Debian 9 minimal mit PDA aufgesetzt ... soweit so gut :-)


    Standardmäßig ist der Mailserver und sind die Domains ja nicht verschlüsselt.
    Da geschäftliche Mails inzwischen ja zwingend verschlüsselt werden müssen und und die Domains über https laufen sollen, würde ich gern wissen wie ihr eure Server nach der Grundinstallation auf den verschlüsselten Stand "hebt" . Ist letsencrypt das Mittel der Wahl für beide Anforderungen?
    Ein aktuelles how-to fände ich klasse und würde wahrscheinlich viele Fragen beantworten.


    Ich danke für eure Unterstützung im Voraus und würde mich freuen wenn ihr helfen könntet mal "Licht ins Dunkel zu bringen" wie man es Stand 08/2018 auf einem PDA bewerkstelligen sollte...


    Danke & Gruß,
    Sacha

  • Also es gibt hier ja schon eine Menge zu SSL.


    Einmal erklärt Herr Bradler hier wie man Let's Encrpyt benutzt und dann gibt es noch eine Erklärung dazu, wie man jedes andere beliebige Zertifikat einfügen kann und für den Server einbinden kann hier.


    Für den Server selber würde ich ein Zertifikat kaufen, da der ständige Wechsel bei Let's Encrpyt ja anscheinend zu Problemen führt. Für die Domains selber denke ich mal ist Let's Encrpyt besser als nichts.

  • OK, meine Hoffnung war, das es inzwischen einen "Knopf-Druck-Standardweg" gäbe.


    Es bleiben noch ein paar Unklarheiten:


    -wo kauft ihr eure Zertifikate?
    -wenn die Serverdomain abgesichert ist, ist dann auch jeder Mailserver der einzelnen Domains automatisch abgesichert oder muss das für jede Domain gemacht werden?
    -in der Serverkonfig ist letencrypt aktiv und in der Angebotsverwaltung angehakt. Müssen die Kunden selbst im Customer Account noch etwas aktivieren??


    Vielen Dank für eure Hilfe ... ich weiß, das ist meine erste Erfahrung mit dem Einrichten der Verschlüsselung , versuche es aber zu verstehen ;-)


    Danke,
    Sacha

  • Zitat

    Original von IP-Logic
    OK, meine Hoffnung war, das es inzwischen einen "Knopf-Druck-Standardweg" gäbe.


    Eine Knopfdruck Lösung gibt es leider nicht. Ich halte Let's Encrypt für den professionellen Einsatz jedoch für nicht ungeeignet. In meinem Blog habe ich eine Anleitung für die Einrichtung in pdadmin geschrieben. Bei mir läuft dies problemlos.


    Und sicherlich gibt es Möglichkeiten Zertifikate regelmäßig zu prüfen, so dass bei möglichen Problemen diese schnell auffallen.


    Zitat

    Original von IP-Logic
    -wenn die Serverdomain abgesichert ist, ist dann auch jeder Mailserver der einzelnen Domains automatisch abgesichert oder muss das für jede Domain gemacht werden?


    Der Mailserver kann nur ein Zertifikat verwenden. Dieses sollte identisch mit dem Hostnamen sein.


    Wird für den Mailverkehr die Kundendomain verwendet, kommt es in der Regel zu einer Zertifikatswarnung.


    Zitat

    Original von IP-Logic
    -in der Serverkonfig ist letencrypt aktiv und in der Angebotsverwaltung angehakt. Müssen die Kunden selbst im Customer Account noch etwas aktivieren??


    Wenn Let's Encrypt in der Serverkonfiguration und im Angebot aktiviert ist muss der Kunde nichts mehr machen.

  • Danke für die Antwort und den Blog werde ich mir anschauen :-)
    ... habe ich gerade und das hast Du sehr gut alles beschrieben. Danke!
    D.h. du siehst keine Probleme komplett auf letsencrypt zu setzen und favorisierst diese Vorgehensweise?
    Wäre ja schon für PDA interessant direkt die Vorgehensweise fest zu implementieren. (deswegen hatte ich auch auf eine integrierte "Ein Knopf Lösung" gehofft ) ;-)))


    ES sind noch zwei Fragen aufgetaucht, die bei mir für Verwirrung sorgen:


    Im PDA Reseller gibt es den Menüpunkt SSL und dann in der Endkundenverwaltung noch mal den Punkt SSH .... Wofür sind von PDA diese Menüs vorgesehen, wenn die Anleitungen doch alle von der Konsole aus diese Dinge einrichten ??? oder geht das auch rein über das dpa Interface?


    Vielen Dank,
    Sacha

  • Unter dem Punkt SSL können SSL Zertifikate manuell installiert und verwaltet werden. Wenn Sie Zertifikate kaufen ist dies die Stelle, wo die Zertifikate hin kommen 😉 Zudem lassen sich dort SSL Proxys konfigurieren.


    SSH dagegen hat nichts mit SSL zu tun. Darüber wird die Shell des Endkunden festgelegt und somit ob dieser sich per Konsole (z.B. PuTTy) auf den Server einloggen kann. /bin/false ist keine Shell und somit ist der Login deaktiviert. Mit /bin/bash wird die Bash als Shell gesetzt und ein Login ist somit möglich.

  • Danke!
    Nur um das richtig zu verstehen :


    Wenn ein Kunde sich ein SSL Zertifikat kauft, kann er es selbst unter dem Abschnitt SLL im Customer einbinden ohne das der Reseller was damit zu tun hat.... Es betrifft aber nur den Domainaufruf und nicht die Mailkonten. Diese sind weiterhin unverschlüsselt weil diese Verschlüsselung über die Hauptserverdomain erfolgt.


    Richtig verstanden?


    Wenn ich den im Blog beschriebenen Weg umsetze, werden über die kostenlosen letsencrypt Verschlüsselungen alle oder wenn nur für eine Domain aufgerufen, nur diese Domain verschlüsselt. Mit den Scriptänderungen würde letsencrypt auch den Mailserver verschlüsseln...
    Das immer wieder zitierte Aktualisierungsproblem bei ist aber bei der im Blog beschriebenen Vorgehensweise nicht zu erwarten und es spricht dann auch nichts gegen die Nutzung von letsencrypt für den gesamten Server...


    Habe ich das jetzt alles so richtig wiedergegeben?


    Vielen Dank für die Infos und die Erklärungen :-)

  • Zitat

    Wenn ein Kunde sich ein SSL Zertifikat kauft, kann er es selbst unter dem Abschnitt SLL im Customer einbinden ohne das der Reseller was damit zu tun hat.... Es betrifft aber nur den Domainaufruf und nicht die Mailkonten. Diese sind weiterhin unverschlüsselt weil diese Verschlüsselung über die Hauptserverdomain erfolgt.


    Ist fast richtig. Der Kunde kann das Zertifikat nicht selber einbinden, dass musst Du machen. Der Mailverkehr bleibt aber unverschlüsselt, da das über den Server selber eingestellt werden muss und nicht abhängig von den Domains ist.


    Zitat

    Wenn ich den im Blog beschriebenen Weg umsetze, werden über die kostenlosen letsencrypt Verschlüsselungen alle oder wenn nur für eine Domain aufgerufen, nur diese Domain verschlüsselt. Mit den Scriptänderungen würde letsencrypt auch den Mailserver verschlüsseln... Das immer wieder zitierte Aktualisierungsproblem bei ist aber bei der im Blog beschriebenen Vorgehensweise nicht zu erwarten und es spricht dann auch nichts gegen die Nutzung von letsencrypt für den gesamten Server...


    Ich habe den Blog zwar nur überflogen, aber es sieht so aus, als würde da alles verschlüsselt per Let's Encyrpt. Ob es Probleme gibt bei IPhones oder anderen Geräte kann ich Dir nicht sagen, da ich immer nur gekaufte Zertifikate für den Server benutze und Let's Encrpyt nur für Kundendomains nutze, die kein Zertifikat kaufen wollen.

  • Hmmm ... wenn der Kunde das nicht selber kann, wie macht man das dann? Der Kunde gibt einem das Zertifikat und ich gehe dann in den Customer ? Was muss ich dann noch machen?


    Wo kauft ihr denn eure Zertifikate und reicht ein Domain Zertifikat ? Multidomain- oder Wildcard können ja schon empfindlich teuer werden...



    Danke und Gruß,
    Sacha

  • Also das Zertifikat kannst Du nur unter /administrator und dann im Punkt "SSL" einspielen.
    Ist aber ziemlich schnell erledigt. Du musst für den Kunden ja auch .csr und .key generieren bevor Du oder er selber das Zertifikat bestellen kann.


    Also wir selber sind Reseller von Comodo, dass lohnt sich je nach Menge der Zertifikate die man braucht, ob sich ein Wildcard lohnt oder nicht hängt von der Situation ab, wenn der Kunden ein paar Subdomains hat lohnt sich das auf jeden Fall, denn sonst muss für jede Subdomain ein eigenes Zertifikat gekauft werden.

  • Zitat

    Original von Eisenherz
    Ich habe den Blog zwar nur überflogen, aber es sieht so aus, als würde da alles verschlüsselt per Let's Encyrpt. Ob es Probleme gibt bei IPhones oder anderen Geräte kann ich Dir nicht sagen, da ich immer nur gekaufte Zertifikate für den Server benutze und Let's Encrpyt nur für Kundendomains nutze, die kein Zertifikat kaufen wollen.


    Richtig, es wird alles verschlüsselt. Mit iPhones habe ich leider keine Erfahrung. Die Lets Encrypt Webseite behandelt leider nur die Kompatibilität bei Browsern.


    IP-Logic


    Wenn es beim Mailserver doch Kompatibilitätsprobleme mit Apple gibt, würde ein kommerzielles Zertifikate für den Hostnamen benötigt werden. Die Kundendomains können aber weiterhin per Lets Encrypt abgesichert werden. Ihre Kunden müssen dann nur den Hostnamen als Posteingangs- und Postausgangsserver verwenden. Ansonsten wird es eine Fehlermeldung geben, das Zertifikat passe nicht zur Adresse.

  • Also wenn Du auf Nummer sicher gehen willst, dann kaufe Dir für den Server ein Zertifikat und den Kunden würde ich auch Zertifikate anbieten, wenn das einem Kunden zu teuer ist, dann würde ich ihm anbieten seine Webseite per Let's Encrpyt zu schützen oder Du bietest jedem Kunden standardmäßig Let's Encrpyt an und optional ein SSL-Zertifikat zum Kauf.

  • gut, dann werde ich für den Server auf Nummer Sicher gehen und ein SSL Zertifikat kaufen.


    Wenn man z.B. eine Domain "meineserver.de" nutzt und die jeweiligen Server dann mit Namen "server1.meineserver.de" ... "server2.meineserver.de" usw. betreibt und ich kein wildcard Zertifikat für "meineserver.de" kaufen möchte, muss ich doch für den server2 ein Domainzertifikat ordern welches dann auf "server2.meineserver.de" ausgestellt wird.
    Ist das korrekt??


    Danke und Gruß,
    Sacha

  • ... der Mailserver der Kunden heißt bei mir immer mail.kundendendomain.de
    wenn ich ein Zertifikat für server2.meinserver.de gekauft habe, welchen Mailserver muss der Kunde dann angeben damit Mail über ssl läuft?


    mail.server2.meinserver.de ???


    LG

  • Einfach nur server2.meinserver.de - ohne das Mail davor.


    Das mail.kundendomain.de kommt in der Regel durch den MX Eintrag. Dieser muss ein full qualified hostname sein und keine IP. Daher wird in der Regel ein mail.kundendomain.de Eintrag angelegt, welcher auf die IP des Servers zeigt.
    Programme wie Outlook verwenden dies gerne per Autokonfiguration. Hier muss der Kunde dann nur server2.meinserver.de verwenden.