Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Code signing for programs

  1. #1

    Code signing for programs

    I remember @paulstoffregen writing somewhere that he used ksoftware.net to buy certificates for code signing. I emailed him about it and he told me to post it here for a writeup that can help everyone.

    So the mic is yours Paul, how do you sign your programs with the certificate you buy from ksoftware.net?

    Thanks!

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,799
    Everything in this message is about signing for Microsoft Windows. Apple has a similar system for MacOS. Unlike Apple, for Microsoft delegates all the certificate stuff to 3rd party certificate authority companies, so you don't end up dealing with Microsoft at all (other than perhaps actually using Windows, but it's possible to do it all on Linux with open source software, which is the path I use).

    The first step is to obtain a code signing cert. I buy from K Software. Ultimately the cert is issued by Sectigo of Comodo. You can buy directly from Comodo or about half a dozen other certificate authorities that Microsoft trusts, but that costs a lot more than getting it through a reseller like K Software.

    The cheaper OV cert is fine. OV certs can be used to sign INF "drivers". You only need the expensive EV cert if publishing actual executable driver code like a .SYS file. If only creating a .CAT file for a .INF, the OV cert is enough. Of course OV also works for signing ordinary .EXE programs.

    I don't buy this very often and I always buy the longest available term so I don't have to mess with it again for a while. Seems like every time the process is different. Sometimes a very specific browser has been needed, to the point of installing a specific version of Windows. K Software is by far the best place I've found that keeps the instructions up to date. It's absolutely an arbitrary process dictated by whatever Comodo / Sectigo do. Ultimately, you'll create a private key and use it to send a certificate request by following the instructions.

    Theoretically Comodo / Sectigo is supposed to verify your identity. Again, what they will actually do seems to vary. Often renewal is just a rubber stamp operation (but costs the same). They might make an automated phone call. It seems to change every time.

    Ultimately they will send you the cert. How it's delivered has differed. Sometimes they've emailed the file. Other times it's been downloaded to a browser and you have to export it. The key used to create the request also needs to be exported. K Software has details about how to export. I don't recall the details, other than it seems to change every few years when I renew again. There's always some amount of having to relearn the process all over again every time...

    Once the process is complete, you should end up with a key+cert in P12 or PEM format, which may or may not (but usually is) encrypted with a pass phrase.

    To actually use your key+cert to sign Windows EXE files, you'll need special software. I personally use an open source command line tool called osslsigncode. You can get it here:

    https://github.com/mtrojnar/osslsigncode

    If you want to sign Windows EXE files on a Linux system (as I do), osslsigncode is probably the best way. Ubuntu and others have osslsigncode as a package you can install.

    K Software has a Windows-only GUI program and tutorials about how to use it. I haven't tried it.

    Microsoft has a command line tool, and they probably have support for it in their GUI IDEs, but I don't use those tools (and I really don't use Windows much).

    One small detail that might come up is which hash algorithm to use. Modern versions of Windows require SHA256. But Windows XP only understands SHA1. You can sign a EXE with both by running osslsigncode twice, with "-nest" for the 2nd run which adds the SHA256 signature. This is the only way I've found to publish an EXE file which is accepted by Windows XP, Vista, 7, 8, 10, 11.

    Signing usually involves obtaining a timestamp from the certificate authority (Comodo). Internet connectivity is required. If you skip this part, you can still create a signed EXE that Windows will accept, but only if the PC's clock is set within the range your certificate is valid. After your cert expires, Windows will only accept signatures you created if they were made with a timestamp.

    Actually running osslsigncode is conceptually pretty straightforward, but ends up involving a pretty good number of command line parameters. Here's a little script which rolls all that up into a neat little package for the common case of signing a Windows EXE file.

    Code:
    #! /bin/bash
      
    # sudo apt-get install osslsigncode
    
    KEY_P12=~/Documents/mycodesigncertkey.p12
    KEY_PASS="mysupersecretpassphrase"
    KEY_TS1="http://timestamp.comodoca.com"
    KEY_TS2="http://timestamp.comodoca.com?td=sha256"
    
    [ -f $1 ] || exit 1;
    
    cp $1 $1.sign0 || exit 1
    echo "Signing $1 with SHA1"
    osslsigncode sign -h sha1 -pkcs12 $KEY_P12 -pass $KEY_PASS -t $KEY_TS1 -in $1.sign0 -out $1.sign1 || exit 1
    echo "Signing $1 with SHA2"
    osslsigncode sign -h sha2 -nest -pkcs12 $KEY_P12 -pass $KEY_PASS -ts $KEY_TS2 -in $1.sign1 -out $1.sign2 || exit 1
    cp $1.sign2 $1 || exit 1
    
    exit 0
    Last edited by PaulStoffregen; 09-21-2022 at 10:29 AM.

  3. #3
    Thank you Paul, I will try this tutorial with the Linux variant.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •