NSP Zertifikatswechsel für Konnektoren

[ffischer]

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.

 

[JanJäschke]

Guten Morgen Frank,

ich schätze die Rechte auf den Privaten Schlüssel hast du auf allen Gateways zur Sicherheit schon überprüft?

 

[ffischer]

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.


2.Lokaler Dienst hinzufügen - Speichern / Dienst neustarten

 

[869288141]

Hallo Frank,
ich habe mal auf meinen Instanzen nachgesehen und dort ist überall im Zertifikat bei den Berechtigungen die drei NSP Accounts eingetragen.

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

 

[ffischer]

Hallo Dani,
ich werde das nachher mal anpassen und probieren mit den 3 Diensten.

 

[ffischer]

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

 

[869288141]

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

 

[ffischer]

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.

 

[869288141]

Gabs doch mal ein Tool was das automatisch beziehen kann.

Puh, gibt es sicherlich einige. Ich mach es mit Posh-ACME, weil ich den Automatisierungsgrad hochhalten möchte.

Wenn es am Zertifikat liegen würde, wäre das schon sehr wunderlich.

Recht glauben kann ich es aktuell auch nicht. Aber glauben reicht eben nicht immer.

 

[ffischer]

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)

 

[869288141]

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

 

[ffischer]

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

 

[869288141]

Hallo Frank,
ich habe einen neuen Empfangs Konnektor, welcher auf Port 587 lauscht und STARTLS verwendet, angelegt

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.

Server 2019 Std.

Perfekt, das ist auch die Grundlage bei mir im Lab.

Gruß,
Dani

 

[ffischer]

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

 

[869288141]

Aber jetzt sieht es normal aus. Ich beobachte das ganze mal.

...was hast du final getan, damit der Fehler nicht mehr auftritt?!

 

[ffischer]

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,

 

[869288141]

Dort dann Eigenschaften und Sicherheit und dort den Benutzer "NT Service\NoSpamProxyGatewayRole" Hinzufügen Lesen setzen,

Inzwischen habe ich auch die Stelle in Handbuch gefunden: Link. Das zur Vollständigkeit für die Nachwelt.

 

[ffischer]

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:

Möglicherweise liegt es aber, wie du auch schon vermutest hast, am WIndows Server selbst.

 

[JanJäschke]

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

 

[869288141]

Das würde ich noch etwas beobachten

Würde ich nicht lange fackeln... Kiste neu aufsetzen. Selten erlebt, dass sich Probleme unter Windows mit Updates beheben.