• Bewerte uns auf OMR Reviews: Klick

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

  • Wichtige Information für alle, die noch nicht auf v14.0.5.39 sind:

    Cyren Antimalware kann nicht mehr verwendet werden. Unsere Lizenz ist endgültig deaktiviert, so dass der Dienst nicht mehr nutzbar ist.
    Bitte stellt sicher, dass ihr schnellstmöglich auf die aktuelle Version aktualisiert. Bis es so weit ist, empfehlen wir die Cyren Antimalware Aktion zu deaktivieren und mindestens den lokalen Virenscanner zu aktivieren. Sollte kein anderer Scanner als Cyren aktiv sein, kommt es unweigerlich zur Abweisung von E-Mails.

    Zusätzlich raten wir dazu, die Cyren Filter zu deaktivieren, hier ist der Einfluss zwar geringer, solange alle anderen Filter korrekt durchlaufen, aber im Problemfall kommt es ebenfalls zur Abweisung.

     

    Unser Blogbeitrag wird in Kürze ebenfalls aktualisiert.

    Beste Grüße
    Euer NoSpamProxy Team

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

Nutzung von Lets Encrypt

SBW

Well-known member
Hallo NSP Team,
ich beschäftige mich zurzeit mit dem Einsatz von Let's Encrypt (Zertifikaten auf Webservern. Dazu zählen auch die Server, auf denen das NSP Webportal installiert ist.

Knackpunkt ist wohl nicht das Webportal selbst, sondern das die Intranet-Rolle von NSP. Und zwar dahingehend, dass nach dem Tausch des SSL-Zertifikats der neue Fingerabdruck in der Konsole explizit akzeptiert werden muss. Ich habe zum besseren Verständnis einen Screenshot angehängt.

Bei gekauften Zertifikaten mit einer Laufzeit von einem Jahr, ist die manuelle Bestätigung einmal pro vertretbar. Nun beträgt die Laufzeit bei LE Zertifikaten drei Monate. Zudem werden die Zertifikate in unregelmäßigen Zeitabständen (um Ratelimits unseres Domain Hoster und LE aus dem Weg zu gehen) regelmäßig gewechselt. D.h. ich muss alle 3 Monate für jeden Server des Webportals das neue Zertifikat zu bestätigen. Solange ich diese nicht bestätige, erfolgt laut meinen Tests keine Synchronisation mehr. Was somit ein möglicher Impact für die Endanwender bedeutet.

Daher interessiert mich brennend (und andere evtl. auch), wie Eurerseits das Best Practice für dieses Szenario aussieht? LE kann man heutzutage nicht mehr wegdiskutieren.


Grüße,
Daniel
 

Anhänge

  • 2021-10-03 16_39_01-Remote Desktop Manager [nsp02].png
    2021-10-03 16_39_01-Remote Desktop Manager [nsp02].png
    25.2 KB · Aufrufe: 10
Hi,

naja - intern für die Intranetrolle würde ich nicht unbedingt ein LetsEncrypt Zert nehmen. Für sowas nimmt man normalerweise eines von der internen Zertifizierungsstelle und wenn man keine hat, würde ich einfach das Selfsigned per GPO auf die Rechner verteilen.

Für extern zugängliche Dienste macht Lets Encrypt aber sicherlich Sinn

just my2ct
 
Guten Morgen Robert,
naja - intern für die Intranetrolle würde ich nicht unbedingt ein LetsEncrypt Zert nehmen.

Wie gesagt es geht mir primär um das Webportal. Natürlich wäre auch die Gateway Rolle wünschenswert. Die Intranet Rolle ist mir eigentlich egal.
 
Hallo zusammen,
in der V14 ist schon eine Implementierung für Lets Encrypt Zertifikate enthalten. Primär ist sie dafür da, um zB das Zertifikat für den Empfangskonnektor sicherzustellen. Das alles läuft voll automatisch. :)
Gruß Stefan
 
Hallo Stefan,
freut mich zu hören, dass das Thema bei euch einen Platzhalter hat. Wie erfolgt die Validierung, über http-01 Challenge?

Das bedeutet für mich im Umkehrschluss, dass ich bei hochverfügbaren Umgebungen (inkl. Load Balancer) wie bei uns, weiterhin auf eigene Lösung (dns-01 Challenge) angewiesen bin oder greift ihr auf Entwicklungen wie Posh-ACME o.ä. zurück?


Gruß,
Daniel
 
Ich fürchte, dass ich hier zurückrudern muss. Die Lets Encrypt Anbindung haben wir für unsere Cloud Plattform eingebaut. Ich nehme das aber gerne noch einmal zum Anlass, um das auch in das Server-Produkt mit einfließen zu lassen.
Sorry für den Wirbel.
Gruß Stefan
 
Hallo Stefan,
Danke für die Korrektur. Bitte führt keine zwei Klassengesellschaft (Cloud und OnPrem) ein. Das sorgt früher oder später für Frust bei Kunden.
Damit komme ich wieder zu meiner ursprünglichen Frage. Wie kann ich mit dem Fingerprint umgehen?


Gruß,
Daniel
 
Hallo Stefan,
die Rahmenbedingungen haben sich nicht geändert. Ich habe mir nochmals Gedanken darüber gemacht.
Gibt es ein PowerShell cmdlet, um geänderte Fingerprints zu bestätigen/aktualisieren?


Gruß,
Daniel
 
Hallo Daniel,

leider noch nicht.
Dies wollen wir aber unbedingt mit umsetzen da es die Automatisierung deutlich verbessern würde.

Stand jetzt muss immer manuell über die Konsole das neue Zertifikat akzeptiert werden.

Gruß
Jan
 
Hallo Jan,
auf Grund der aktuellen Situation (Migration zu V14) und dem Ablauf unseres Zertifikats, würde mich der Status Quo zu LE und Webportal interessieren.


Gruß,
Daniel
 
Guten Morgen Daniel,

hier gibt es durch uns ledier noch keine Unterstützung. Es müsste aktuell weiterhin auf tools wie "Certify the Web" zurück gegriffen werden.
Mit den beiden CmdLets:
- Get-NspIssue
- Invoke-NspIssueAction

Könntest du dann automatisch das neue zertifikat akzeptieren lassen, zumindest das ist schon einmal ein Vorteil der v14 :)


Gruß
Jan
 
Hallo Jan,
das bekomme ich vermutlich hin. ;-)
Wo finde ich die Doku zu den beiden cmdlets?


Gruß,
Daniel
 
Hallo,

leider können wir hierzu noch keine Dokumentation zur Verfügung stellen.

Nach einem kurzen Test der genannten CmdLets wurde festgestellt dass diese, mit der aktuellen Version 14.0.2, nur für Issues der Gatewayrolle funktionieren. Issues der Intranetrolle können damit (noch) nicht bestätigt werden. Dazu zählt leider auch das Issue zum Bestätigen der neuen Web Portal Zertifikats. Hierzu wurde die Erweiterung bereits beauftragt.

Beispiel zur Bestätigung eines Issues:
PS C:\Users\Administrator> Get-NspIssue

Role        : NSP02
Severity    : Warning
ReportedOn  : 04.11.2022 10:24:07
Text        : The Gateway Role TLS settings are not configured according to best practices. Please review the
              configuration on the 'Advanced settings' node.
IsActionable : True
ActionName  : Dismiss
Id          : TlsBestPracticeIssue

PS C:\Users\Administrator> Invoke-NspIssueAction -id TlsBestPracticeIssue -role NSP02

Gruß Thomas
 
Hallo, als Anregung: bei uns ist das Webportal hinter einem nginx reverse-proxy der sich auch um die Erneuerung der lets encrypt Zertifikate kümmert. Auf dem IIS ist das selbstsignierte Zertifikat hinterlegt, was aber Niemand zu Gesicht bekommt! So machen wir das auch mit anderen veröffentlichten Webservern. VG Nico
 
Hallo eisback,
in wie weit erfüllt dein Vorschlag meine Anforderun? Wenn ich es richtig verstehe, verschiebe ich das Problem nur von Backend ins Frontend.
Unabhängig davon müsstest du dann alle x Wochen in der MMC das neue Zertifikat händisch bestätigen, oder?


Gruß,
Daniel
 
Nicht wenn Du auf dem NSP dafür sorgst, dass der FQDN des Webportals mit der internen IP aufgelöst wird, also die HOST-Datei bearbeitest. Zuvor solltest Du das interne Zertifikat vom Web Portal zu den vertrauenswürdigen Stammzertifizierungsstellen hinzufügen damit es vertrauenswürdig ist. Wir setzen das Webportal derzeit noch nicht aktiv ein, sind noch am vorbereiten, aber das sollte so klappen!
 
Das funktioniert natürlich, wenn man die aktuelle Sicherheitsarchitekturen nicht (strikt) verfolgt. Wer dies aber tut oder sogar muss (IT-Sicherheit, ISO Zertifizierungen, etc.), fällt damit in zweifacher Hinsicht auf die Nase.

Heutzutage sollte man das Webportal ausschließlich über eine Perimeter-Firewall und WAF bereitstellen. Das gilt nicht nur für Zugriff aus dem Internet sondern auch aus dem LAN. Denn weder die Applikationen noch der Windows Server sind heute von möglichen Angriffen oder Nutzung von Sicherheitslücken gefeilt. Somit ist der Zugriffsweg immer Client -> Firewall -> WAF (-> LB) -> Webportal Server. Somit muss auch die Zertifikatskette zu 100% von allen Geräten validiert werden können, um mögliche Manipultationen in der Kette o.ä. feststellen zu können.

Des Weiteren sollte man immer daran denken, dass Zugriffe aus dem LAN in die DMZ in Ordnung sind, aber niemals von der DMZ ins LAN. Das ist am Anfang teilweise umständlich und es muss ein Undenken bei der Planung von Netzwerk- und Systemarchitekturen stattfinden. Aber schlussendlich eine weitere Hürde im Sicherheitskonzept um es für mögliche Angreifer so schwer wie möglich zu machen.
 
Zurück
Oben