Seltsames OpenSSL ts-Verifizierungsproblem

Question 1

Um eine vollständige Zertifikatskette für die Überprüfung durch OpenSSL aufzubauen, benötigen Sie nicht nur das Stammzertifikat (das Sie mithilfe des -CAfileSchalters angegeben haben), sondern auch das Zertifikat, das zum Signieren der TSResponse verwendet wurde.

Aus der Manpage von ts:

-untrusted cert_file.pem
           Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This
           file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them.  (Optional)

Answer

Um eine vollständige Zertifikatskette für die Überprüfung durch OpenSSL aufzubauen, benötigen Sie nicht nur das Stammzertifikat (das Sie mithilfe des -CAfileSchalters angegeben haben), sondern auch das Zertifikat, das zum Signieren der TSResponse verwendet wurde.

Aus der Manpage von ts:

-untrusted cert_file.pem
           Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This
           file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them.  (Optional)

Question 2

Ein Prüffehler „Lokales Ausstellerzertifikat konnte nicht abgerufen werden“ bedeutet, dass OpenSSL im lokalen Truststore entweder die Wurzel (oder den Anker) einer vollständigen Kette oder das nächste Glied einer unvollständigen Kette, das die Wurzel/der Anker sein kann oder nicht, nicht finden konnte.

Als Hintergrund: Da Sie nicht angeben, wie gut Sie sich mit zertifikatsbasierter Überprüfung auskennen, ts -verifybesteht sie im Wesentlichen aus vier Teilen:

Überprüfen Sie, ob die Signatur im Token-Text mithilfe des öffentlichen Schlüssels im (beanspruchten) Zertifikat des Unterzeichners verifiziert wurde und ob einige weitere durch RFC3161 auferlegte Einschränkungen eingehalten werden (es darf nur eine SignerInfo vorhanden sein und diese muss signedAttrs einschließlich ESSCertId verwenden). Ob das Zertifikat des Unterzeichners in der Zeitstempelantwort enthalten ist, wird durch ein Flag in der RFC3161-Anforderung gesteuert. Wenn es nicht enthalten ist, muss der Prüfer/Vertrauende bereits darüber verfügen oder es auf andere Weise erhalten.
Erstellen Sie eine Kette (auch Pfad genannt), die das beanspruchte Zertifikat des Unterzeichners mit mindestens einer vertrauenswürdigen Zertifizierungsstelle verknüpft, die durch ein Zertifizierungsstellenzertifikat dargestellt wird, das als Stamm- oder Ankerzertifikat bezeichnet wird und lokal als vertrauenswürdig definiert ist, normalerweise indem es in einem Truststore vorhanden ist. Die RFC3161-AntwortMaidie Kettenzertifikate enthalten, dies ist jedoch nicht erforderlich. Andernfalls muss der Prüfer/Vertrauensperson bereits über diese verfügen oder sie auf andere Weise erhalten.
Validieren Sie die Kette, indem Sie prüfen, ob die Signatur jedes Zertifikats mit dem öffentlichen Schlüssel des nächsthöheren Zertifikats (also des übergeordneten Zertifikats) übereinstimmt, ob jedes Zertifikat zum Zeitpunkt der Signatur gültig (in Kraft und nicht abgelaufen) ist und ob eine Reihe anderer Felder in jedem Zertifikat für die Verwendung in der Kette geeignet sind. Einzelheiten finden Sie inRFC5280 Abschnitt 6. ValidierungsollenDazu gehört die Überprüfung, dass die einzelnen Zertifikate in der Kette nicht widerrufen sind (zum Zeitpunkt der Signatur). OpenSSL führt diesen Teil jedoch nicht standardmäßig aus. Es gibt mehrere Optionen für verschiedene Varianten der Widerrufsprüfung, Sie haben jedoch keine davon verwendet.
Überprüfen Sie abschließend, ob das Zertifikat (die Zertifikatskette) für den hier genannten Zweck geeignet ist, nämlich für die Zeitstempelung. Bei anderen Fällen der Zertifikatverwendung wie SSL/TLS und S/MIME müssen wir normalerweise nicht nur überprüfen, ob das Zertifikat rechtmäßig unter der Autorität einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, sondern auch, ob es ausgestellt wurdeZueine bestimmte Entität (eine Website, ein Mailserver oder eine Person, die zuverlässig identifiziert wurde). Für die Zeitstempelung ist uns das jedoch normalerweise egalwelcheTSA hat das Token nur ausgegeben,manchegültige TSA hat dies getan, daher überprüft diese letzte Prüfung nur, ob die ExtendedKeyUsage des Zertifikats/der Kette Zeitstempel enthält (die standardisierte OID dafür und somit zulässt).

Zusammen (und nur zusammen) stellen sie sicher, dass es sich bei den Daten, die wir haben, tatsächlich um einen von einer gültigen TSA ausgestellten Zeitstempel-Token handelt und dass diese weder absichtlich noch unabsichtlich gefälscht oder verändert wurden und daher vertrauenswürdig sind.

Für die OpenSSL-Befehlszeile muss sich der Root/Anker im verwendeten Truststore befinden, der entweder aus der angegebenen -CAfileund/oder -CApathder Standard-CA-Datei und/oder dem CA-Pfad besteht, sofern diese vorhanden sind, in beiden Fällen im PEM-Format; und (obwohl die Manpage nicht sehr klar ist) alle anderen Kettenzertifikate, die nicht in der Antwortnachricht enthalten sind, müssenentwederim Truststore oder in der bereitgestellten Datei sein -untrusted(dies muss eine einzelne Datei sein, kann aber mehrere Zertifikate im PEM-Format enthalten). Standardmäßig wird nur ein Root-Zertifikat (und historisch wurde nur ein Root-Zertifikat) als Ketten-/Pfadanker akzeptiert, aber mit der -partial_chainOption seit 1.0.2 wird ein Nicht-Root-Anker im Truststore akzeptiert.

Die ts -reply -textAnzeige zeigt nicht die CMS-Ebene und insbesondere, welche Zertifikate darin enthalten sind. Sie können alles sehen, asn1parse -inform der [-i]müssen es aber manuell dekodieren. Bequemer können Sie den CMS SignedData-Teil, auch bekannt als signiertes Token, wie folgt extrahieren:meine Antwort hierund prüfen Sie dann die Zertifikate wie folgt:

 openssl ts -reply -in respfile -token_out -out tokenfile
 openssl pkcs7 -inform der -in tokenfile -print_certs 
 # if desired/necessary, feed any or each of the PEM cert block(s) 
 # to openssl x509 -text -noout to get full details

Ich habe keine Erfahrung mit diesem TSA, aber nach dem Prinzip, dass das Zertifikat und die Kette eines bekannten öffentlichen TSA öffentlich protokolliert werden sollten, ist das einzige protokollierte Zertifikat mit diesem Betreff, das crt.sh bekannt ist (das ebenfalls von Comodo-now-Sectigo betrieben wird),https://crt.sh/?id=1437463789welches einen bekannten Elternteil hatSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092dessen Aussteller ist USERTrust RSA Certification Authority; diese Zertifizierungsstelle hat vier Zertifikate (potenzielle Eltern) aufgelistet unterhttps://crt.sh/?caid=1167-- einer davon ist Microsoft Codesigning, das normalerweise nur verwendet wird, wenn der Zeitstempel für eine Microsoft Authenticode-Codesignatur bestimmt ist, und die drei anderen sind alle für die allgemeine Verwendung geeignet, obwohl der einzige mit dem Namen Comodo recht neu ist (erst vor 3 Monaten herausgegeben). Übrigens verweist die AIA in id=1437089092 aufhttp://crt.usertrust.com/USERTrustRSAAddTrustCA.crtwelches das Zertifikat vom AddTrust-Stamm bereitstellthttps://crt.sh/?id=4860286welches das älteste ist (ausgestellt im Jahr 2000 und läuft innerhalb eines Jahres ab).

Verwenden Sie die Zertifikate in der Nachricht, um zu bestimmen, welche zusätzlichen Ketten- und Ankerzertifikate für die gewünschte Wurzel oder den gewünschten Anker erforderlich sind, und vergleichen Sie diese mit dem, was in Ihrer -CAfileoder einer anderen Datei bereitgestellt wird, die Sie möglicherweise verwenden -untrusted.

Answer

Ein Prüffehler „Lokales Ausstellerzertifikat konnte nicht abgerufen werden“ bedeutet, dass OpenSSL im lokalen Truststore entweder die Wurzel (oder den Anker) einer vollständigen Kette oder das nächste Glied einer unvollständigen Kette, das die Wurzel/der Anker sein kann oder nicht, nicht finden konnte.

Als Hintergrund: Da Sie nicht angeben, wie gut Sie sich mit zertifikatsbasierter Überprüfung auskennen, ts -verifybesteht sie im Wesentlichen aus vier Teilen:

Überprüfen Sie, ob die Signatur im Token-Text mithilfe des öffentlichen Schlüssels im (beanspruchten) Zertifikat des Unterzeichners verifiziert wurde und ob einige weitere durch RFC3161 auferlegte Einschränkungen eingehalten werden (es darf nur eine SignerInfo vorhanden sein und diese muss signedAttrs einschließlich ESSCertId verwenden). Ob das Zertifikat des Unterzeichners in der Zeitstempelantwort enthalten ist, wird durch ein Flag in der RFC3161-Anforderung gesteuert. Wenn es nicht enthalten ist, muss der Prüfer/Vertrauende bereits darüber verfügen oder es auf andere Weise erhalten.
Erstellen Sie eine Kette (auch Pfad genannt), die das beanspruchte Zertifikat des Unterzeichners mit mindestens einer vertrauenswürdigen Zertifizierungsstelle verknüpft, die durch ein Zertifizierungsstellenzertifikat dargestellt wird, das als Stamm- oder Ankerzertifikat bezeichnet wird und lokal als vertrauenswürdig definiert ist, normalerweise indem es in einem Truststore vorhanden ist. Die RFC3161-AntwortMaidie Kettenzertifikate enthalten, dies ist jedoch nicht erforderlich. Andernfalls muss der Prüfer/Vertrauensperson bereits über diese verfügen oder sie auf andere Weise erhalten.
Validieren Sie die Kette, indem Sie prüfen, ob die Signatur jedes Zertifikats mit dem öffentlichen Schlüssel des nächsthöheren Zertifikats (also des übergeordneten Zertifikats) übereinstimmt, ob jedes Zertifikat zum Zeitpunkt der Signatur gültig (in Kraft und nicht abgelaufen) ist und ob eine Reihe anderer Felder in jedem Zertifikat für die Verwendung in der Kette geeignet sind. Einzelheiten finden Sie inRFC5280 Abschnitt 6. ValidierungsollenDazu gehört die Überprüfung, dass die einzelnen Zertifikate in der Kette nicht widerrufen sind (zum Zeitpunkt der Signatur). OpenSSL führt diesen Teil jedoch nicht standardmäßig aus. Es gibt mehrere Optionen für verschiedene Varianten der Widerrufsprüfung, Sie haben jedoch keine davon verwendet.
Überprüfen Sie abschließend, ob das Zertifikat (die Zertifikatskette) für den hier genannten Zweck geeignet ist, nämlich für die Zeitstempelung. Bei anderen Fällen der Zertifikatverwendung wie SSL/TLS und S/MIME müssen wir normalerweise nicht nur überprüfen, ob das Zertifikat rechtmäßig unter der Autorität einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, sondern auch, ob es ausgestellt wurdeZueine bestimmte Entität (eine Website, ein Mailserver oder eine Person, die zuverlässig identifiziert wurde). Für die Zeitstempelung ist uns das jedoch normalerweise egalwelcheTSA hat das Token nur ausgegeben,manchegültige TSA hat dies getan, daher überprüft diese letzte Prüfung nur, ob die ExtendedKeyUsage des Zertifikats/der Kette Zeitstempel enthält (die standardisierte OID dafür und somit zulässt).

Zusammen (und nur zusammen) stellen sie sicher, dass es sich bei den Daten, die wir haben, tatsächlich um einen von einer gültigen TSA ausgestellten Zeitstempel-Token handelt und dass diese weder absichtlich noch unabsichtlich gefälscht oder verändert wurden und daher vertrauenswürdig sind.

Für die OpenSSL-Befehlszeile muss sich der Root/Anker im verwendeten Truststore befinden, der entweder aus der angegebenen -CAfileund/oder -CApathder Standard-CA-Datei und/oder dem CA-Pfad besteht, sofern diese vorhanden sind, in beiden Fällen im PEM-Format; und (obwohl die Manpage nicht sehr klar ist) alle anderen Kettenzertifikate, die nicht in der Antwortnachricht enthalten sind, müssenentwederim Truststore oder in der bereitgestellten Datei sein -untrusted(dies muss eine einzelne Datei sein, kann aber mehrere Zertifikate im PEM-Format enthalten). Standardmäßig wird nur ein Root-Zertifikat (und historisch wurde nur ein Root-Zertifikat) als Ketten-/Pfadanker akzeptiert, aber mit der -partial_chainOption seit 1.0.2 wird ein Nicht-Root-Anker im Truststore akzeptiert.

Die ts -reply -textAnzeige zeigt nicht die CMS-Ebene und insbesondere, welche Zertifikate darin enthalten sind. Sie können alles sehen, asn1parse -inform der [-i]müssen es aber manuell dekodieren. Bequemer können Sie den CMS SignedData-Teil, auch bekannt als signiertes Token, wie folgt extrahieren:meine Antwort hierund prüfen Sie dann die Zertifikate wie folgt:

 openssl ts -reply -in respfile -token_out -out tokenfile
 openssl pkcs7 -inform der -in tokenfile -print_certs 
 # if desired/necessary, feed any or each of the PEM cert block(s) 
 # to openssl x509 -text -noout to get full details

Ich habe keine Erfahrung mit diesem TSA, aber nach dem Prinzip, dass das Zertifikat und die Kette eines bekannten öffentlichen TSA öffentlich protokolliert werden sollten, ist das einzige protokollierte Zertifikat mit diesem Betreff, das crt.sh bekannt ist (das ebenfalls von Comodo-now-Sectigo betrieben wird),https://crt.sh/?id=1437463789welches einen bekannten Elternteil hatSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092dessen Aussteller ist USERTrust RSA Certification Authority; diese Zertifizierungsstelle hat vier Zertifikate (potenzielle Eltern) aufgelistet unterhttps://crt.sh/?caid=1167-- einer davon ist Microsoft Codesigning, das normalerweise nur verwendet wird, wenn der Zeitstempel für eine Microsoft Authenticode-Codesignatur bestimmt ist, und die drei anderen sind alle für die allgemeine Verwendung geeignet, obwohl der einzige mit dem Namen Comodo recht neu ist (erst vor 3 Monaten herausgegeben). Übrigens verweist die AIA in id=1437089092 aufhttp://crt.usertrust.com/USERTrustRSAAddTrustCA.crtwelches das Zertifikat vom AddTrust-Stamm bereitstellthttps://crt.sh/?id=4860286welches das älteste ist (ausgestellt im Jahr 2000 und läuft innerhalb eines Jahres ab).

Verwenden Sie die Zertifikate in der Nachricht, um zu bestimmen, welche zusätzlichen Ketten- und Ankerzertifikate für die gewünschte Wurzel oder den gewünschten Anker erforderlich sind, und vergleichen Sie diese mit dem, was in Ihrer -CAfileoder einer anderen Datei bereitgestellt wird, die Sie möglicherweise verwenden -untrusted.

Seltsames OpenSSL ts-Verifizierungsproblem

Antwort1

Antwort2

verwandte Informationen