Code signing requires private key PEM, but providers (e.g., Certum) don’t provide private key for download

[jiwei-aipolabs]

Hey,

I’m trying to set up code signing for use with dxt, but I’ve run into a blocker: it looks like your process requires access to a private key PEM file for signing. However, most major certificate providers—like Certum —do not allow you to download the private key. Typically, the private key is generated and stored securely on a hardware token or HSM, and never leaves the device.

This makes it impossible to export the private key and generate a PEM file as required. 😢

Is there an alternative supported workflow for users whose certificate providers do not allow exporting the private key?

Any advice or help on how to move forward with code signing in this situation would be greatly appreciated.

If anyone else has encountered and solved this problem, I’d love to hear how you processed it as well.

Thank you!

[trknhr]

Sigstore Integration Proposal

I've been exploring this issue and would like to propose adding Sigstore support to dxt. This would solve the private key export problem while providing modern, keyless signing capabilities.

Current Problem

The current implementation requires a private key PEM file, which is incompatible with:

1. Hardware tokens/HSMs (as mentioned in this issue)
2. Sigstore's keyless signing approach
3. Modern certificate providers that don't allow key export

Proposed Solution: Native Sigstore Support

Add a --sigstore flag to enable keyless signing:

# Proposed usage
npx dxt sign --sigstore test.dxt

# Or with specific identity provider
npx dxt sign --sigstore --oidc-issuer https://oauth2.sigstore.dev/auth test.dxt

Implementation Approach

1. Add Sigstore as an optional dependency

{
  "optionalDependencies": {
    "@sigstore/sign": "^2.0.0"
  }
}

2. Extend the signing interface

// In the sign command
if (options.sigstore) {
  await signWithSigstore(file, options);
} else {
  await signWithPEM(file, options.cert, options.key);
}

3. Implement Sigstore signing

async function signWithSigstore(file, options) {
  const { Signer } = require('@sigstore/sign');
  const signer = new Signer({
    oidcIssuer: options.oidcIssuer || 'https://oauth2.sigstore.dev/auth',
    oidcClientID: 'sigstore',
  });
  
  const bundle = await signer.signBlob(fs.readFileSync(file));
  fs.writeFileSync(`${file}.sigstore.bundle`, JSON.stringify(bundle));
}

Benefits

1. No private key management - Uses OIDC for authentication
2. Hardware token compatible - No need to export keys
3. Industry standard - Sigstore is becoming the de facto standard for software signing
4. Backward compatible - Existing PEM-based signing still works

Alternative: External Signing Support

If full Sigstore integration is too complex, consider allowing external signing tools:

# Allow custom signing command
npx dxt sign --external-signer "cosign sign-blob" test.dxt

Would the maintainers be interested in a PR for this? I'm happy to work on implementing either approach.

Related Resources

• [Sigstore documentation](https://docs.sigstore.dev/)
• [npm's RFC for Sigstore adoption](https://github.com/npm/rfcs/blob/main/accepted/0049-link-packages-to-source-and-build.md)
• [Node.js Sigstore integration discussion](doc: add meeting minutes 2023-09-14 nodejs/security-wg#1105)

[bryan-anthropic]

Hi @jiwei-aipolabs — you're correct. The current mcpb sign command only accepts PEM-encoded private keys. It does not support PKCS#11 (HSM/hardware token) signing or any external signing interface.

This is a known limitation. Certificate providers like Certum that store keys on hardware tokens require a signing API (PKCS#11, CNG, or similar) rather than direct key access. Supporting this would require either:

1. PKCS#11 integration — allowing mcpb sign to interface with HSM/token drivers directly
2. External signer support — a --external-signer flag that delegates to an external tool (like cosign, signtool, or the provider's CLI)

Keeping open as a genuine gap in the signing workflow.