Widerrufenenes Zertifikat nicht ungültig

[lukas]

Servus zusammen,

ich habe gerade folgendes Szenario:
- Kunde hat ein SMIME Zertifikat von TeleSec, gültig bis 2023, dieses wurde im Dezember revoked
- Kunde hat ein neues Zertifiklat, gültig bis 2024
Beide Zertifikate werden mir im NSP und im Windows als gültig angezeigt.

Prüfe ich die Zertifikate per certutil oder Webdienst https://certificate.revocationcheck.com wird mir aber beim ersten korrekt angezeigt, dass es gesperrt/widerrufenen wurde.

Nun wird mir aber bei jeder Mail an den Kunden folgende Meldung ins Eventlog geschrieben:
- SERIALNUMBER=2, E=name@domain.de, usw usw, C=DE (Thumbprint 12345xxxxx, valid from 11.03.2020 15:02:08 to 12.03.2023 00:59:59): Revoked

Anschließend wird zum Verschlüsseln aber das korrekte, gültige Zertifikat verwendet.

Dazu nun 2 fragen:
1) Warum wird das erste Zertifikat von Winodws bzw. vom NSP nicht für ungültig erklärt (basierend auf der CRL)?
2) Wie geht man da im NPS als best practice vor? Das alte Zertifikat selbst entfernen?

Ich kann mir vorstellen, dass sonst das Log ordentlich zugemüllt wrd, wenn sich SMIME in 10-100 Jahren doch mal durchsetzen sollte und deutlich mehr (revoked) Zertifikate umherschwirren.

Beste Grüße

 

[JanJäschke]

Hallo LRO,

das ist defenitiv nicht das zu erwartende Verhalten.
Um dein Problem vorerst einfach zu lösen kannst du das alte Zertifikat entfernen, dann wird das auch unter keinen Umständen mehr versucht für die Verschlüsselung zu nutzen.

Ich würde den Hauptgrund des Problems darin vermuten, dass der NSP als Dienst Probleme mit der Abfrage der CRLs / OCSP hat.
Ist bei euch ein Netwzerk Proxy im Einsatz?

Schau dir einmal dieses Skript an: https://github.com/noSpamProxy/Troubleshooting/tree/master/Check-NspCertificates
Damit kannst du die Zertifikate von jeder Rolle separat testen lassen und bekommst eine detailierte Rückmeldung.

Gruß
Jan

 

[lukas]

Hallo Jan

nein, in dem Fall nutzen wir keinen Proxy o.ä. Die Prüfung wird ja vermutlich auf dem GW passieren, da dieses auch das Log schreibt... die Gateways sind in der DMZ und kommunizieren direkt mit dem Internet. Natürlich eingeschränkt aber ich nehme an, dass die Sperrlisten-Prüfung ein Standard-Dienst von Windows ist den man nicht explizit freigeben muss? HTTP(S) ist auf jeden Fall erlaubt. Ich vermute aktuell eher, dass das da schon im Windows irgendein Check nicht gemacht wird, muss man das erst aktivieren?


Ich habe dasselbe Verhalten auch auf meinem lokalen Win10-Client ohne VPN und ohne Windows-Firewall, d.h. ich kann einen Block per Unternehmens- oder lokaler Firewall definitiv ausschließen.



Interessanterweise habe ich dasselbe Verhalten auch bei einem Zertifikat von euch entdeckt, deswegen hole ich mal etwas aus und packe ein paar Screenshots dazu




Ich habe unter anderem die beiden Zertifikate:


4CD884916E4BB7D0C48DC46439AF85F56F532594 (Gültig)


7B307B1C6F0D263D9645485A0A375A49A51CADFA (Revoked)

Das PS-Script gibt diese Infos auch korrekt wieder (ausgeführt auf der NSP-Intranet-Rolle)

PS C:\NSP-Git\Check-NspCertificates> .\Check-NspCertificates.ps1 4CD884916E4BB7D0C48DC46439AF85F56F532594
NSP-GW01 : NoSpamProxy Support   NoError
NSP-GW01 : SwissSign Personal Gold CA 2014 - G22   NoError
NSP-GW01 : SwissSign Gold CA - G2   NoError

NSP-GW02 : NoSpamProxy Support   NoError
NSP-GW02 : SwissSign Personal Gold CA 2014 - G22   NoError
NSP-GW02 : SwissSign Gold CA - G2   NoError


PS C:\NSP-Git\Check-NspCertificates> .\Check-NspCertificates.ps1 7B307B1C6F0D263D9645485A0A375A49A51CADFA
NSP-GW01 : Support NoSpamProxy   Revoked
NSP-GW01 : SwissSign Personal Gold CA 2014 - G22   NoError
NSP-GW01 : SwissSign Gold CA - G2   NoError

NSP-GW02 : Support NoSpamProxy   Revoked
NSP-GW02 : SwissSign Personal Gold CA 2014 - G22   NoError
NSP-GW02 : SwissSign Gold CA - G2   NoError

Ein Check auf der Gateway-Rolle zeigt wiederrum ein widersprüchliches Verhalten. Per GUI ist das Zertifikat gültig, per certutil nicht.

Daher ganz blöd gefragt: Muss man Windows erst sagen, dass er die CRLs prüfen muss/soll/darf damit auch der NSP das tut?

Gruß
Lukas

 

[JanJäschke]

Hallo Lukas,

ich habe mal noch etwas nachgeforscht und auch gleich etwas verbesserungswürdiges gefunden ^^
"Die MMC zeigt aktuell nur die zeitliche Gültigkeit an. Eine vollständige Validierung der Kette (inkl. CRL) geht eigentlich nur auf den Gateways, da dafür unbeschränkter Internetzugriff erforderlich ist."

Somit ist die Lösung:
Ignorieren da der Eventeintrag nicht von nachteil ist oder das Zertifikat löschen wenn es doch stört. (Das solltet ihr nicht bei eigenen machen.)

Ich werde das Thema mit in die Planung aufnehmen, damit wir in Zukunft wenn möglich dann auch den Sperrstatus berücksichtigen


Gruß
Jan

 

[BRZ]

Ich werde das Thema mit in die Planung aufnehmen, damit wir in Zukunft wenn möglich dann auch den Sperrstatus berücksichtigen

Moin Jan,

wird dieser Punkt noch umgesetzt oder ist er von der Agenda?

Viele Grüße
Martin

 

[JanJäschke]

Hallo Martin,

ja der Punkt ist noch auf unserer Agenda
Von der Priorität haben wir jedoch aktuell noch wichtigere Themen offen weshalb eine Umsetzung noch etwas Zeit in Anspruch nehmen wird.


Gruß
Jan

 

[wagnerv]

Hallo @JanJäschke ich wollte mal kurz dieses Thema aufgreifen.
wir sind auch sehr interessiert.

 

[JanJäschke]

Es gab ein paar kleine Anpassungen, das Grundsätzliche "Problem" besteht jedoch weiterhin. Hier müssen wir noch weitere Umbauten machen.
Auf Grund des alters gibt es leider viele Abhängigkeiten die wir vorab lösen müssen um nicht in andere Probleme zu laufen

 

[righter]

Hallo

Sehe ich, dass richtig, dass NSP revoked Zertifikate weiter nimmt für die Verschlüsselung der externen Empfänger?
Wir haben das Problem auch. Ich denke die Lösung müsste sein die Revoked Zertifikate der externen User zu löschen aus dem NSP oder?
Leider kann man im UI nicht nach Revoked sortieren. Geht das mit einem NSP-XX Befehl?

 

[JanJäschke]

Hallo,

nein das ist nicht ganz richtig.
Sobald wir die Zertifikate als Revoked einstufen werden diese auch nicht mehr zum verschlüsseln verwendet.
Da wir sie aber in diesem Fall nicht als Revoked einstufen bzw. dies erst später tun, findest du sie auch nicht über den NSP.
Hier würde akut nur ein manuelles raus suchen eines bestimmtes Zertifikates oder ein zusätzliches Skript helfen welches aktiv jedes Zertifikat gegenprüft.


ggf. führe ich an dieser Stelle noch einmal etwas aus warum es bei uns zu einer Verzögerten Einstufung kommt:
Wir nutzen die Windows Boardmittel um die Validierung der Zertifikate immer wieder durchzuführen. Dabei kommt es schon zu unterschieden am Gateway sowie ind er NCC. Die NCC fragt die Informationen deutlich seltener ab was performance bedingt ist wodurch hier Zertifikate meist länger noch als valide eingestuft werden. Das Gateway ist da hingegen etwas zügiger unterwegs.
In beiden Fällen spielt uns hier Windows jedoch leider böse mit da dort intern viel gecached wird. Der letzten Analyse nach kann dies eine minimale Verzögerung von 36h mit sich bringen.
Durch unsere Modernisierung arbeiten werden wir dieses Problem aus der Welt schaffen können da wir uns dann von den Windows Boardmitteln leichter trennen können und das Handling selbst übernehmen können.


LG
Jan

 

[righter]

Hmm ok mit den 36h haben wir immerhin eine Definition von "Verzögerung"

Komischerweise sind die 2 betroffen Zerts schon einige Monate abgelaufen:

Revocation Time: Aug 27 07:21:47 2024 GMT
+
Revocation Time: Jul 10 13:27:18 2024 GMT

Ich habe als Workaround das Zertifikat manuell gelöscht