Sorry to hear about this Anatoly. StageManager validates the signature of extensions at load time to ensure that the installed extension footprint hasn't been modified. But I agree the current behaviour seems very strict, I have logged a bug internally for this and someone will look into whether we can change the behaviour in this area.
Anatoly, I am still digging into this but in the meantime could you help me by looking at your signed extension's signature.
Does the META-INF/signatures.xml file in the bundled zxp contain a timestamp? Search for "SignatureTimeStamp".
Also, how did you sign your extension? Using Extension Builder, the Packaging And Signing Toolkit, or something else?
Thank you for the quick response.
>>StageManager validates the signature of extensions at load time to ensure that the installed extension footprint hasn't been modified.
I don't think that StageManager should use signatures to validate that the extension hasn't been modified - the signature is only guaranteed to be valid at installation time. StageManager could use some hash code stored by extension manager to make sure that the extension has not changed.
I couldn't find timestamp in signatures.xml.
You can download the extension from here: http://bit.ly/n9xnG9
It was signed using extension builder, the older version of it.
Please let me know if you need any more information,
Okay - thanks for the info. I am following up with a couple of teams on this, will let you know what the outcome is hopefully in the next couple of days
Anatoly, let me summarise my thoughts/findings on this:
- Your extension's signature is invalid now that your certificate has expired (as you have reported)
- Your extension's signature is not timestamped with a timestamp certificate. A signature without a timestamp is only valid till the signing certificate expires. A signature with a timestamp is valid until the timestamp certificate expires, typically a much longer period.
- As you can infer from this, Extension Builder does not create timestamped signatures and does not give any warning about this. Apologies that we failed to anticipate this problem during CS SDK and Extension Builder development. You will probably agree this is not good enough, and I have filed a bug (#2916071) to ensure this is dealt with in future releases.
As I mentioned earlier, extension signature validation is performed on extension load to ensure an extension's footprint has not been maliciously modified since installation. I think it is very unlikely that we can remove this signature validation for security reasons, nonetheless I've started a conversation about it internally and can let you know the outcome.
To help your users now, I think you will need re-sign and re-deploy your extension with a new certificate. So you can timestamp the signature, use ucf.jar in the Packaging and Signing Toolkitto sign the extension rather than Extension Builder. Pass the argument -tsa=<your_chosen_timestamp_server> to ucf.jar when signing and check the signature is timestamped
Could you provide information on how to verify that the signature has been timestamped.
Also, in the doc for ucf.jar (PkgSignDeployTechNote.pdf) when describing the -tsa option on page 6, it sounds like timestamping is on by default, using a server at timestamp.geotrust.com, unless the user explicitly specifies "none". Is that correct? So do we need to explicitly use the -tsa option, or do we just avoid specifying "-tsa none"?
An easy way of checking for the timestamp is to see whether the META-INF/signatures.xml file in the bundled zxp contains a "SignatureTimeStamp".
Unfortunately the Packaging and Signing Toolkit documentation is just plain wrong on the -tsa option - sorry for the confusion this causes. As with the Extension Builder signing issue, this will be fixed for the next release.
It should say that -tsa is 'none' by default. To sign with a TSA you must pass -tsa <timestamp-server-url>, none is used by default.
I will be writing a cookbook to try and highlight these bugs as soon as I can, in the meantime let me know if you have any more questions.
I get a release by using "-tsa none" but it's the same result.
Is it normal that the default url https://timestamp.geotrust.com/tsa is error 404 ?
Is there any other correct urls ?
Confusingly, the documentation is wrong - the default is actually -tsa=none. You shouldn't use -tsa none if you want to avoid this problem.
I think the TSA you mention is used by most AIR apps, so I'd be susprised if it was down. Did you try using it as the tsa parameter?
Note that if your own certificate has expired, then specifying a TSA won't help you. You need to sign with a certificate that hasn't expired.
Ok, so i tested it but unsuccessfull....
is there any work around until the incoming update ?
If your extension signature is invalid immediately after signing, it suggests to me that your certificate is invalid (for example, has it expired?). I'd check that out first.
If it is valid, maybe you are using an incorrect command for ucf.jar.
My certificate is valid. We use it for our Air applications.
ucf.jar -package -storetype PKCS12 -keystore xxxxx.p12 -storepass xxxxx -tsa https://timestamp.geotrust.com/tsa extension.zxp -C /Users/Pierre/Workspace/ .
And on two computers during extension installation, that doesn't work ... always the same message "Extension does not contain valid signature"
The only thing that jumps out at me is your -C argument.
The example in the docs is:
-C "./myExtension" .
You could try copying this syntax - use a relative path, and use quotes around the path. Does that make any difference?
If not I would try unzipping the zxp after you've tried to sign it, and check whether the contents are as-described in the docs (with respect to mimetype and signatures.xml).
That makes no difference.
Is it possible I send you our extension to check if all is ok ?
If you unpack the zxp, does it look signed? Does the signature look different to other signed extensions installed in your system?
If you want to send files for an engineer to look at, you can purchase a support case from firstname.lastname@example.org
Ok I sent pkg to this email because all seems to be ok for me.