x509: unsupported elliptic curve

Reproduziert mit Go 1.26. Die Parser für private Schlüssel melden dieselbe Einschränkung mit anderen Worten: ParseECPrivateKey meldet „x509: unknown elliptic curve“, ParsePKCS8PrivateKey „x509: failed to parse EC private key embedded in PKCS#8: x509: unknown elliptic curve“.

Go crypto/x509 — ParsePKIXPublicKey / ParseCertificate

Was der Fehler bedeutet

Der Schlüssel oder das Zertifikat lässt sich strukturell parsen, aber die Kurven-OID gehört zu keiner Kurve, die die Standardbibliothek von Go unterstützt: crypto/x509 verarbeitet nur die NIST-Kurven P-224, P-256, P-384 und P-521. In der Praxis meint dieser Fehler fast immer eine bestimmte Kurve – secp256k1, die Kurve von Bitcoin und Ethereum, die bewusst nicht in der stdlib steckt: Das Go-Team liefert die NIST-Kurven mit zeitkonstanten Implementierungen aus und überlässt alles andere Paketen von Drittanbietern.

Warum der Fehler auftritt

• secp256k1-Schlüsselmaterial in Parsern der stdlib

  häufig

  Mit openssl ecparam -name secp256k1 erzeugte (oder aus Blockchain-Tools exportierte) Schlüssel tragen die OID 1.3.132.0.10. Das Paket x509 von Go erkennt die OID als EC-Schlüssel, hat aber keine Implementierung der Kurve dafür und bricht hier ab.

• Brainpool, GOST oder andere nationale Kurven

  gelegentlich

  Europäische Brainpool-Zertifikate und andere Nicht-NIST-Kurven kommen in einigen Behörden- und Bankenökosystemen vor; die stdlib behandelt sie genau wie secp256k1 – parsbare Hülle, nicht unterstützte Kurve.

• Veraltete kleine Kurven

  selten

  Altes Schlüsselmaterial auf Kurven der Klasse secp160/192 wird nicht unterstützt und ist heute auch kryptografisch unzureichend; die Lösung ist Migration, nicht Parsen.

So behebst du den Fehler

1. 1.

   secp256k1 mit einer spezialisierten Bibliothek parsen

   Extrahiere den rohen Punkt selbst (oder aus der SEC1-Struktur) und übergib ihn an eine gepflegte secp256k1-Implementierung, etwa die von dcrd.

   import (
       "github.com/decred/dcrd/dcrec/secp256k1/v4"
       "github.com/decred/dcrd/dcrec/secp256k1/v4/ecdsa"
   )
   
   pub, err := secp256k1.ParsePubKey(pointBytes)  // 33/65-byte SEC1 point
   ok := ecdsa.VerifySignature(...)               // via the package's ecdsa subpackage

2. 2.

   Oder die Anwendung auf P-256 umstellen

   Braucht im System nichts secp256k1 (keine Interoperabilität mit Blockchains), erzeuge die Schlüssel auf einer Kurve neu, die die stdlib unterstützt – dann wird die gesamte Toolchain einfacher.

   openssl ecparam -name prime256v1 -genkey -noout -out key.pem
   openssl pkey -in key.pem -pubout -out pub.pem

3. 3.

   Prüfen, welche Kurve das Material tatsächlich verwendet

   Bevor du zu einer Bibliothek greifst, lies die Kurven-OID aus der Datei aus: 1.3.132.0.10 ist secp256k1, 1.2.840.10045.3.1.7 ist P-256. So fallen auch falsch beschriftete Dateien auf, deren Kurve nicht die ist, die der Dateiname oder die Dokumentation angibt.

   openssl ec -in key.pem -noout -text | grep -A1 "ASN1 OID"
   openssl x509 -in cert.pem -noout -text | grep -iA2 "public key algorithm"

← Gesamte Signaturfehler-Datenbank durchsuchen