How do you deploy your own Authenticode authentication service?

Question

I would like to create a timestamp for my dll file using my own Authenticode Timestamping service. Is it possible? How could I achieve this?

Answer 1

You can create your own timestamping service. You can write a TSP server (RFC 3161), but Authenticode does not use RFC 3161 formats, but PKCS # 7 / PKCS # 9, as described in the MSDN article (which you can also implement). Our SecureBlackbox components include a timestamping server component that supports both formats. Update: Recent Authenticode updates use the standard RFC 3161 timestamps.

But the problem is getting a certificate that you will use to sign timestamps. This certificate should be issued by one of the certification authorities, and, as I understand it, there are serious requirements for the management and infrastructure aspects of the timestamp server. In particular, you need to have safe temporary equipment. I did not delve into this question, but these aspects are much more complicated than writing a piece of code.

However, if you run your own PKI infrastructure (you have your own trusted root certificates and CA certificates), the problem with a reliable timestamping certificate will be solved automatically - you can create your own certificate.

Answer 2

You need to write your own Timestamp HTTP protocol. It must follow RFC 3161 Time Protocol Rules (TSP).

When you sign your authentication dll with a tool like Signtool.exe from the Windows SDK, you can specify the timestamp server url (with / t swich. See also / tr and / td). Then you point to your server.

See here about SO for a related question: Reliable Timestamps - Understanding the Format (rfc3161)

as well as: Alternative time-stamping services for Authenticode

Answer 3

With SignServer, you can configure your own time stamp authority (TSA) that supports Authenticode time stamps (and / or RFC # 3161).

See https://www.signserver.org for downloads and installation instructions. In conclusion, the important steps are:

1. Make sure you have the necessary conditions:

   • Java
   • Application Server (i.e. WildFly)
   • Apache Ant for deployment

2. Download version 4.0 from https://signserver.org or https://sourceforge.net/projects/signserver/files/signserver/4.0/ .

3. Configure Application Server

   • For HTTPS (optional)
   • To make web services work
   • Patch with latest security fixes

4. Configure SignServer Deployment

   • Set for database.name = nodb and database.nodb.location = / an / empty / folder / as / db in conf / signserver_deploy.properties

5. Expand SignServer

   • export APPSRV_HOME = / opt / wildfly-9 /
   • bean / ant deployment
   • Launch the application server /opt/wildfly-9/bin/standalone.sh

6. Verify that the server is running.

   • bin / signserver gets a short description of all

7. Set up crypto token

   • bin / signserver setproperties doc / sample-configs / keystore-crypto-configuration.properties
   • reboot bin / signserver 1
   • bin / signserver gets a short description of all

8. Set Sample Timestamp Signature

   • bin / signserver setproperties doc / sample-configs / qs_timestamp_configuration.properties
   • reboot bin / signserver 2
   • bin / signserver gets a short description of all

9. Check signature time

   • timestamp bin / signclient http: // localhost: 8080 / signserver / process? workerName = TimeStampSigner

Answer 4

Assuming you want this for testing, if you are happy to use signtool.exe with the / tr switch, you do not need to look at the RFC, because openssl implements enough for you. Just write the HTTP POST handler in your favorite language, pass the published data to "openssl ts -reply" verbatim, send the TS response data from openssl. This is good enough to trick "signtool.exe verify / pa" even if it is not strictly RFC compliant.

EDIT: It seems the open source Java Signserver project provides the server with MSauthenticode (/ t) and rfc3161 (/ tr) handle processing out of the box. The Signserver configuration included too many dependencies for me, so I instead cracked its unit test to timestamp MSAuthenticode attached on a small HTTP server to the test script, and with a little work - my Java skills are mediocre on average - have a valid script timestamp server for development, and confirmed that the timestamps created in this way are not affected by this problem . I cannot release the source code, however after this tip you need something to work pretty quickly.