• 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. 

Installierte Zertifikate werden nicht verwendet / gefunden

Fabian_FD

Member
Hallo zusammen,

seit kurzem setzen wir den NoSpamProxy (14.0.5) zur Sicherung unseres E-Mail-Verkehrs ein. Das Setup ist recht einfach, ein Gateway Server in der DMZ und die Intranetrolle hinter einer weiteren Firewall.

Langfristig wollen wir die Zertifikate über eine MPKI beziehen, da wir aber bis 2025 noch aktive S/MIME Certs haben habe ich diese nun erstmal mitsamt des privaten Schlüssels im NoSpamProxy hinzugefügt.

Ebenfalls habe ich die öffentlichen Zertifikate und privaten Roots (z.B. Bayern Root CA) importiert.

Beim Versand von Test-Mails an unsere Partner habe ich nun feststellen müssen, dass e-Mails scheinbar willkürlich signiert und verschlüsselt werden: name1@wir.de möchte eine mail an name2@partner.de versenden. Die entsprechenden Regeln sehen eine Signierung und Verschlüsselung der Mail vor sofern alle Zertifikate im NoSpamProxy bekannt sind. Bei einer ersten Test-Mail hat dies gut geklappt. Eine zweite Mail (gleiche Absender-Empfänger-Paarung) wird auf einmal unverschlüsselt und unsigniert versendet. Die Nachrichtenverfolgung sagt dazu:
- Die E-Mail wurde für den Empfänger name2@partner.de nicht verschlüsselt, da kein Verschlüsselungsschlüssel gefunden werden konnte.
- Die Nachricht konnte nicht signiert werden, da kein Signatur Schlüssel für den Absender name1@wir.de verfügbar ist.

Wechsle ich in die Zertifikatsliste sind alle Zertifikate als gültig vorhanden. Für den Empfänger sind sogar zwei gültige Zertifikate mit unterschiedlichen Fingerprints und leicht unterschiedlicher Gültigkeit vorhanden.

Ein Neustart der Rollen brachte keine Besserung.

viele Grüße
Fabian
 
Wechsle ich in die Zertifikatsliste sind alle Zertifikate als gültig vorhanden. Für den Empfänger sind sogar zwei gültige Zertifikate mit unterschiedlichen Fingerprints und leicht unterschiedlicher Gültigkeit vorhanden.
Moin Fabian

puhh...gar nicht so einfach und ein Bug ist nicht bekannt, ich tippe mal fast auf einen Fehler mit der Replikation.

Schau doch mal bitte in der NCC nach und filtere dort auf Fehler:

1683270137014.png

Sollten dort keine Fehler auftauchen, könnte es auch sein, dass das Gateway die Zertifikate nicht validieren kann... sind 80 und 389 ausgehend erlaubt?

kannst du mit einer cmd testen: certutil -url <pfad zu einem public key der nicht genommen wird>
 
Hallo,
wenn das LDAP bybn verwendet wird und nicht der NSP nicht im Behördennetzwerk ist
muss directory.bayern.de verwendet werden.
Sollte zugriff ins Behördennetzwerk vorhanden sein dann directory.bybn.de

Habe ich kontakt mit Empfängern mit Zertifikaten an das bybn die sind immer verschlüsselt und von mir signiert
 
Hallo,
ich habe eine Vermutung.

Schau doch mal bei Unternehmensbenutzern nach.
Such dir einen Benutzer raus der die Zertifikate hat. Wenn die Zertifikate von Bybn kommen
sollte ja Zertifikate drin stehen Signatur und Encryption.

Kann es sein das bei Signatur das Siegel ohne "Grünen" Hacken drin ist ?
Ändere das mal um.
1683277047641.png
denn wenn es nur das Siegel ohne "Grün" ist dann ist es unterstützt aber nicht ausgewählt.
1683277117538.png

nur eine Vermutung für nicht ausgehendes Signieren

Vielleicht gibt es ein Script von NSP, welches diese Option am Benutzer direkt setzten kann, weil etliche Benutzer einzeln durchgehen, das dauert schon eine weile.
 
Zuletzt bearbeitet:
Hallo,

vielen Dank schon mal für eure Antworten. Ich denke ich konnte das Problem mittlerweile nachvollziehen (und einen "Workaround" finden).

- Die Zertifikate waren alle korrekt in den Datenbanken für die Gateway-Rolle und Intranet-Rolle hinterlegt. Ich habe das sowohl mit dem SQL-Management Studio als auch mit den hilfreichen Power-Shell-Kommandos verifiziert.

- Der nächste Schritt war die Logging-Funktion entsprechend einzuschalten und svclogs auf dem Gateway und der Intranetrolle zu generieren. Die logs lassen sich recht schön mit dem Microsoft ServiceTraceViewer visualisieren. In den logs konnte ich nicht feststellen, dass Zertifikaten nicht gefunden werden - ganz im Gegenteil selbst bei den Mails die unsigniert rausgingen hat das Gateway laut Service-Log erfolgreich das private Zertifikat für den Absender "gefunden".

Bei einer weiteren Betrachtung sind bereits von Outlook signierte Mails das "Problem". NSP bietet explizit eine Option signierte Mails aus Outlook zuzulassen, versucht Sie beim Versand neu zu signieren - was fehlschlägt und dann in der GUI die völlig falsche Fehlermeldung produziert, dass für den Absender kein Zertifikat gefunden wurde... Sofern man "signieren" am NSP via Regel, Outlook-Add-In, oder Betreffmarkierung erzwingt wird eine von Outlook signierte mail sogar abgewiesen. Das bessere Verhalten wäre, die vorhanden Signatur zu prüfen (der Schlüssel ist ja da...) und diese einfach weiterzuverwenden, da ja nix schlimmes dabei passiert. Die Fehlermeldung sollte überarbeitet werden, das hätte das Debugging dann doch erheblich beschleunigt :)

Aktuell hat unser NSP nur eine Default Regel die allen Verkehr signiert/verschlüsselt wenn möglich, eine LDAP-Anbindung an O365 ist noch nicht erfolgt, aktuell auch noch nicht geplant, da es "nur" 50 Nutzer sind. Die Kommunikation mit bestimmten Partnern werden wir demnächst auf Verschlüsselt erzwungen über zusätzliche Regeln konfigurieren.

Wir befinden uns nicht im bybn - kommunizieren aber sehr viel mit Behörden.

viele Grüße
Fabian
 
Nicht nur das auch das VErhalten sollte eigentlich korrekt sein o.0
Könntest du uns das SVCLog zur Verfügung stellen?
Dann kann ich das mit der Entwicklung einmal gegensprechen. Natürlich nur per E-Mail oder direkt Nachricht ;)
 
Nicht nur das auch das VErhalten sollte eigentlich korrekt sein o.0
Könntest du uns das SVCLog zur Verfügung stellen?
Dann kann ich das mit der Entwicklung einmal gegensprechen. Natürlich nur per E-Mail oder direkt Nachricht ;)
Ich kann gerne Morgen mal ein kurzes SVCLog erstellen und per Mail (wie ist die Adresse?) rüberschicken, das die Fälle berücksichtigt. Aktuell sind die Protokoll-Chunks etwas unglücklich groß. Letztlich könnte die Entwicklung das verhalten aber auch super einfach selbst reproduzieren indem sie

- eine bereits in Outlook signierte Mail mit dem Betreff [Signieren] verschickt - sollte vom NoSpamProxy mit dem Fehler kein Zertifikat gefunden abgelehnt werden
- eine bereits in Outlook signierte Mail *ohne* das Keyword versenden - sollte vom NoSpamProxy durchgelassen werden (Vorausgesetzt die Regel passt), aber unter Aktivität in der Nachrichtenverfolgung ist sichtbar dass kein Zertifikat gefunden wurde und die mail nicht signiert wurde
- eine in Outlook unsignierte Mail versenden, diese wird dann korrekt signiert.

Das Zertifikat in Outlook und NSP ist das gleiche.

viele Grüße
Fabian
 
Guten Morgen Fabian,

so ausführliche Schritte helfen natürlich auch weiter :)
Da kannst du das SVCLog erst einmal sein lassen und wir schauen das wir es in unserern System direkt nachstellen.

Vielen Dnak dafür ^^
 
Zurück
Oben