Re: Code signing, trusted publishers, and expiration dates?
- From: "Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx>
- Date: Tue, 27 Mar 2007 18:29:01 -0400
While it is certainly possible to create your own self-signed code-signing
certificates which are valid for any time period and convince your clients
to install them (through some installation process), this is not a wise
idea.
If you have a self-signed certificate you probably have no mechanism for
revocation .. which is a fairly complicated infrastructure which you
automatically benefit from when you have a VeriSign or related issued
certificate.
What if you create your own self-signed cert for code-signing purposes,
valid for say 10 years and have the certificate installed to the clients
Trusted Publisher store or whatever store makes downloading exe signed with
taht cert transparent and then, horror of horrors .... the code-signing
cert's private key is jeopardized or compromised in some way? You have a
potential major disaster on your hands .. no good way to revoke it.
That is just one of several bad security risk-scenarios that you incur if
you roll your own self-signed code-signing infrastructure.
That being said .. I have done this .. but mainly for testing purposes ;-)
e.g. this cert is 2048 bit certificate I use for code-signing is valid for
4 years:
http://www.jensign.com/certs/javascience2048.cer
- Mitch
"Scott Bussinger" <scottb@xxxxxxxxxxxxx> wrote in message
news:emClzvLcHHA.4772@xxxxxxxxxxxxxxxxxxxxxxx
Mitch and Jeffrey,
Thanks for the help!
Essentially a renewal is the same as getting a new cert.
This was the key phrase I was worried about.
I sell vertical market software into a sector that has very non-technical
and inexperienced users. Any dialog that pops up (like for a non-signed
executable) causes a lot of support headaches. I was considering having
our installation program just install our certificate onto their machine's
trusted publisher store as a way to avoid them receiving what to them
would be strange dialogs when running our software or updates to our
software. But since nobody seems to sell long-term certificates this
doesn't look like much help (we'd have to reinstall new certificates every
couple of years anyway).
The problem we're trying to avoid is having an administrator need to go to
every machine for every update (our customers rarely have domains set up
and never have an IT staff). I love that Vista is enforcing the least
privileged user for machines, but it does complicate some things. I'd love
it if we could do one last update that required administrative permissions
and then "never" have to mess with individual workstations again. (Our
application lives on a share on their internal file server.)
Hmmm. We may not be able to purchase a long term codesigning certificate
(we're currently using Thawte and they only support a 2 year renewal), but
perhaps we could create a self-signed certificate with a really long
expiration period (say 20 years). We would sign our externally
downloadable update executables with our "real" Thawte certificate,
install our self-signed certificate into their trusted publisher stores
once, and then sign the installed applications with our long term
self-signed certificate. This would require administrative permissions one
time, but still allow updates to be trusted for the foreseeable future.
Be seeing you.
.
- References:
- Code signing, trusted publishers, and expiration dates?
- From: Scott Bussinger
- RE: Code signing, trusted publishers, and expiration dates?
- From: "Jeffrey Tan[MSFT]"
- Re: Code signing, trusted publishers, and expiration dates?
- From: Scott Bussinger
- Code signing, trusted publishers, and expiration dates?
- Prev by Date: Re: Code signing, trusted publishers, and expiration dates?
- Next by Date: RE: CryptExportPublicKeyInfo fails
- Previous by thread: Re: Code signing, trusted publishers, and expiration dates?
- Next by thread: CSP: parameter PP_SMARTCARD_GUID for function CPGetProvParam
- Index(es):
Relevant Pages
|
