I'm trying to sign a manually created ZXP file using the ZXPSignCmd application. As the plugin comes as a part of a software package and installed by it, I can't generate a dummy certificate and re-sign the plugin using Adobe Exchange facility. So I have to use a commercial certificate to make sure no warnings will be shown to the end user.
Here is the command line:
ZXPSignCmd.exe -sign src plugin.zxp certificate.pfx <password> -tsa https://timestamp.geotrust.com/tsa
The "certificate.pfx" is a commercial Comodo certificate I use for signing applications. It is recognized on all modern operating systems without downloading any intermediate certificates.
I get a signed ZXP-file as a result, but when I try to install it using extension manager I get the "can not be verified" error. Here's what ZXPSignCmd.exe -verify tells me (private data removed):
c:\>ZXPSignCmd.exe -verify plugin.zxp -certInfo
*********** Certificate Information ***********
CN: <company name goes here>
DN: <certificate details goes here>
OS Trusted: false
Timestamp: Valid and within certificate validity dates
Signature verified successfully
I guess that the "OS Trusted: false" is the key, but have no idea what to do about this. The certificate is more than valid and I have no issues with it so far. Any ideas what to check or try?
I have also tried to get a detailed log of the installation, just in case. Here are the most interesting lines, I guess (private info removed):
[Warning] Tue Mar 04 20:21:01.904 2014 (..\Source\Util\SignatureValidator.cpp, 155) -CSignatureValidator::verifySignature: timestamp has an in-range date and is valid!
[Trace] Tue Mar 04 20:21:01.905 2014 (..\Source\Util\SignatureValidator.cpp, 191) -CSignatureValidator::verifySignature: extension in C:\ProgramData\Adobe\Extension Manager CC\Temp\TMP_20140304202059550: dn-"<certificate details>", cn-"<company name>", ou-""
[Trace] Tue Mar 04 20:21:01.906 2014 (..\Source\Util\SignatureValidator.cpp, 237) -CSignatureValidator::verifySignature: extension is 3rd_party_signed_untrusted!
The second question is about the timestamping service. Not sure if it is related, but anyway. I tried to use another timestamping service, suggested by Comodo: http://timestamp.comodoca.com/authenticode, but got the 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.
The question is: should I worry about this at all, or I can simply use the standard geotrust time server? Can timestamp server affect the signature validation?
Thanks for getting in touch.
In answer to your second question, it is probably best to use the standard Geotrust time server when you see that error. Different timestamping services may use different formats for their timestamps - Geotrust's is definitely understood by ZXPSignCmd's verification process, but there are other formats which it cannot handle at present. Therefore, if ZXPSignCmd will be used to verify the ZXP's timestamp (e.g. before loading an Adobe Extension or installing via Extension Manager), it is important that it is able to verify the timestamp successfully.
ZXPSignCmd immediately tries to verify the timestamp it receives from the timestamping server, so if this error is seen then it means that ZXPSignCmd will not be able to verify it later either.
Regarding the "OS Trusted: false" output you are seeing - could you please email me your ZXP at fgregor at adobe dot com so that I can inspect it?
I suspect that the problem may be to do with the ordering of certificates in the signature, but it is difficult to tell without looking at the signature itself.
Thanks, I've just sent you the plugin by e-mail.