Digital signatures have become the backbone of secure document workflows, providing cryptographic proof of both document integrity and signer authenticity. But there’s a hidden complexity that catches many developers off guard: ECDSA signatures work fundamentally differently than RSA, even though both adhere to the same cryptography standards that govern modern encryption systems.

What looks like a simple algorithm swap can turn into hours of debugging cryptic validation errors. We’ve seen this pattern repeatedly with customers who successfully implement RSA signatures, only to hit unexpected roadblocks when transitioning to ECDSA’s superior performance and security.

The deceptive simplicity of ECDSA

The Elliptic Curve Digital Signature Algorithm(opens in a new tab) (ECDSA) promises compelling advantages: smaller key sizes, faster operations, and equivalent security to much larger RSA keys. On paper, switching from RSA to ECDSA should be straightforward — just change the algorithm parameters, right?

Not quite. In a recent customer support case, we saw a perfect example of why ECDSA implementation is more nuanced than it appears. The customer had a fully working RSA setup, but their ECDSA signatures consistently failed with validation errors that suggested document tampering.

The frustrating part? The signatures were cryptographically valid, but the format was wrong for PDF validators.

An overview of the ECDSA signature format

Here’s what most users tend to overlook: the fact that the Web Crypto API(opens in a new tab) and PDF digital signatures speak different languages.

When you sign data with ECDSA using Web Crypto, you get a raw 64-byte signature — two 32-byte integers (r and s) concatenated together. But PDF digital signatures expect these values wrapped in a specific ASN.1 DER-encoded structure within a PKCS#7 container.

It’s like having a perfectly valid conversation in English, but the listener expects French. The meaning is there, but the format doesn’t match.

A common error when signing with ECDSA signatures using Nutrient

If the signature format isn’t compatible with PDF validators, you might see errors like the following when attempting to validate a document:

[Core::SignatureValidator] Error verifying the integrity of the digital signature: Could not find any algorithm named 'EMSA3(SHA-256)'

You may encounter this error during an SDK upgrade — for example, moving from 2024.5.2 to 1.4.1 — when an ECDSA signature is packaged in a way validators don’t expect. This isn’t a version issue; it’s more of a formatting mismatch.

What does EMSA3 (SHA‑256) mean?

RSA signatures use padding schemes to stay secure — think of them as extra seasoning added around the signature. Encoding methods for signatures with appendix (EMSA) is just a fancy name for these padding schemes. EMSA3 is the IEEE 1363 label for the padding everyone knows as PKCS #1 v1.5. The twist: This padding only makes sense for RSA, not ECDSA. So if you see an EMSA3 error, it usually means your signature is being read as RSA when it should be ECDSA.

The two-path solution

Based on the ECDSA challenge discussed above, we’ve identified two reliable approaches to ensure signatures validate correctly.

Path 1: The DER conversion route

If you’re using SignatureCallbackResponseRaw, you need to convert Web Crypto’s raw format to DER encoding:

// The raw signature needs proper ASN.1 encoding.
function convertRawToDER(rawSignature) {
  const r = rawSignature.slice(0, 32);
  const s = rawSignature.slice(32, 64);
  // Critical: Pad with zero if high bit is set to prevent negative interpretation.
  const padIfNeeded = (bytes) =>
    bytes[0] & 0x80 ? new Uint8Array([0, ...bytes]) : bytes;
  // Build proper DER SEQUENCE structure.
  // [ASN.1 encoding implementation]
}

Path 2: The PKCS#7 container approach

For production applications, SignatureCallbackResponsePkcs7 provides more control and reliability:

// Using asn1js and pkijs libraries for robust PKCS#7 construction.
import { ContentInfo, SignedData } from "pkijs";
import { fromBER } from "asn1js";
async function buildPKCS7Container(ecdsaSignature, certificateChain) {
  // Construct complete PKCS#7/CMS container with proper ECDSA OIDs
  // Include full certificate chain for validation.
  return containerBuffer;
}

For ECDSA, SignatureCallbackResponseRaw isn’t compatible, so the reliable approach is to use a carefully crafted SignatureCallbackResponsePkcs7 ArrayBuffer, which ensures proper encoding, correct ECDSA identifiers, and full certificate chain support.

Certificate requirements for PDF digital signatures

ECDSA implementation isn’t just about signature format — your certificates need specific extensions for PDF signing:

# Essential extensions for PDF digital signatures.
X509v3 Key Usage: critical, digitalSignature, nonRepudiation
X509v3 Extended Key Usage: critical, codeSigning, documentSigning

Without these extensions, signatures will fail validation, even if they’re perfectly formatted. For the full list of requirements, refer to our guide on signing a PDF with a certificate in the browser.

When ECDSA signatures fail, traditional debugging approaches often fall short. Below is an overview of tools that actually help.

• Visual ASN.1 analysis — Use Lapo’s ASN.1 JavaScript decoder(opens in a new tab) to inspect your PKCS#7 containers. Convert your signature buffer to Base64, paste it in, and verify the structure matches PDF requirements.
• OpenSSL verification — Write your signature bytes to a file and use OpenSSL to analyze the structure and validate certificate chains.
• Certificate chain completeness — Ensure you provide the full certificate chain, with intermediate CAs as required, as detailed in our certificate chain documentation.

Summary

Successful ECDSA implementation comes down to understanding that it’s not just an algorithm swap — it’s a format transformation challenge. The signature algorithm works perfectly; the challenge is packaging those signatures in the format PDF validators expect.

Key success factors:

• Encode properly — Convert raw Web Crypto output to DER format
• Package correctly — Use PKCS#7 with proper ECDSA object identifiers
• Certify completely — Include required extensions and full certificate chains
• Debug visually — Use ASN.1 decoders to inspect signature structure

For advanced scenarios like HSM integration or cloud-based signing, consider our experimental hash-signing with AWS, which provides even more flexibility for delegated signing workflows.

The complexity is frontloaded; once you have the encoding pipeline working, ECDSA signatures provide superior performance and security for your document workflows. And with Nutrient’s robust support for both traditional digital signatures and modern eSignature workflows, you can build comprehensive signing solutions that meet diverse customer needs.