• Bewerte uns auf OMR Reviews: Klick

  • 25Reports geht live, schaut es euch an: Klick

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

  • Zertifikate vom Deutschen Forschungsnetz beziehen (Harica CA)? Klick

SwissSign bestimmte Zertifikate widerrufen und erneuern

Das hat leider nicht geholfen, NSP sendet signiert mit dem älteren Zertifikat
 
Zusammenfassend, die bisherigen Erkenntnisse meiner Tests:

- Script funktioniert grundsätzlich und erleichtert die Arbeit deutlich (y)
- Wenn man mehrere Zertifikate gleichzeitig anfragt, ist die Wahrscheinlichkeit gefühlt höher, dass welche auf "Ausstehend" hängen bleiben (in der Schlüsselanforderungs GUI), obwohl diese erfolgreich ausgestellt und gebunden wurden.
- Unter dem Punkt "Zertifikate" oder via PS fehlen diese "noch" und tauchen erst ca. 2 Stunden später dort auf.
- Die mit "Ausstehend" gehen irgendwann in "Fehler / Zeit überschritten" (oder so ähnlich) über - aber wie gesagt, die haben trotzdem funktioniert!
- Die SwissSign Sperrungen im NSP sehe ich (noch) nicht (im SwissSign Portal schon), auch nicht nach Neustart GW Rollen
- Es sind bei mir (anders als im Post zuvor) die neuen Zertifikate gemappt und werden laut Protokoll auch verwendet zum signieren.

Vielleicht könnte man das Thema "Ausstehend" durch einen kurzen Sleep zwischen den einzelnen Requests in den Griff bekommen.
Oder vielleicht (könnte ich auch selber testen) im letzten Step des Scriptes eine Schleife mit nur je einer Anfrage der Liste + 1s Sleep etc. in den Prozess "einkippen".
 
Ich schaue mir das mal näher an, sobald die Revocation bei allen angekommen ist, löst sich das Thema durch den userimport aber auch wieder von alleine -> dieser fragt dann korrekt neue an.

Ihr könntet einmal folgendes in der CMD auf den GWs probieren:
certutil -setreg chain\ChainCacheResyncFiletime @now

Damit wird der Cache sauber invalidiert, ein GW dienst Neustart ist dann noch zu empfehlen.
 
Moin,

ich bin über diesen Beitrag gestolpert, da ich selbst erst heute auf das Problem gestoßen bin. Die Nachricht von SwissSign habe ich bekommen. Bin aber irrtümlicherweise davon ausgegangen, NSP macht das schon... Nun gut.
Das Skript habe ich mir geholt. An sich scheint das ja damit zu gehen, allerdings komme ich dann auch bei zu vielen Anfragen ans Timeout. Bei SwissSign sehe ich auch nur einen Teil der Anfragen angekommen.
Bei ca. 1300 zu erneuernden Zertifikaten wäre das Skript schon recht hilfreich. Ich sitze jetzt hier und spiele mit den Zeitstempel, damit die "Pakete" mit zu erneuernden Zertifikaten nicht zu groß wird und schicke den Befehl dann ab. Aber ist das gerade die Lösung? Oder stelle ich mich zu ...doof an?
Weiter scheint auch die Revozierung bei mi nicht anzukommen. Die Zertifikate sind weiterhin gültig. Auch nach der Neuanfrage.

Gruß.
 
Ich schaue mir das mal näher an, sobald die Revocation bei allen angekommen ist, löst sich das Thema durch den userimport aber auch wieder von alleine -> dieser fragt dann korrekt neue an.

Ihr könntet einmal folgendes in der CMD auf den GWs probieren:
certutil -setreg chain\ChainCacheResyncFiletime @now

Damit wird der Cache sauber invalidiert, ein GW dienst Neustart ist dann noch zu empfehlen.
Habt ihr das hier schon ausprobiert?

Das der NSP das mittlerweile macht ist keine falsche Annahme, sie ist richtig ^^
Die Frage ist eher warum das bei dir noch nicht als revoziert angesehen wird....
 
Achso. Also würde der NSP sich die Zertifikate jetzt doch selber neu holen, wenn er es denn mitbekommen würde? :-D

Stark. Da echt die Frage, warum NSP das nicht checkt. Die Kommunikation schient ja zu klappen, kleinere Aufträge für neue Zertifikate oder einzelne Anfragen gehen erfolgreich durch...

Den Befehl habe ich jetzt nochmal in der CMD statt PS ausgeführt und ging dann auch durch. ;-) Sollten dann größere Anfragen auch durchgehen?
 
Jap, NSP würde wenn er weiß, dass es kein gültiges Zertifikat mehr gibt beim Benutzerimport ein neues beantragen :)
Der certutil ist lediglich zum cache löschen da, wenn du dann den Gateway Rollen Dienst neu startest könntest du einmal prüfen ob das Zertifikat nun als Revoziert angesehen wird.
Ggf. machst du das gleiche auch mal auf der Intranet Rolle, dann ist das identisch :)
Das hat also nichts mit der Batch Size zu tun, warum das Failed bei manchen (mal mehr mal weniger) kann ich derzeit nicht sagen.
Das werden wir uns noch anschauen.
 
Hmm, okay. Nicht gut.
Auf beiden Seiten gemacht, aber Zertifikate werden weitehrin nicht als revoziert erkannt. Ich werde dazu ein Ticket beim Support auf machen.
Und erstmal weiter manuell die Zertifikate anfragen. Was muss, dass muss...
:)

Edit: Witzig auch: Wenn ich das Zertifikat manuell sperren möchte über NSP, schlägt dies fehl mit der Meldung "already revocked". Top.
🤟
 
Wenn du den öffentlichen Teil des Zertifikats manuell öffnest/wo anders prüfst, ist es denn dann Revoziert? ^^
 
Sehe ich das richtig, das hier nur die Silver Zertifikate betroffen sind und nicht die Gold-Zertifikate?
 
Hmm, okay. Nicht gut.
Auf beiden Seiten gemacht, aber Zertifikate werden weitehrin nicht als revoziert erkannt. Ich werde dazu ein Ticket beim Support auf machen.
Und erstmal weiter manuell die Zertifikate anfragen. Was muss, dass muss...
:)

Edit: Witzig auch: Wenn ich das Zertifikat manuell sperren möchte über NSP, schlägt dies fehl mit der Meldung "already revocked". Top.
🤟
Es kommt immer darauf an, wie geprüft wird: CRL vs. OCSP. Im Standard ist es unter Windows so, dass OCSP den Vorrang gegenüber einer CRL hat, weil es vor allem viel schneller ist. Die CRL wird erst kurz vor Ende ihrer Laufzeit neu heruntergeladen. Je nach Konfig kann das ein paar Tage dauern.
 
Frage: gibt es inzwischen einen Lösungsweg für die revozierten Zertifikate?
Diese werden bei uns im NSP, als auch in Windows selbst immernoch als valide angezeigt.

Der Befehl "certutil -setreg chain\ChainCacheResyncFiletime @now" hatte leider nichts gebracht.

Wenn ich es richtig sehe, sendet auch das Gateway des NSP Support weiterhin mit den revozierten Zertifikaten:
1777363959824.png

In SwissSign sind die Zertis als revoziert markiert.

1777363783984.png
 
Zurück
Oben