Skip navigation
Currently Being Moderated

Why does extension loader check extension's certificate during each loading?

Jul 10, 2011 2:26 PM

Hello,

We are having some problems with an expired code signing certificate.
We sell a commercial extension which is signed with our code signing certificate. Recently our certificate expired, and we started to receive reports that our extension had stopped working in CS5.
It looks like CS5 checks the extension's certificate not only during installation, but also at each loading.
This behavior looks like a serious bug in Creative Suite extension loader since all certificates will expire sooner or later, and this means that all extensions are doomed to stop working at some point, unless they are timely updated.
Why does CS5 check the certificate at each start up? This doesn't make sense at all, certificates are only used to check that the code is authentic during installation. An authentic extension cannot turn into malware after installation, so there is absolutely no point in checking the certificate after installation.
Can someone from the CS SDK team comment on this issue? This turned into a major problem for us.
Thank you in advance,
Anatoly Paraev
PixelNovel 

 
Replies
  • Currently Being Moderated
    Jul 11, 2011 3:17 AM   in reply to Anatoly Paraev

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 11, 2011 9:31 AM   in reply to david_a_clark

    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?

     

    Thanks

    David.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 12, 2011 12:58 AM   in reply to Anatoly Paraev

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 15, 2011 11:02 AM   in reply to david_a_clark

     

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 15, 2011 12:50 PM   in reply to david_a_clark

    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"?

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 20, 2011 10:08 AM   in reply to meeky

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 3:22 AM   in reply to david_a_clark

    Hi David,

    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 ?

     

    Thanks.

    Regards.

     

    Pierre RAFFA

    Aquafadas.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 3:41 AM   in reply to Pierre-RAFFA

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 9:06 AM   in reply to david_a_clark

    Ok, so i tested it but unsuccessfull....

     

    is there any work around until the incoming update ?

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 9:18 AM   in reply to Pierre-RAFFA

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 9:36 AM   in reply to david_a_clark

    My certificate is valid. We use it for our Air applications.

     

    command:

    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"

     

    Pierre RAFFA

    Aquafadas.

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 15, 2011 10:16 AM   in reply to Pierre-RAFFA

    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).

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 16, 2011 3:38 AM   in reply to david_a_clark

    That makes no difference.

    Is it possible I send you our extension to check if all is ok ?

     

    Pierre RAFFA

    Aquafadas

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 16, 2011 4:09 AM   in reply to Pierre-RAFFA

    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 techpart@adobe.com

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 16, 2011 5:04 AM   in reply to david_a_clark

    Ok I sent pkg to this email because all seems to be ok for me.

     

    Thanks David.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 12, 2011 9:19 AM   in reply to Pierre-RAFFA

    In case you didn't see the other thread, the Extension Manager team believe they have reproduced this on 10.7.2 (not 10.7.1) and are investigating. I will keep you posted

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points