tags:

views:

178

answers:

3

We perform code signing and timestamping for all our production builds. Occasionally (usually when we are about to RTM (!) ) the timestamp server at verisign ("http://timestamp.verisign.com/scripts/timstamp.dll") decides to go offline intermittently.

Anyone got any suggestions as to what do do in this case?

  • Does the timestamp server have to be hosted by your root certification authority?
  • Are there any other network hosted timestamp servers we could use
    instead of Verisign if their server is down? Suggestions for other highly available and free alternatives welcome :)
A: 

I can imagine a poorly written contract which has requires a certification authority to timestamp data, but having a duly authorized corporate officer authenticate and digitally sign seems that it would be preferable on all counts. In particular, if I am suing you, it is simpler to depose your officer than some third-party CA.

If a third party CA is not a immutable contractual requirement, have the CA certify your officer's GPG or PGP free, home-made, always available signing key and timestamp in-house. It is actually better for everyone involved even if your customer mistakenly believes otherwise.

Added: A timestamp certification is only useful in legal proceeding or similar forensic endeavors (e.g. establishing patent priority). As such, they are only as credible as the person vouching for them. If your customer can't trust that your officer won't perjure herself over the authenticity of a time-stamp, they probably shouldn't be doing business with you. Or conversely, a notary only certifies that it was you who signed the document in his presence, he says nothing about the provenience or validity of the document, nor can he or should he.

msw
Uh, what does this have to do with the question? Authenticode signs an executable with a certificate that "proves" it is created by the organization in question (provided you trust the certificate, and the CA - though this is somewhat easy to verify by getting their certificate fingerprint out-of-band). Timestamping allows the signed EXE to be valid for as long as the CA is trusted (typically 10 years), and not just when the certificate is valid. Without it, when the certificate expires (every 1-2 years typically), the EXE will fail validation.
gregmac
+1 to gregmac's comment. see http://www.positivessl.com/code-signing/code-signing-technical.html
Roddy
+1  A: 

I'm not sure if the timestamp server has to be owned by the root CA or not.

We use http://timestamp.comodoca.com/authenticode (and have a Comodo authenticode certificate) but actually have a similar issue, in that their server seems to give an error or time out occasionally. We do signing as part of a nightly (or on-demand) build on our continuous integration server for Release builds only (not for Debug builds).

I got around this (mostly) in two ways:

  • If the call to signtool.exe fails, it tries again (immediately) twice more
  • The build script used to sign every exe in one step (and we have several as part of our product), and now it does one-by-one - takes slightly longer, but is less likely to fail

Between these, build failures caused by timestamp server issues have gone from once or twice a week thing to virtually never.

gregmac
A: 

Any timestamp server can be used: I recently switched from my issuer's timestamp server to Verisign since I found that GlobalSign's server was unreliable. Furthermore, Thawte don't run their own timestamp server but recommend people to use Verisign's.

BruceCran