[Eisfair] mail & Cert mail-manager Zertifikat anzeigen

Marcus Röckrath marcus.roeckrath at gmx.de
Do Jul 23 08:29:04 CEST 2020


Hallo Kay,

Kay Martinen wrote:

>> Da ist dann der eis in der Serverrolle und braucht damit auch ein
>> Zertifikat. Für den Zugriff von extern bietet sich letsencrypt an, da ein
>> solches Zertifikat jeder Client unmittelbar, weil von einer bekannen CA
>> unterzeichnet, prüfen kann.
> 
> LetsEncrypt aber nur wenn Zugriffe von Außen NICHT per VPN liefen, denn
> dann ist der Client ja im "Internen Netz" wenn ich dich unten richtig
> verstehe.

Ja, per VPN befindest du dich ja schon verschlüsselt im Zielnetz. Wenn man
das nun auch mittels letsencrypt-Zertifikat im Mailclient betreiben will,
müsste der Client im Mailprogramm mit "eis.meine.domain" statt IP arbeiten
und das dann auf die interne IP umbiegen, z. B. indem der Client den DNS im
Zielnetz benutzt, wenn dort eine solche Umschreibung existiert.

>> Um ein solches letsencrypt-Zertifikat auch im internen LAN zu nutzen,
>> muss auch aus dem internen LAN der Zugriff über die externe Adresse, also
>> nicht über eine lokale IP, erfolgen. Damit die Verwendung der externen
>> Domain den Traffik dennoch im internen LAN hält, müsste man im internen
>> DNS dafür sorgen, dass solche Anfragen direkt an den Server im internen
>> Netz umgeleitet werden.
> 
> Das klingt komplizierter, nach Umweg und für mich nicht machbar.

Wenn man den DNS einer Fritzbox benutzt, wird man Probleme haben, so etwas
überhaupt zu definieren - ich habe nichts gefunden.

Betreibt man sowieso einen bind im eigenen Netz, dürfte das mit einer Zeile
in der Konfiguration erledigt sein.

IMHO sollte man es im eigenen Netz nicht übertreiben, wenn man die übichen
Sicherheitsvorkehrungen beherzigt - starke WLAN-Passwörter. Wenn sich
jemand physischen Zugang zu deinem Netz verschaffen kann, ist eine
unerverschlüsselte Mailnutzung im internen netz dein kleinstes Problem.

> Ich hab 
> ja einmal den WAN-Router, das Zwischennetz in dem dieser Server liegt
> und den internen Router der nach außen hin eh NAT macht. Wenn ich aber
> überlege das ich mit einer QuellIP von z.b. 192.168.1.10 die durch NAT
> auf 192.168.2.2 übersetzt wird den EIS unter 192.168.2.100 nicht
> ansprechen sollte, sondern dies evtl. über eine "externe" IP (Welche?

Für den externen Zugriff brauchst du eine eigene Domain, die die weltweiten
DNS-Server auf deine externe IP übersetzen - z. B. einen dyndns-Dienst.

> Die WAN-IP des WAN-Routers?) ansprechen soll dann weiß ich nicht wie ich
> das umsetzen sollte. Ein portforward der das vom Router wieder zurück
> schmettert zum EIS erscheint mir unsinnig und das einzige was ich machen
> kann ist meinem internen DNS die IP des EIS im Zwischennetz übersetzen
> zu lassen (A und Rev) aber ...???

Du hast also sowas?

Internet - 1. Router (Typ?) - eis - 2. Router (Typ?) - internes Netz

Welcher Router macht DNS für dein lokales Netz?

>> letsencrypt-Zertifikate werden nicht auf IPs ausgestellt!
> 
> Dann würde ich die VPN-Lösung präferieren. Da der Tunnel eh schon
> verschlüsselt könnte ich den VPN-Server auch auf dem EIS einrichten.
> Dann bräuchte ich auch keine CA weil imap da dann auch unverschlüsselt
> durch laufen kann. Scheint mir einfacher weil ich dann doch auch alles
> auf die IPs des VPN Limitieren könnte. Und des Lokalen Netzes.

Ja so könntest du es tun.

>> Klar, aber dafür braucht man kein lokales Zertifikat; bei diesem Vorgang
>> wird das Zertifikat des externen Mailproviders (also z. B. gmx) auf dem
>> eis beim Connect geprüft.
> 
> Also keine CA bei fetchmail-abruf nötig.

Ja.

>> s. o. Hierfür bräuchte der eis ein Zertifikat, wenn das verschlüsselt
>> geschehen soll. (*)
> 
> Also keine CA wenn imap unverschlüsselt bleiben kann.

Ja.

>> Bei einem sonstigen Zugriff über das Internet wäre die Verschlüsselung
>> ratsam.
> 
> Internet: *Böse* Nicht mit Füßen ins Wasser, Haie! :-/ Eine Schande das!

Es gibt durchaus Szenarien, bei denen man auch von außen auf seinen eigenen
Mailserver ohne VPN zugreifen will. Dann wäre Verschlüsselung im
Mailverkehr Pflicht.

>> Hast du schon jemals gehört, das ein normaler TB-Anwender zum Abruf der
>> Mails beim Provider sich um ein eigene Zertifikat samt CA kümmern müsste?

> Nee, aber TB machte das neulich fast automatisch.

Aber doch nicht den Aufbau einer lokalen CA samt Zertifikat. Wozu? Wie
sollte davon jemand externens Kenntniss davon bekommen. Dein CA
interessiert niemanden, wozu sollte irgendjemand einfach so einem selbst
erstellten Zertifikat und CA trauen.

> Zeigt ein neues 
> Zertifikat an weil das alte ablief und es dauerte ein paar Mausklicks
> bis es wieder lief.

Da gehts aber nicht um dein lokales Zertifikat sondern um die der
Gegenstellen, also die der Provider.

Übrigens speichert der TB nicht die Zertifikate der Mailprovider ab, sondern
er hat den ganzen Zoo von Rootzertifikaten (im eis das CA-Bundle, das kommt
nämlich gnau von Mozilla) installiert, um das vom Provider dargebotene
Zertifikat prüfen zu können.

>> Falsch; um das angebotene Serverzertifkat z. B. von gmx prüfen zu können,
>> muss das Root-Zertifikat auf dem System vorhanden sein, nicht das
>> gmx-Zertifikat.
> 
> Dann brauche ich das Zertifikats-bundle (wg. Root-CAs) oder nur die von
> meinen Providern?

Wenn du das Bundle drauf hast, bist du für alle Fälle gewappnet. Die große
Menge an Root-Zertifikaten führt allerdings schonmal zum Verschlucken der
CRL-Aktualisierung (Wiki-Artikel: CRL-Bereinigung).

Wenn man weiß, welche Zertifikate zur Prüfung des Mailserverzertifikates
gebraucht werden, kann man natürlich alle anderen unnötigen wieder
entfernen, was aber viel Handarbeit ist.

Wenn man sich mit dem ganzen Zertifikatshandling icht sicher ist, packt man
das ganze Bundle drauf, wie es auch im TB oder Firefox üblich ist.

> Mir fällt eben etwas auf was die Idee mit dem EIS in dem Zwischennetz
> ad-absurdum führte. Mein ipfire (Zwischen-router) hat eh ein VPN an
> bord. Kann ich im Prinzip auch dort auf setzen und muß das VPN Netz nur
> nach innen durch lassen zu einem Mailserver der im Internen Netz liegen
> kann. Dann kommen zugriffe entweder vom internen oder vom Transfernetz
> des VPN und fetchmail oder Smarthost-Verbindungen werden dann eh durch
> das NAT zum Provider geschickt. Bin nicht sicher aber das klingt fast
> noch einfacher aber Besser/Sicherer? Bei IMAP ohne TLS aber nur Intern
> oder durch VPN?

Kling ok.

> Ja, ich meide diese CA Sachen wenn es geht. Ich werde auch nur älter. :-/

In Coronazeiten bemisst man das in Form der Zugehörigkeit zu einer
Risikogruppe - ich durfte bis in den Juni hinein nicht arbeiten.

-- 
Gruß Marcus
[eisfair-Team]


Mehr Informationen über die Mailingliste Eisfair