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

NSP Zertifikatswechsel für Konnektoren

ffischer

Moderator

Hallo,
wildcard zertifikat wie immer erstellt und eingebunden.
Jetzt kommt immt wieder.

Bei der Überprüfung des privaten Schlüssels des Zertifikats mit dem Fingerabdruck ' 294A7611C745950EE8xxxxxxxxxx80C6CA ' ist unerwartet fehlgeschlagen. Ungültigen Anbietertyp angegeben Das Zertifikat wird von den Konnektoren ' Direct Zustellung Internet DNS ' verwendet.

Entferne ich das ganze Starte Gateway neu, lege dann wieder neu fest und wähle das Zertifikat aus, starte wieder Gateway neu, geht es dafür kommt dann ein anderer Konnektor mit dem Fehler.
 
Guten Morgen Frank,

ich schätze die Rechte auf den Privaten Schlüssel hast du auf allen Gateways zur Sicherheit schon überprüft?
 
Guten Morgen,
die sind im erstellten *.pfx mit drin. Werden jedes mit mit importiert. Der ändert sich ja nicht

Via mmc. zertifikate Computer - das Wildcard - Schlüssel Verwalten - rechte an System und lokaler\Admin

Edit:
habe am Privaten Schlüssel den benutzer "Lokaler Dienst" hinzugefügt.
bisher alles grün

1.
1715841110723.png

2.Lokaler Dienst hinzufügen - Speichern / Dienst neustarten
1715841136498.png
 
Zuletzt bearbeitet:
Hallo Frank,
ich habe mal auf meinen Instanzen nachgesehen und dort ist überall im Zertifikat bei den Berechtigungen die drei NSP Accounts eingetragen.
1715946963056.png
Mit dieser Konstellation habe ich bis dato keine Probleme gehabt.

Ein weiterer Unterschied ist, dass ich grundsätzlich keine Wildcard Zertifikat verwende. Sollte technisch gesehen keinen Unterschied machen, aber ich möchte es erwähnen.


Gruß,
Dani
 
Zuletzt bearbeitet von einem Moderator:
Hallo @869288141 ,
hab heute mal danach geschaut aber die Nutzer erscheinen bei mir nicht.

Nach einem regulären neustart kommt heute mal wieder eine neue Meldung.

Bei der Überprüfung des privaten Schlüssels des Zertifikats mit dem Fingerabdruck ' 294A7611Cxxxxxxxxxxxxx080C6CA ' ist unerwartet fehlgeschlagen. Das geöffnete CNG-Schlüsselhandle ist kurzlebig, aber die EphemeralKey-Option wurde beim Öffnen nicht angegeben.
Parametername: keyHandleOpenOptions Das Zertifikat wird von den Konnektoren ' Direct Zustellung Internet DNS ' verwendet.


Immer mal was neues. Mal sehen was jetzt wieder los ist. Irgend was stimmt hier nicht :unsure:
 
Guten Morgen Frank,
hab heute mal danach geschaut aber die Nutzer erscheinen bei mir nicht.
Das sind NT Services. Nach denen kann man meine ich nicht suchen. Gerne per Skript setzen: Link
Bei der Überprüfung des privaten Schlüssels des Zertifikats mit dem Fingerabdruck ' 294A7611Cxxxxxxxxxxxxx080C6CA ' ist unerwartet fehlgeschlagen. Das geöffnete CNG-Schlüsselhandle ist kurzlebig, aber die EphemeralKey-Option wurde beim Öffnen nicht angegeben.
Parametername: keyHandleOpenOptions Das Zertifikat wird von den Konnektoren ' Direct Zustellung Internet DNS ' verwendet.
Hast du die Möglichkeit temporär ein LE Zertifikat mit dem entsprechenden SANs zu beziehen und dieses zu nutzen? Nur um wirklich das Zertifikat auszuschließen.

Gruß,
Dani
 
Zuletzt bearbeitet:
Hallo Dani,
ja bestimmt ein LE Zertifikat.
Gabs doch mal ein Tool was das automatisch beziehen kann.

Wenn es am Zertifikat liegen würde, wäre das schon sehr wunderlich.
Sophos XGS WAF läuft normal damit bisher.
Ich schau nachher nochmal genau nach.
Danke für den Link, auch den prüfe ich.
 
Hallo Dani,
habe mir das jetzt nochmal angesehen und mit dem POSH-Acme versucht.
Zertifikats Antrag raus und alles ist da.

Eingehend zugewiesen auf 2 Konnektoren, nach dem Import PFX mit zert,priv und kette
Erster Konnektor Port 25 keine Fehler in der Konsole
Aber zweiter Konnektor:
Bei der Überprüfung des privaten Schlüssels des Zertifikats mit dem Fingerabdruck ' 48B6A93D1xxxxxxxxxxxxxxxxxxxxxx038AC4B ' ist unerwartet fehlgeschlagen. Ungültigen Anbietertyp angegeben Das Zertifikat wird von den Konnektoren ' SMTPS 587 an 192.168.210.110 ' verwendet.

Edit: Ich musste noch unter C:\ProgramData\Microsoft\Crypto\Keys die Rechte vergeben, über die MMC Console gab es Fehler ( Speicher nicht möglich - Falscher Parameter)
 
Zuletzt bearbeitet:
Hallo Frank,
Eingehend zugewiesen auf 2 Konnektoren, nach dem Import PFX mit zert,priv und kette
Wenn du die betroffene Umgebung einmal beschreibst, versuche ich es gerne nachzustellen.
  • Du hast du eine oder zwei Gateway Rollen?
  • Den Konnektor mit Port 25 hab ich auch. Auf welchen Port lauscht der zwei Konnektor?
  • Welche Windows Server Version und Edition kommt bei dir auf den Servern, auf denen die NSP Intranet und Gateway Rolle zum Einsatz?
Edit: Ich musste noch unter C:\ProgramData\Microsoft\Crypto\Keys die Rechte vergeben, über die MMC Console gab es Fehler ( Speicher nicht möglich - Falscher Parameter)
Kam der Fehler durch die Verwendung des Posh Skripts oder auch beim Versuch es manuell zu tun?


Gruß,
Dani
 
Hallo,

Posh Script lief durch, das erstelle pfx konnte ich auch importieren.
Das Problem am Konnector bliebt gleich.
Nachdem ich die Rechte geändert hatte ging es dann. Das konte ich aber nicht in der Zertifikat \ Computer ändern.
unter C:\ProgramData\Microsoft\Crypto\Keys das nach dem Import erschienene korrigiert mit den Rechten.

Server 2019 Std.

Der 25er Konnektor ist der der alles annimmt.
Der andere Konnektor war auf Port 587
 
Hallo Frank,
ich habe einen neuen Empfangs Konnektor, welcher auf Port 587 lauscht und STARTLS verwendet, angelegt
1716225674570.png
Danach alle NSP Server (Intranet und Gateway) neu gestartet. Leider konnte ich da Problem nicht nachstellen. Wobei das bei mir verwendete SSL-Zertifikat kein Wildcard ist.

Nachdem ich die Rechte geändert hatte ging es dann. Das konte ich aber nicht in der Zertifikat \ Computer ändern.
unter C:\ProgramData\Microsoft\Crypto\Keys das nach dem Import erschienene korrigiert mit den Rechten.
Kann ich leider ebenfalls nicht nachstellen. Klingt für mich so, als wäre mit dem Windows Server etwas nicht mehr in Ordnung.

Ich habe exemplarisch über den Windows Explorer den Benutzer Local System auf den privaten Schlüssel meines Zertifikats berechtigt. Anschließend über die MMC, für das selbe Zertifikat bw. Private Key, den Network Service hinzugefügt. Hat alles ohne Fehlermeldung oder ähnliches funktioniert.
Perfekt, das ist auch die Grundlage bei mir im Lab.

Gruß,
Dani
 
Hallo, Dani,
vor dem Austausch des Zertifikates lieg alles normal.
Seit dem Wechsel verg. Woche Mittwoch, passierte das.

Aber jetzt sieht es normal aus. Ich beobachte das ganze mal.
Danke für deine Hilfe.

Grüße
 
Ich beobachtete den Ordner C:\ProgramData\Microsoft\Crypto\Keys
Importierte das Zertifikat und sah dann den "Privaten" Schlüssel im Verzeichnis oben.
Dort dann Eigenschaften und Sicherheit und dort den Benutzer "NT Service\NoSpamProxyGatewayRole" Hinzufügen Lesen setzen,
GW Rolle neustarten.
Fertig Fehler waren weg,
 
Ja genau das kannte ich auch.

Aber bei Punkt:
  1. Fügen Sie die Gatewayrolle über Hinzufügen > Objektname "nt service\NoSpamProxyGatewayRole" hinzu und geben Sie dieser Leseberechtigungen auf den Schlüssel.
das klappte nicht mehr wegen dem Fehler, hier nochmal der Screenshot:
1716231381009.png
Möglicherweise liegt es aber, wie du auch schon vermutest hast, am WIndows Server selbst.
 
Guten Morgen,

schön, dass du das problem lösen konntest.
Die Crypto Keys werden ausschließlich vom Windows verwaltet, das ist schon etwas merkwürdig, dass es da Probleme beim setzen der Rechte gab :S

Das würde ich noch etwas beobachten ;)

LG
Jan
 
Zurück
Oben