14
Exchange, Reverseproxy mit Lets Encrypt Zertifikat: Best Practice
Hallo Exchangeadmins,
wir haben nen Exchange 2013 mit Reverseproxy auf Squid-Basis im Einsatz.
Bisher haben wir ein gekauftes Zertifikat (gleiches Zertifikat für beide) verwendet. Da dies demnächst ausläuft wollen wir auf ein kostenloses Let's Encrypt Zertifikat umstellen.
Hierzu hätte ich folgende Fragen, da ich noch nicht genau weiß wie man - vorallem das automatische Verlängern des Zertifikats - zuverlässig abbildet:
1.) Mir ist ehrlich gesagt nicht 100%ig klar, ob Exchange und Reverseproxy das gleiche Zertifikat verwenden müssen, oder ob es auch mit Unterschiedlichen geht?
Da ich meine im Hinterkopf zu haben, dass der Reverseproxy die Anfragen einfach 1:1 an den Exchange weiterleitet und nicht erst entschüsselt und wieder verschlüsselt braucht es wahrscheinlich das gleiche Zertifikat.
2.) Kann ich den Ausstellungs und Renewalprozess von Let's Encrypt öfters durchführen? Hintergrund der Frage ist, dass ich für diesen Fall separat jeweils vom Exchangserver aus und vom Reverseproxy aus das Zertifikat bzw. den Renewalprozess starten würde. Da ich davon ausgehe, dass jede Anfrage zu einem neuen Zertifikat führen würde und beide Server das gleiche Zertifikat benötigen (siehe 1.) ) wahrscheinlich keine funktionierende Lösung...
3.) Wäre eine mögliche Lösung den Renewalprozess des Zertifikat auf dem Reverseproxy durchführen und das erhaltene Zertifikat irgendwie (z.B. SMB Share) automatisiert auf den Exchange kopieren und hier das Skript zum Austauschen starten? Dieser Weg erscheint mir aber als fehleranfällig und unzuverlässig. Jedoch müsste ich nicht noch einen Port (80) für die Außenwelt aufmachen...
Wie habt ihr o.g. Problem in der Praxis zuverlässig gelöst?
Vielen Dank für Eure Hinweise,
Malungo
wir haben nen Exchange 2013 mit Reverseproxy auf Squid-Basis im Einsatz.
Bisher haben wir ein gekauftes Zertifikat (gleiches Zertifikat für beide) verwendet. Da dies demnächst ausläuft wollen wir auf ein kostenloses Let's Encrypt Zertifikat umstellen.
Hierzu hätte ich folgende Fragen, da ich noch nicht genau weiß wie man - vorallem das automatische Verlängern des Zertifikats - zuverlässig abbildet:
1.) Mir ist ehrlich gesagt nicht 100%ig klar, ob Exchange und Reverseproxy das gleiche Zertifikat verwenden müssen, oder ob es auch mit Unterschiedlichen geht?
Da ich meine im Hinterkopf zu haben, dass der Reverseproxy die Anfragen einfach 1:1 an den Exchange weiterleitet und nicht erst entschüsselt und wieder verschlüsselt braucht es wahrscheinlich das gleiche Zertifikat.
2.) Kann ich den Ausstellungs und Renewalprozess von Let's Encrypt öfters durchführen? Hintergrund der Frage ist, dass ich für diesen Fall separat jeweils vom Exchangserver aus und vom Reverseproxy aus das Zertifikat bzw. den Renewalprozess starten würde. Da ich davon ausgehe, dass jede Anfrage zu einem neuen Zertifikat führen würde und beide Server das gleiche Zertifikat benötigen (siehe 1.) ) wahrscheinlich keine funktionierende Lösung...
3.) Wäre eine mögliche Lösung den Renewalprozess des Zertifikat auf dem Reverseproxy durchführen und das erhaltene Zertifikat irgendwie (z.B. SMB Share) automatisiert auf den Exchange kopieren und hier das Skript zum Austauschen starten? Dieser Weg erscheint mir aber als fehleranfällig und unzuverlässig. Jedoch müsste ich nicht noch einen Port (80) für die Außenwelt aufmachen...
Wie habt ihr o.g. Problem in der Praxis zuverlässig gelöst?
Vielen Dank für Eure Hinweise,
Malungo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 505363
Url: https://administrator.de/forum/exchange-reverseproxy-mit-lets-encrypt-zertifikat-best-practice-505363.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
14 Kommentare
Neuester Kommentar
Hallo Malungo,
Exchange 2019 (adaptierbar) mit Sophos WAF + Sophos SMTP Check davor, alle drei mit LE Zert versorgt.
Viele Grüße,
Christian
certifiedit.net
PS: Was für eine Firewall/UTM setzt ihr ein?
Exchange 2019 (adaptierbar) mit Sophos WAF + Sophos SMTP Check davor, alle drei mit LE Zert versorgt.
Viele Grüße,
Christian
certifiedit.net
PS: Was für eine Firewall/UTM setzt ihr ein?
Zitat von @certifiedit.net:
Exchange 2019 (adaptierbar) mit Sophos WAF + Sophos SMTP Check davor, alle drei mit LE Zert versorgt.
Wie läuft das genau? Holen sich alle 3 separat die LE Zertifikate oder holt sich der Erste eines und verteilt es dann auf die Anderen? Sophos hat wahrscheinlich einen Automatismus hierfür eingebaut und kann es für WAF und SMTP Checker verwenden...aber wie kriegst Du es auf den Exchange?Exchange 2019 (adaptierbar) mit Sophos WAF + Sophos SMTP Check davor, alle drei mit LE Zert versorgt.
Ich habe meine ursprüngliche Frage nochmal angepasst, da nicht genau hervorging, dass ich primär daran interessiert bin wie ihr in einem Konstrukt Exchange + Reverse Proxy die automatische Verlängerung der Let's Encrypt Zertifikate abgebildet habt...
PS: Was für eine Firewall/UTM setzt ihr ein?
.
Was heisst sehr klein? Ich höre auch von 50 Mann Firmen, dass Sie "sehr klein" sind.
Grundsätzlich empfehle ich immer eine UTM (natürlich ordentlich eingerichtet, sonst ist der Router auch nicht schlechter...)
Und auch per Activesync hängt der Exchange irgendwie "echt" im Netz, schon wegen SMTP/S etc.
Grundsätzlich empfehle ich immer eine UTM (natürlich ordentlich eingerichtet, sonst ist der Router auch nicht schlechter...)
Und auch per Activesync hängt der Exchange irgendwie "echt" im Netz, schon wegen SMTP/S etc.
Hallo Malungo,
das kannst du durchaus so praktizieren, allerdings würde ich den Renew auf dem R-Proxy durchführen und dann per Skript das neue Zertifikat an den Exchange übertragen und einbinden lassen. Habe neulich versucht mit dem Certbot das ganze direkt am Exchange zu automatisieren, aber das ist alles andere als "intuitiv" und hat im Endeffekt nie richtig funktioniert.
edit: Mit UTM von Sophos etc habe ich persönlich keine guten Erfahrungen, da die zum Teil doch die Internetverbindung ausbremsen und sich bei den Clients tief im System verankern. Hatte neulich den Fall das eine UTM abgeraucht ist und ersetzt wurde. Die Client-Software lies sich nur mit großer Mühe wieder entfernen, weil die unbedingt vor/während der Deinstallation mit der - nicht mehr vorhandenen - UTM quatschen wollte.
Grüße
bloody
das kannst du durchaus so praktizieren, allerdings würde ich den Renew auf dem R-Proxy durchführen und dann per Skript das neue Zertifikat an den Exchange übertragen und einbinden lassen. Habe neulich versucht mit dem Certbot das ganze direkt am Exchange zu automatisieren, aber das ist alles andere als "intuitiv" und hat im Endeffekt nie richtig funktioniert.
edit: Mit UTM von Sophos etc habe ich persönlich keine guten Erfahrungen, da die zum Teil doch die Internetverbindung ausbremsen und sich bei den Clients tief im System verankern. Hatte neulich den Fall das eine UTM abgeraucht ist und ersetzt wurde. Die Client-Software lies sich nur mit großer Mühe wieder entfernen, weil die unbedingt vor/während der Deinstallation mit der - nicht mehr vorhandenen - UTM quatschen wollte.
Grüße
bloody
1
Es gibt eine Client Software? Ich kenne nur das Outlook Plugin und das Endpoint Security.
Wir dann wohl die Endpoint-Security gewesen sein. Ist schon ein wenig her.
Wer vom gleichen Anbieter UTM und Endpoint nimmt, gehört auch geschlagen, ich mein, glaubt ihr die AV Routine unterscheidet sich da groß?
(Ich vertreibe Sophos UTM, aber keine Endpoint Protection von denen).
(Ich vertreibe Sophos UTM, aber keine Endpoint Protection von denen).
Will mich hier nicht verteidigen oder drüber diskutieren, aber bitte spar dir doch solche vorurteilsgespickten Anfeindungen: Ich nehme davon gar nichts. Wir wurden als Helfer in der Not gerufen, weil der vorherige 1-Mann-Admin plötzlich nicht mehr erreichbar war. Ich habe nur von einem RL-Beispiel berichtet.
Zitat von @bloodstix:
Will mich hier nicht verteidigen oder drüber diskutieren, aber bitte spar dir doch solche vorurteilsgespickten Anfeindungen: Ich nehme davon gar nichts. Wir wurden als Helfer in der Not gerufen, weil der vorherige 1-Mann-Admin plötzlich nicht mehr erreichbar war. Ich habe nur von einem RL-Beispiel berichtet.
Will mich hier nicht verteidigen oder drüber diskutieren, aber bitte spar dir doch solche vorurteilsgespickten Anfeindungen: Ich nehme davon gar nichts. Wir wurden als Helfer in der Not gerufen, weil der vorherige 1-Mann-Admin plötzlich nicht mehr erreichbar war. Ich habe nur von einem RL-Beispiel berichtet.
Dann darfst du dich auch gerne nicht angesprochen fühlen. Was habt ihr denn im Einsatz?
Nebenbei, klar, wenn die UTM alle Funktionen anbietet und zu schwach dimensioniert wurde bremst die natürlich auch...
Bei der XG wäre es ein entscheidender Vorteil. Synchronized Security. Wenn ein Schädling vom Endpoint an die Firewall gemeldet wird, macht die Firewall die Verbindungen von und zu diesem Client dicht.
Macht Sie auch schon bei der SG. Nur aus eigenen Stücken, je nach dem kann man das besser oder schlechter finden, vom PC die Info ist ggf. schneller, aber wenn der PC schon geköpft ist gibt es ggf. einen fehlnegativ.
sorry, aber das hat doch nichts mit meiner Frage zu tun und geht am Thema vorbei! - wie auch fast ausschließlich die bisherige Diskussion mit Ausnahme von bloodys Beitrag! 
Also bitte zurück zum ursprünglichen Thema bzw. zu meinen Fragen.
Wer von Euch betreibt nen Exchange sowie nen Reverseproxy davor (auf Linux Basis) und verwendet hierfür Lets Encrypt Zertifikate? Wie bzw. mit welchen Tools bildet ihr einen zuverlässigen Renewableprozess ab?
Also bitte zurück zum ursprünglichen Thema bzw. zu meinen Fragen.
Wer von Euch betreibt nen Exchange sowie nen Reverseproxy davor (auf Linux Basis) und verwendet hierfür Lets Encrypt Zertifikate? Wie bzw. mit welchen Tools bildet ihr einen zuverlässigen Renewableprozess ab?
Wie gesagt, mit der SG und irgendwie geht das eben auch nicht am Thema vorbei, wenn man hier im falschen Use-Case die Sophos so hinstellt.
Ungeachtet dessen ist das nach wie vor ein Forum, das heisst auch, dass man Dinge breiter beleuchten darf.
Ungeachtet dessen ist das nach wie vor ein Forum, das heisst auch, dass man Dinge breiter beleuchten darf.
Moin,
Muss er nicht, wenn du intern und extern unterschiedliche TLDs bzw. DNS-Adressen für Autodiscover, ECP, EWS, etc... nutzt.
Der Reverse Proxy reicht die Anfragen selbstverständlich weiter, sonst wird's mit dem Zugriff schwer.
Gruß,
Dani
1.) Mir ist ehrlich gesagt nicht 100%ig klar, ob Exchange und Reverseproxy das gleiche Zertifikat verwenden müssen, oder ob es auch mit Unterschiedlichen geht?
Da ich meine im Hinterkopf zu haben, dass der Reverseproxy die Anfragen einfach 1:1 an den Exchange weiterleitet und nicht erst entschüsselt und wieder verschlüsselt braucht es wahrscheinlich das gleiche Zertifikat.Muss er nicht, wenn du intern und extern unterschiedliche TLDs bzw. DNS-Adressen für Autodiscover, ECP, EWS, etc... nutzt.
Der Reverse Proxy reicht die Anfragen selbstverständlich weiter, sonst wird's mit dem Zugriff schwer.
2.) Kann ich den Ausstellungs und Renewalprozess von Let's Encrypt öfters durchführen? Hintergrund der Frage ist, dass ich für diesen Fall separat jeweils vom Exchangserver aus und vom Reverseproxy aus das Zertifikat bzw. den Renewalprozess starten würde. Da ich davon ausgehe, dass jede Anfrage zu einem neuen Zertifikat führen würde und beide Server das gleiche Zertifikat benötigen (siehe 1.) ) wahrscheinlich keine funktionierende Lösung...
Da kann ich dir leider nicht folgen. Es gibt seitens Let's Encrypt natürlich Einschränken - siehe hier.3.) Wäre eine mögliche Lösung den Renewalprozess des Zertifikat auf dem Reverseproxy durchführen und das erhaltene Zertifikat irgendwie (z.B. SMB Share) automatisiert auf den Exchange kopieren und hier das Skript zum Austauschen starten? Dieser Weg erscheint mir aber als fehleranfällig und unzuverlässig. Jedoch müsste ich nicht noch einen Port (80) für die Außenwelt aufmachen...
Kann man machen, ist aber wahrscheinlich fehleranfällig. Neben der Validierung über das Verzeichnis ".well-known" ist es auch über einen TXT-Eintrag in der DNS-Zone der TLD möglich. D.h. du musst den Server nur ausgehend Zugriff auf LE geben. Kann man mit Hilfe von Appliaction Control auf einigen Firewalls sehr restriktiv konfigurieren.Gruß,
Dani
1
