Skip to main content
Participant
July 24, 2025
Answered

Guidance Needed for CEP Extension Digital Signing and Certification

  • July 24, 2025
  • 3 replies
  • 466 views

Hi Adobe Exchange Support Team,

 

I’m currently developing a CEP extension for Adobe Premiere Pro and need urgent guidance on digital signing and certification for distribution.

We’re running into a widespread issue: all major certificate authorities have recently restricted the ability to export .p12 and .pfx files due to private key security protocols. This has effectively blocked traditional signing methods required for Adobe Exchange.

We are now exploring cloud-based code signing options as a potential workaround — and possibly the only viable path forward. If Adobe has any officially recommended providers or documentation on how to sign CEP extensions using cloud signing infrastructure, we would greatly appreciate direct links and guidance on how to proceed.

Our goal is to get this extension signed and approved for Adobe Exchange as soon as possible. Any help you can provide to expedite this process would be incredibly valuable.

 

Thank you in advance,
Correct answer Bruce Bullis

3 replies

Participating Frequently
August 31, 2025

There's a Github ticket for this now:
https://github.com/Adobe-CEP/CEP-Resources/issues/550
Please follow if this is still relevant for you.

Bruce Bullis
Community Manager
Bruce BullisCommunity ManagerCorrect answer
Community Manager
July 25, 2025
Participating Frequently
August 21, 2025

Greetings!

 

The problem is there is no way to export a signing private key from certificate authority:  https://knowledge.digicert.com/alerts/code-signing-changes-in-2023

 

There are two options now: a hardware token or a cloud-based code signing service. None of these options allow for creation of .pfx or p.12 files.

 

According to Getting Started guide it is still expected that a p12 secret is expected on command line: "ZXPSignCmd -sign <inputDir> <outputZxp> <p12> <p12Password> [options]". But all we can export are certificates only. 

Getting Started guide also says "Commercial certificates must be purchased from a trusted certificate authority". This sentence is not 100% accurate. The p12 file must also include signing key.  While you can create a PKCS#12 file that only contains a certificate (without a private key), such a file cannot be used for signing. It would effectively function as a "trusted certificate" store, useful for verifying signatures or establishing trust in a server, but not for generating new signatures.

 

I wanted to make sure I'm not wrong about this and staged two experiments.

First I've tried to generate a selfsigned certificate file with ZXPSignCmd and imported it to certificate store. It gets imported along with private key. So ZXPSignCmd selfsigned certificate has a key. And expects a key, apparently.

Next I've tried a PKCS#12 file with just CA-issued certificates. Downloaded pem certificates and converted them to p12 with "openssl pkcs12 -export -in bundle.pem -out nokeybundle.p12 -nokeys".

ZXPSignCmd can read such a file. This is easy to check: just provide a wrong password first and see it responding with "Please check that your certificate file(s) are valid, stored in an accepted file format (e.g. PKCS12 'p12'), and that you have entered the correct password.".
But it can't use such a file. Once I've provided the correct password, ZXPSignCmd crashed with no output and a weird error code -1073741819 (seen via $LASTEXITCODE).

 

ZXPSignCmd is of version 4.1.3. Getting Started guide doesn't help.

 

Both options offered by certificate authorities (hardware token or a cloud-based code signing service) involve indirect signing methods.

It is either certificate authority integration of some form, when CA tools act as wrappers for third party utils, or third party tools link CA-provided libraries and use library calls for signing. In both cases sign requests get processed externally. By libraries that talk to hardware token or send sign requests to CA Cloud and recieve signatures from there.

 

I'm afraid these new signing methods won't be usable with ZXPSignCmd unless ZXPSignCmd developers contact DigiCert and collaborate on adding support for DigiCert's SMCTL and/or PKCS11/KSP. Other CAs too.

 

I would love to be wrong about this. But after a couple of hours of experimenting this looks like the case.

 

Best regards. Thank you!

Kevin-Monahan
Community Manager
Community Manager
July 25, 2025

Hi there,

Thanks for your message. I labeled your discussion appropriately with SDK. That should draw the proper people to your post. I hope we can help you shortly.

 

Thanks,
Kevin

 

Kevin Monahan - Sr. Community &amp; Engagement Strategist – Pro Video and Audio