DataError: Data provided to an operation does not meet requirements

Prüfe auf den DOMException-Namen DataError; der Meldungstext variiert je nach Laufzeitumgebung. Firefox und Safari zeigen den generischen Satz oben; Chrome lässt die Meldung oft leer oder nennt den Grund („The imported EC key specifies a different curve than requested“); Node gibt „Invalid keyData“ oder einen konkreten Grund wie „Named curve mismatch“ aus.

WebCrypto crypto.subtle.importKey — browsers & Node

Was der Fehler bedeutet

importKey (oder unwrapKey) hat die Schlüsselbytes abgelehnt: Die Bytes lassen sich nicht im angegebenen Format parsen, oder ihr Inhalt widerspricht den Algorithmusparametern (falsche Kurve, nicht zusammenpassende JWK-Felder). Es ist das WebCrypto-Gegenstück zu „diese Bytes sind nicht der Schlüssel, für den du sie ausgibst“ – ausgelöst, bevor überhaupt ein Schlüsselobjekt erzeugt wird.

Warum der Fehler auftritt

• Formatname passt nicht zu den Bytes

  häufig

  Einen öffentlichen Schlüssel mit dem Format „pkcs8“ (Container für private Schlüssel) oder einen privaten Schlüssel mit „spki“ zu importieren, ist die klassische Verwechslung. Die Namen sind wenig intuitiv: spki = öffentlich, pkcs8 = privat, raw = nackter EC-Punkt, jwk = JSON-Objekt.

• PEM-Text wurde nicht in Binärdaten umgewandelt

  häufig

  importKey erwartet einen ArrayBuffer mit DER, keinen PEM-Text. Übergibst du den PEM-String als UTF-8 kodiert – oder dekodierst du ihn mit base64, ohne vorher die BEGIN/END-Zeilen und Zeilenumbrüche zu entfernen –, entstehen Bytes, an denen das Parsen der Struktur scheitert.

• Abweichende Kurve zwischen Schlüssel und Algorithmus

  gelegentlich

  Ein P-256-SPKI, importiert mit namedCurve: "P-384" (Node meldet „Named curve mismatch“), oder ein JWK, dessen crv nicht zum angeforderten Algorithmus passt. Die Bytes sind in Ordnung; die Deklaration ist falsch. Firefox prüft den SPKI-Fall beim Import nicht, daher kann derselbe Code dort durchlaufen und in Chrome, Safari und Node scheitern.

• Ungültiger roher Punkt

  gelegentlich

  Beim Format „raw“ müssen die 65 Byte 0x04 ‖ X ‖ Y lauten, wobei (X, Y) tatsächlich auf der Kurve liegt; Chrome, Firefox und Node lehnen einen beschädigten Punkt beim Import ab, während die Engine von Safari ihn in unserem Test anstandslos importiert hat. Komprimierte Punkte (33 Byte mit dem Präfix 0x02/0x03) sind eine Portabilitätsfalle in umgekehrter Richtung: Chrome, Firefox und Node akzeptieren sie, Safari lehnt sie mit diesem Fehler ab.

So behebst du den Fehler

1. 1.

   PEM → ArrayBuffer korrekt konvertieren

   Entferne die Rahmenzeilen, dekodiere den Inhalt mit base64 und wähle das Format anhand des PEM-Labels: PUBLIC KEY → spki, PRIVATE KEY → pkcs8.

   function pemToArrayBuffer(pem) {
     const b64 = pem.replace(/-----[^-]+-----/g, "").replace(/\s+/g, "");
     return Uint8Array.from(atob(b64), (c) => c.charCodeAt(0)).buffer;
   }
   
   const key = await crypto.subtle.importKey(
     "spki", pemToArrayBuffer(publicKeyPem),
     { name: "ECDSA", namedCurve: "P-256" },
     false, ["verify"],
   );

2. 2.

   JWK bevorzugen, wenn du Schlüsselmaterial als JSON hast

   JWKS-Endpunkte liefern bereits Objekte, die WebCrypto direkt verarbeiten kann – keine Binärkonvertierung, und crv reist mit dem Schlüssel mit.

   const key = await crypto.subtle.importKey(
     "jwk", jwk,
     { name: "ECDSA", namedCurve: jwk.crv },
     false, ["verify"],
   );

3. 3.

   Prüfen, was die Bytes wirklich sind

   Füge den Schlüssel unten in den Zertifikats-Decoder oder in den Signatur-Verifier ein – beide parsen SPKI/PKCS#8/JWK lokal und melden die tatsächliche Kurve und den Schlüsseltyp, was die Abweichung meist sofort benennt.

← Gesamte Signaturfehler-Datenbank durchsuchen