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/Troublesh...rtificates
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)





[Bild: https://forum.nospamproxy.com/attachment.php?aid=203]






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

Code:

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.





[Bild: https://forum.nospamproxy.com/attachment.php?aid=204]





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