Re: Signing corporate applications

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Jun 7, 2:32 am, "Steve B." <steve_bea...@xxxxxxxxxxxx> wrote:
After further investigations, and according your feedbacks, I'm driving to
this solution :

Since our apps are deployed using a custom autorun.exe, we can add our
custom corporate certificate to the "unpriviledge certificate store" from
the autorun (priviledge app seems to be very more restrictive but I don't
think our apps will require this priviledges). I've successfully created a
small prototype of such autorun.
However, the autorun.exe itself is not signed. So I think about buying a
certificate to a commercial authority in order to sign autorun.Exe, and only
autorun.exe. Since we have a complete (and complex :) ) app auto updating
and deployment mechanism that uses dozens of cab files, we can't "buy" each
signing event. According that, we will sign all corporate packages with our
own certificate.

The next step is to choose a certificate authority. My feelings is that M2M
is not the good choice, since it requires the app to be validated against
some requirements to obtain the "designed for Windows Mobile" logo, in a ISV
vision.
Is verisign a cood choice in this case ?
We already have bought a signing certificate for a desktop application that
is deployed with clickonce to the web. Should this certificate be used to
sign mobile application ?

Thanks,
Steve

Steve,

It sounds like your idea will probably work, but you will need to sign
your autorun.exe (which I presume will be running on the handheld)
with an ACS certificate such as the one Verisign sells.
You will not be able to sign your handheld exe with a normal Software
Publisher Certificate, such as waht you would use to sign an exe
running on the desktop. The ACS involves code-signing events and
they're sold in packs of ten for $400 (I know what you're thinking...
and you're right)

http://www.verisign.com/products-services/security-services/code-signing/microsoft-smartphone-code-signing/index.html

The idea you have sounds like it will work. You'll need to create you
autorun.exe and have it insert your custom certificate into both the
Unpriviledged Certificate Store *and* the Software Certificate store
on the handheld. You would then sign your deployment CAB file and
*all* of the exes and dlls that it contains with your custom
certificate.

You will then need to sign autorun.exe with an ACS for Verisign or
some other root cert suthority. The the way Verisign does this is to
have you to upload your autorun.exe to them using a web interface,
they sign it with the ACS an then you download the signed exe (in your
case autorun.exe)

The good thing about about idea is that you only need to use one
signing event to sign just your autorun.exe (which will be installing
your custom cert to the Unpriv. Cert Store and the Software Provider
Cert store.) That way you have nine signing events left over to use in
case you need to make changes to your autorun.exe and sign it again.

The bad news is that Verisign has come up with a scam to take
advantage of the WIndows Mobile security model (ACS), and Verisign is
using this situation to shake down developers for as much money as
they possibly can. Verisign knows that there's nothing technical they
can do do stop you from implementing the solution you've come up with,
so they've added a little line to their EULA that states that an
application signed with their ACS certificate cannot be used to
install another certificate. This way they can try to force developers
to sign each and every exe and dll they are deploying (not to mention
having to sign the CAB file that holds the apps) to ensure that
developers use up and many code-signing events as possible in as short
a period of time as possible. Not to mention the fact that the code-
signing events expire 12 months after the purchase. It's a real scam.
How can a small developer or small company possibly be expected to be
able to afford this?

Btw, the thing you mentioned about needing to meet requirements for
the "windows logo" only applies to obtaining a privileged certificate,
which your app probably won't need unless you're making registry
changes or something of that nature. Here is a list of the privileged/
trusted APIs:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceosdev5/html/wce50conTrustedAPIs.asp

-Scott

.

Relevant Pages

  • Re: Access DEveloper Extensions 2003
    ... distribution of run time 2003 apps? ... >>come from a Root Authority, i.e., Verisign or Thawte. ... >certificate as a root certificate in the client OS. ... > Microsoft Access Links, Hints, Tips & Accounting ...
    (microsoft.public.access.devtoolkits)
  • Re: Prevent Acc 2003 JET Security Warning for MDE
    ... Sorry for the delay in getting back to you, Chris, I was ill for a few days ... resign the same app or sign different apps with the same certificate. ... GlobalSign digital certificate is a forgery and should be deleted without ...
    (microsoft.public.access.setupconfig)
  • Questions on deploying apps on a file server
    ... We keep our apps centralized on a file server and our users simply run them ... have to run any type of setup on the local machine including ... If we used this certificate, would our machines try to bounce up against ...
    (microsoft.public.dotnet.security)
  • RE: Questions on deploying apps on a file server
    ... Rather than signing with a Verisign certificate, you can sign with a keypair that you create with the sn tool. ... assembly signed with that private key, and your applications will be able to run off of the file server with no problem. ... >We keep our apps centralized on a file server and our users simply run them ...
    (microsoft.public.dotnet.security)
  • Re: Java Web Start
    ... that is just a certificate for apps I wrote. ... Coaching, problem solving, economical contract programming. ...
    (comp.lang.java.programmer)