ZXPSignCmd sign process is broken (segmentation fault)

[Alex White]

Looks like the ZXP sign process is broken both on macOS and Windows.

• macOS: Signing process ends with: [1] 21894 segmentation fault ./ZXPSignCmd -sign mypassword -tsa
• Window: just fails with no error

1. Command that fails:  ./ZXPSignCmd -sign "/Users/admin/Desktop/extension/dist/cep" "/Users/admin/Desktop/extension/dist/zxp/com.my.extension.cep.zxp" "/Users/admin/Desktop/extension/lib/.tmp/com.my.extension.cep-cert.p12" mypassword -tsa http://timestamp.digicert.com/
2. None of the environments nor macOS nor Windows has changed. It just worked yesterday and today it's not.
3. ZXPSignCmd has proper executable rights
4. Tried changing timestamp servers
5. Tried using different network connection
6. Verified with different repos/tools
7. Tested on ARM/x64 macOS, ARM/x64 Windows. All fail to sign
8. Confirmed the same behavior by many devs

[Justin Taylor-Hyper Brew]

Also seeing ZXP failures on all of our Windows and Macs both Intel and ARM, even with testing various TSAs, primarily DigiCert. Panels were building fine yesterday.

It doesn't seem that the executable cert has expired so I'm guessing some other internal mechanism is phoning home to some site that is down or using another verication that has expired or no longer works.

A timely fix is crucial for extension developers across Adobe apps to continue to update and publish new versions of their tools.

Additionally, long-term open sourcing ZXPSignCmd would be a smart choice so developers could temporarily patch issues like this on their own while waiting for offical fixes from Adobe.

Thanks for your help

[Bart Walczak]

I am seeing exactly the same thing, looks like some Adobe service is not functioning correctly. A timely fix would be extremely welcome, because there is no alternative to ZXP Sign for distribution. 

[trevorq90181746]

I am experiencing the same issue and can't patch a bug since I can't sign an updated version of my extension. 

[Softmatic GmbH]

Any news on this? We are having the same issue, signing works but only without timestamp. We are using a self-signed cert which expires in 2034. As far as I understand, it should be safe to omit the timestamp when the expiry is so far out. Can anyone confirm this?

[Chris Hocking]

Confirming... still broken here too for the last few days.

[Ivan Stepanov]

For me everything works. I switched to http://timestamp.apple.com/ts01 long time ago.

System: macOS ARM.

I use this version of ZXPSign.

Result file has .zip extension, but tested .zxp and it works as well.

Command:

./ZXPSignCmd-64bit -sign "/path/to/extension" "/path/to/extension.zip" "path/to/certificate.p12" mypassword -tsa http://timestamp.apple.com/ts01

[--aaron--]

Using the Apple tsa fixed this issue for us as well. 
Thanks @Ivan Stepanov for the helpful clue. 

Agreed that Adobe should provide an open source option for ZXPSignCmd. This is a critical part of the pipeline so when it breaks it would be good to understand why. 

[Cameron J]

Confirmed - switching from Digicert to the Apple tsa worked for us: http://timestamp.apple.com/ts01

[Justin Taylor-Hyper Brew]

Great find @Ivan Stepanov, I'm glad that we have a working soluion for MacOS!

Unfortunately after testing on 14 different TSAs (from StackOverflow and and Davide), the problem still persists on Windows and on MacOS with any other non-apple TSA. (see full testing details below)

My guesses are either:

A: There is some speical access for Apple-to-Apple timestampping that allows the Apple TSA to work on Macs, but all others are broken

or

B: Something is patched in ZXPSignCmd 4.1.2 to allow this, but since there was never a 4.1.2 version published for Windows, we're stuck with a bug on 4.1.1

All ZXPSignCmd Versions (latest Win: 4.1.1, latest Mac: 4.1.2) 

It's great we have a solution for Mac, but lots of users, workflows, and build systems rely on Windows as well, so we need working solutions for both.

As @Softmatic GmbH and @Alex White have pointed out, it is possible to create a ZXP by omitting the TSA, however this comes with an expiration date, though "supposedly" far in the future, from the Adobe documentation in SigningTechNote.pdf sounds like it could break sooner without warning:

 

----------------------------------------------------------------------------------------------------------------------------------------------------

Full testing details on Mac and PCs:

Works on MacOS but not Windows

• http://timestamp.apple.com/ts01

Both OS's report: Error - the timestamp returned from the chosen TSA could not be verified, so the ZXP created s likely to be rejected by other tools. Please recreate your ZXP with a different trusted TSA.

• http://time.certum.pl/
• http://zeitstempel.dfn.de
• http://timestamp.globalsign.com
• http://timestamp.globalsign.com/scripts/timstamp.dll

Both OS's report: Error: [cep] Command failed: ZXPSignCmd ...

• http://timestamp.digicert.com/
• http://timestamp.comodoca.com
• http://timestamp.entrust.net/TSS/RFC3161sha2TS
• http://tsa.swisssign.net
• http://timestamp.acs.microsoft.com
• http://timestamp.sectigo.com

Both OS's report: Error - cannot contact the chosen TSA. Please make sure the URL is valid and that you are onnected to the internet.

• http://tsa.starfieldtech.com
• http://sha256timestamp.ws.symantec.com/sha256/timestamp
• http://timestamp.verisign.com/scripts/timstamp.dll

----------------------------------------------------------------------------------------------------------------------------------------------------

[Softmatic GmbH]

Did some more testing and http://timestamp.apple.com/ts01 worked for us on macOS, thanks to @Ivan Stepanov. All other timestamp servers resulted in either seg faults or "Error - cannot contact the chosen TSA". Adobe should open source this tool ASAP.

[Garrick Meeker]

I believe the Apple timestamps are failing on Windows because the OS doesn't trust Apple's root certificate.

[Justin Taylor-Hyper Brew]

That may be part of the issue, but there must be more involed since other TSAs besides DigiCert used to work and now none of them work except Apple on Apple.

[Garrick Meeker]

Yes, the failures with DigiCert are the most concerning issue here. I'm just suggesting that using Apple is not really a fix due to Windows not trusting that root certificate. Even if you sign on a Mac, I'm not sure that Adobe will trust that timestamp on Windows. Then again, Adobe seems to trust self-signed certificates if you install a panel manually so maybe they don't care about the timestamp's root certificate, outside of ZXPSignCmd.
Hopefully signing with DigiCert will work again soon.

[Henrique - TMMW]

+1 waiting for a windows solution

[Ivan Stepanov]

@Justin Taylor-Hyper Brew indeed on Windows ZXPSignCmd doesn't work!

Here is an update on the working solutions, based on my tests.

Working timestamps:

• http://timestamp.apple.com/ts01
• http://tss.accv.es:8318/tsa

Windows solution:

• https://github.com/JuMouren/SignAndPackage
  You will need to install Java, replace certum timestamp in .bat file with any of 2 above.

SignAndPackage worked with both timestamp.apple.com and tss.accv.es timestamps on Windows, so it seems that option B is correct.

B: Something is patched in ZXPSignCmd 4.1.2 to allow this, but since there was never a 4.1.2 version published for Windows, we're stuck with a bug on 4.1.1

By  @Justin Taylor-Hyper Brew

[Bart Walczak]

Some is doing something, because apple timestamp no longer works, failing this time with a different error:

```

libc++abi: terminating due to uncaught exception of type boost::filesystem::filesystem_error: boost::filesystem::copy_file: File exists: "/tmp/zxpsignaOXSxzWIDPHbj6r0/tmp.zxp",

```

[Softmatic GmbH]

Same here, Apple TSA doesn't work anymore (macOS 15.2). What a mess.

[Yuer Lee]

I can still sign with the Apple TSA (ZXPSignCMD 4.1.2, macOS 15.4.1).

[Ivan Stepanov]

@Bart Walczak make sure /tmp/zxpsignaOXSxzWIDPHbj6r0/tmp.zxp file doesnt exist. ZXPSign fails if destination file exists.

[Bart Walczak]

@Ivan Stepanov It's a different file every time and every time it fails for me now.

% sudo rm /tmp/zxpsignA2rsTGTwt155N5EB/tmp.zxp
Password:
% ls /tmp/zxpsignA2rsTGTwt155N5EB/tmp.zxp
ls: /tmp/zxpsignA2rsTGTwt155N5EB/tmp.zxp: No such file or directory
% ZXPSignCmd-64bit -sign ... 
libc++abi: terminating due to uncaught exception of type boost::filesystem::filesystem_error: boost::filesystem::copy_file: File exists: "/tmp/zxpsignaH8nusHa0xZtJboh/tmp.zxp",

[Justin Taylor-Hyper Brew]

@Ivan Stepanov I can confirm http://tss.accv.es:8318/tsa works as well on both Intel and ARM MacOS machines, thanks. So must not be an Apple-to-Apple thing.

Regarding Alternative ZXPSignCmd options for Windows. That one does look interesting, Kris Coppieters mentioned it in another thread. Although it would sure be nice to see an open-source alternative, and one that's still maintained.

• https://github.com/JuMouren/SignAndPackage

@Bart Walczak The Apple TSA is still working on all our Macs, I think you're running into a different problem. Might want to test in a fresh directory, reset permissions, and those sorts of things.

[Bart Walczak]

Funny, now ZXPSignCmd is working for me with Apple tsa, while ZXPSignCmd-64bit is still coughing up the exception. Well, at least I can use it for Mac signing. 

[JohnColombo]

Hi all,
Thank you for reporting this and for all the details you've provided. We're actively investigating the root cause of the breakage and will update this thread once we have an update and/or a fix. Our apologies for the frustration this is causing.

- John, After Effects Engineering Team

[markusbergelt]

So glad I found this thread after days of troubleshooting... Can confirm that no TSA with any version of ZXPSignCmd is working on windows. Signing without TSA works. @Justin Taylor-Hyper Brew Thanks for pointing out that signing without TSA and long lasting certs might not be a good option. Anyway a quick solution is critical, as our build pipeline depends on it.

[avi23837866f7yk]

Only happens on Windows(on macOS works just fine) - and when used with the "-tsa" option the ZXPSignCmd.exe tool fails to sign my CEP project.

I'm generating a self-sign certificate file as described in this CEP Resource - https://github.com/Adobe-CEP/CEP-Resources/blob/master/ZXPSignCMD/SigningTechNote_CC.pdf as follows:

./ZXPSignCmd.exe -selfSignedCert US CA MyCompany MyCompanyShortName abc123 MyCert.p12

Then, try to to sign my CEP project as follows:

./ZXPSignCmd.exe -sign my-cep/ my_cep_extension.zxp MyCert.p12 abc123 -tsa http://timestamp.digicert.com/

and getting the following error:

Error - the timestamp returned from the chosen TSA could not be verified, so the ZXP created is likely to be rejected by other tools. Please recreate your ZXP with a different trusted TSA

I'll also mention that:

• Up until last week(April 25th 2025) it was working fine.
• The issue is only reproducible on Windows, on macOS ZXPSignCmd works just fine, with/without the -tsa option.
• I tried various other tsa servers URL's - all fails.
• Signing without the -tsa option succeeded with no issues.

I also want to ask - is -tsa option is mandatory for my extension to work properly on production environment?