You’ve probably use timestamp server to sign your code, either for tests or production,
it’s a good practice.
timestamp.verisign.com servers are the oldest, which means they are common in most of online guides for signing using Microsoft/Sun/Oracle/OpenSSL tools.
Both variation of
timestamp.verisign.com, which are
http://timestamp.verisign.com/scripts/timestamp.dll might seems not responsive (at least on port 80, when you’ll try opening them with your browser)
Want more, here is a list:
http://sha1timestamp.ws.symantec.com/sha1/timestamp http://sha256timestamp.ws.symantec.com/sha256/timestamp http://timestamp.comodoca.com/authenticode http://timestamp.comodoca.com/rfc3161 http://timestamp.comodoca.com?td=sha256 http://timestamp.comodoca.com?td=sha1 http://timestamp.entrust.net/TSS/AuthenticodeTS http://timestamp.entrust.net/TSS/RFC3161sha1TS http://timestamp.entrust.net/TSS/RFC3161sha2TS http://timestamp.globalsign.com/scripts/timstamp.dll http://tsa.starfieldtech.com http://www.startssl.com/timestamp http://timestamp.geotrust.com http://timestamp.geotrust.com/tsa
I’ve personally moved to using either
http://sha256timestamp.ws.symantec.com/sha256/timestamp (mostly the SHA1 one for signing APK, JAR and ZIP files for Android application development, or as a part of flushing a custom-build kernel/firmware on to a device, which for an official Android-download mode is too a requirement).
The comodo one is pretty great too.
timestamp server usually “understand” your requirement by the digest-algorithm argument you’re passing to (
/td for Microsoft’s
-digestalg for Sun/Oracle’s