Fehlermeldung
Verification failure
Formulierung von OpenSSL 3.x. OpenSSL 1.1.x schreibt die Meldung mit großen Anfangsbuchstaben: „Verification Failure“. openssl pkeyutl -verify gibt die verwandte Meldung „Signature Verification Failure“ aus. Unter OpenSSL 3.x erscheint bei beiden zusätzlich eine Zeile aus dem Fehler-Stack wie „error:030000EA:digital envelope routines:EVP_DigestVerifyFinal:provider signature failure“ (reproduziert mit 3.6). Eine Signatur, die gar kein DER ist, kommt nie so weit, sondern scheitert mit „Error verifying data“.
Was der Fehler bedeutet
openssl dgst -verify hat den Digest deiner Daten berechnet, die Signatur mit dem öffentlichen Schlüssel geprüft, und die Mathematik hat Nein gesagt. Schlüssel, Daten und Signatur waren alle lesbar – eines der drei passt nicht zu den anderen. Zum Vergleich: Bei Erfolg lautet die Ausgabe „Verified OK“.
Warum der Fehler auftritt
Die Daten weichen von den signierten Daten ab
häufigEin Zeilenumbruch am Ende, den ein Editor angefügt hat, eine Umwandlung zwischen CRLF und LF durch git oder ein bereits gehashter Digest, der noch einmal gehasht wird (dgst hasht seine Eingabe – wer ihm einen SHA-256-Digest übergibt, signiert den Hash des Hashes).
Abweichender Digest-Algorithmus
häufigMit -sha256 signiert, aber mit -sha384 geprüft (oder die Bibliothek des Signierers hat standardmäßig einen anderen Hash verwendet). Der Digest ist Teil der signierten Aussage; beide Seiten müssen denselben verwenden.
Falscher öffentlicher Schlüssel
gelegentlichEin rotierter Schlüssel, der Schlüssel eines anderen Dienstes oder ein öffentlicher Schlüssel, der aus einem anderen privaten Schlüssel abgeleitet wurde als aus dem, mit dem signiert wurde.
So behebst du den Fehler
- 1.
Zuerst die Kodierung der Signatur als Ursache ausschließen
dgst -verify liest ECDSA-Signaturen nur als ASN.1 DER. Eine rohe r‖s-Signatur aus WebCrypto, JWS oder einer Go- oder Python-API im Raw-Modus – genau 64 Byte bei P-256, 96 bei P-384 – scheitert schon früher mit „Error verifying data“. Ist deine Signatur DER und scheitert trotzdem hier, sind die Daten, der Digest oder der Schlüssel falsch. Das Tool DER ⇄ Raw unten wandelt zwischen beiden Formen um und markiert nicht kanonische High-S-Werte, die strenge Verifizierer ablehnen.
- 2.
Vorab berechneten Digest mit pkeyutl prüfen
Hast du den Digest statt der Nachricht, ist dgst das falsche Tool (es würde erneut hashen). pkeyutl prüft gegen den rohen Digest.
bash openssl dgst -sha256 -binary message.bin > msg.hash openssl pkeyutl -verify -pubin -inkey pub.pem \ -sigfile sig.der -in msg.hash -pkeyopt digest:sha256 - 3.
Abweichungen in den Daten ausschließen
Vergleiche auf beiden Seiten die Digests genau der Bytes, die tatsächlich verwendet werden; jeder Unterschied bedeutet, dass sich die Nachricht geändert hat – an der Kryptografie liegt es nicht.
bash openssl dgst -sha256 message.bin # run on signer and verifier sides xxd message.bin | tail -2 # check for a sneaky trailing 0a