x509: unsupported elliptic curve

Reproducido en Go 1.26. Los analizadores de claves privadas expresan la misma limitación con otras palabras: ParseECPrivateKey dice «x509: unknown elliptic curve», y ParsePKCS8PrivateKey, «x509: failed to parse EC private key embedded in PKCS#8: x509: unknown elliptic curve».

Go crypto/x509 — ParsePKIXPublicKey / ParseCertificate

Qué significa

La clave o el certificado se analiza bien estructuralmente, pero el OID de su curva no está entre los que admite la biblioteca estándar de Go: crypto/x509 solo maneja las curvas NIST P-224, P-256, P-384 y P-521. En la práctica, este error casi siempre apunta a una curva concreta, secp256k1, la curva de Bitcoin/Ethereum, que queda fuera de la biblioteca estándar a propósito: el equipo de Go incluye las curvas NIST con implementaciones de tiempo constante y deja todo lo demás a paquetes de terceros.

Por qué ocurre

• Material de clave secp256k1 en los analizadores de la biblioteca estándar

  frecuente

  Las claves generadas con openssl ecparam -name secp256k1 (o exportadas desde herramientas de blockchain) llevan el OID 1.3.132.0.10. El paquete x509 de Go reconoce el OID como una clave EC, pero no tiene implementación de esa curva y se detiene aquí.

• Brainpool, GOST u otras curvas nacionales

  ocasional

  Los certificados Brainpool europeos y otras curvas que no son de NIST aparecen en algunos ecosistemas gubernamentales y bancarios; la biblioteca estándar los trata exactamente igual que a secp256k1: envoltorio analizable, curva no admitida.

• Curvas pequeñas heredadas

  rara

  El material antiguo sobre curvas de la clase secp160/192 no está admitido y, además, hoy es criptográficamente insuficiente; la respuesta es la migración, no el análisis.

Cómo solucionarlo

1. 1.

   Analizar secp256k1 con una biblioteca específica

   Extrae tú mismo el punto en bruto (o sácalo de la estructura SEC1) y pásalo a una implementación de secp256k1 mantenida, como la de 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.

   O pasar la carga de trabajo a P-256

   Si nada en el sistema requiere secp256k1 (no hay interoperabilidad con blockchain), vuelve a generar las claves en una curva que admita la biblioteca estándar y toda la cadena de herramientas se simplifica.

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

3. 3.

   Confirmar qué curva usa realmente el material

   Antes de recurrir a una biblioteca, lee el OID de la curva en el archivo: 1.3.132.0.10 es secp256k1 y 1.2.840.10045.3.1.7 es P-256. Así también detectas archivos mal etiquetados cuya curva no es la que indican el nombre del archivo o la documentación.

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

← Explorar toda la base de datos de errores de firma