X509Chain.Build liefert falsche Zertifikatskette zurück

Michael Zdarsky 101 Zuverlässigkeitspunkte
2024-09-04T09:43:30.98+00:00

Hallo,

ich hatte zunächst ein Problem mit X509Chain.Build(...).

Die Methode liefert eine falsche Zertifikatskette zurück.

Mittlerweile habe ich gesehen, dass in der Darstellung des Zertifikatbaumes im Betriessystemdialog,
das gleich Verhalten ist.

Ich habe ein Zertifikat Zalt. Dieses war abgelaufen und ich habe ein neues Zertifikat Z2 erhalten.
Die Ketten der beiden Zertifikate sind wie folgt:

Root -> CodesigningZertifikatNeu -> ZNeu
und
Root -> CodesigningZertifikatAlt -> ZAlt

Betrachte ich mir die Zertifkatkette direkt auf der signierten Datei ist die Zertifkatskette korrekt.
Eportiere ich aber ZNeu in ein zneu.cer und betrache ich mir die Kette von diesem Cer file erhalte ich

Root -> CodesigningZertifikateAlt -> ZNeu.

Herausgefunden habe ich das im Certificate Store CodesigningZertifikatAlt installiert war.
Lösche ich diesen Eintrag bekomme ich korrekt

Root -> CodesigningZertifikatNeu -> ZNeu

Root ist von Global Sign
die beide code signing zertifikate auch

Die LeafZertifikate gehören dem Kunden.

Diese Verhalten darf nach meinem Verständnis nicht sein.
Wenn das Zwischenzertifikat im Certstore nicht in die Kette passt muss es einen Fehler geben.

Der X509Chain.Build(...) Methode verhält sich genauso.

Ist das Verhalten bekannt?

.NET
.NET
Microsoft-Technologien, die auf dem .NET-Softwareframework basieren.
29 Fragen
0 Kommentare Keine Kommentare
{count} Stimmen

1 Antwort

Sortieren nach: Am hilfreichsten
  1. Dimitar Denkov 1,665 Zuverlässigkeitspunkte
    2024-09-05T06:09:58.46+00:00

    Hallo Michael,

    Wenn CodesigningZertifikateAlt und CodesigningZertifikateNeu nicht in der gleichen Zwischenzertifizierungsstelle des lokalen Computers sind, sondern eines von ihnen z. B. in LocalComputer/My, dann muss die gesamte Zertifizierungsstelle durchsucht werden, wie in diesem Thread ausführlich erklärt wird:

    https://stackoverflow.com/questions/75637846/x509chain-build-seems-to-ignore-certificates-in-localcomputer-my

    Soweit ich verstanden habe, ist dies bei Dir nicht der Fall: beide sind in LocalComputer/Intermediate Certification Authorities. Dann könnte die Unterscheidung nach Antragstellerschlüssel-ID (Subject Key Identifier, SKID) zielführend sein, weil die gleiche SKID unter Umständen Schwierigkeiten bereiten kann, wie in diesen zwei Beispielen aus GitHub (wenngleich eins von ihnen OpenSSL betrifft):

    https://github.com/openssl/openssl/issues/18708

    https://github.com/dotnet/runtime/issues/59148

    Wenn Du über einen Bug berichten möchtest, wäre die Visual Studio Developer Community der richtige Ort. Wenn es soweit ist, verlinke den dortigen Thread auch hier, damit künftige Leser dieses Threads schneller den entsprechenden Problembericht verfolgen können.

    Gruß,

    Dimitar

    0 Kommentare Keine Kommentare

Ihre Antwort

Fragesteller*innen können Antworten als akzeptierte Antworten markiert werden, wodurch Benutzer*innen wissen, dass diese Antwort das Problem gelöst hat.