Coffeehouse Thread

8 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Authenticode, time stamping, and infinity

Back to Forum: Coffeehouse
  • User profile image
    davewill

    From what I'm reading it seems that authenticode code signing certificates all have some sort of expiration date.  The reason mentioned mostly seems to be related to certificate authorities wanting to "end the books" so to speak on a given transaction (i.e. so it isn't carried on forever).  Timestamping the signed bits after signing the bits somehow makes the bits continue to pass validation beyond the expiration date.

    Eric Law wrote a great blog post that summed up several hours of research.  http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx

    What are the mechanics of timestamping during validation?  Does Windows make a call to the timestamp server noted in the bits?  Would an isolated signed set of bits fail validation if it had no network access to the timeserver (ever)?

  • User profile image
    Sven Groot

    No, you don't need an Internet connection to validate the signature. Windows never checks with the timestamping server.

    Basically, when you sign an executable and use a timestamp, the CA countersigns your signature along with the date the executable was signed. That countersignature was created using a certificate belonging to the CA, which Windows trusts. It is a guarantee by the CA that the certificate used to sign the executable was valid at the time the signing occurs.

    This happens in the same way Windows checks whether it trusts the certificate in the first place: by checking the list of trusted root certificates. Windows does use the Internet to check if any of the certificates used have been revoked in the mean time, and if you don't have an Internet connection there is a chance that a revoked signature could be deemed valid incorrectly, but that's unavoidable.

  • User profile image
    l000000l

    @davewill:

    MS Authenticode certificates are no longer used. Today all code is signed with the p12 cert.

    http://en.wikipedia.org/wiki/PKCS12

    The CA timestamp server is pinged on signing, and the computer's clock is used on verification.

    This certificate is standard and can be used by a browser, OpenSSL, Java jarsigner, Adobe Flex packages, Android APKs, Microsoft .exe digital certificates and more.

    You can also create a self-signed P12.

    That countersignature was created using a certificate belonging to the CA, which Windows trusts.

    Each SDK/Platform manufacturer has a list of root certificates as do browsers. So your P12 is likely to work across many different platforms that share those root certificates. This process isn't unique to Windows or Microsoft.

  • User profile image
    davewill

    @Sven Groot: Ahhh.  So the countersign at the timestamp time is the legal binding that allows for the certificate to last until infinity but yet still allow the CA to not carry it on the books until infinity.

    Many thanks.

  • User profile image
    l000000l

    @davewill:

    The X.509 in the P12 does not last for eternity. It has an expiration date.

    http://en.wikipedia.org/wiki/X.509#Sample_X.509_certificates

           Validity   
               Not Before: Jul  9 16:04:02 1998 GMT
               Not After : Jul  9 16:04:02 1999 GMT

  • User profile image
    Sven Groot

    @davewill: Yep. And as you would expect, the CA will not countersign for an expired signature, so while the signature on already signed executable will continue to work after the certificate expires (if timestamping was used), you can no longer use that certificate to create new signatures.

  • User profile image
    davewill

    @Sven Groot: That makes a lot of sense.

  • User profile image
    l000000l

    @davewill:



    Alternatively, you can use the SignTool.exe shipped in the Windows SDK and later versions of the .NET Framework. To use this tool, you'll need to convert your .SPC & .PVK files into a new PFX file, which you can do from a Visual Studio Command prompt:

        pvk2pfx -spc mycert.spc -pvk mykey.pvk -pfx mycert.pfx -pi PVKPassword -po NewPFXPassword

    After that, you can use a script like the following to sign your package:

        set /P PFXPass=Enter PFX Password:
        signtool sign /p %PFXPASS% /f C:\src\mycert.pfx /d "FiddlerCap" /du "http://www.fiddlercap.com/" /t http://timestamp.comodoca.com/authenticode /v FiddlerCap-en.msi
        set PFXPass=blank


    Current syntax for Microsoft is:

    signtool.exe sign /f cert.p12 /p mypass /t http://timestamp.comodoca.com/authenticode my.exe

    Assuming you're using Comodo timestamp server.

    Jarsigner and other tools can be configured directly in Ant or Maven so it's not such a pain.

    CAs have been issuing p12 containers now for at least 2-3 years, so this guy is way out there with his info having written an article like that in 2011.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.