How to create a Software Publisher Certificate for internal use from a CA

Not that I am suggesting that there is any conspiracy to make money from hapless IT departments wishing to sign their internal applications, but...

Apart from purchasing a Software Publishing Certificate (SPC) from a commercial and recognised issuer there is a way to create a SPC using free tools and the PKI infrastructure in your organisation. This does have the disadvantage that you can only verify the application on PCs that have your organisation's root certificate installed in the Trusted Root Certificate Authorities partition. An easy thing to do with Group Policy, and also possible for non-domain computers that really require it without heavy lifting.

Whey would you want to do this? Anyone wanting to distribute custom applications or custom installers can now distribute their internally compiled software without reducing security levels. Want users to install an application on Vista or Windows 7 from the control panel when they need it? If it is not signed, it will not happen without a certificate.

So, how to do it? Requirements: An Enterprise CA (running on Windows Server 2008 Enterprise - important as you need to manage certificate templates - not possible on Standard editions,) OpenSSL, PVK from Code Sign here, and Microsoft Platform SDK (which, if you are developing, one assumes you are using.)

Another thing you need to identify is what you want to appear when you install an application and the UAC pops up. Typically, you will wnat your users to identify you as the source of the software, so somehting like "Company Name IT Department." I will refer to this later as "your certificate name."

On your CA you will need to right click Certificate Template and select Manage. In the templates Console you will need to create a code signing template. For our purposes I created a 2008 Enterprise Certificate with the extended purpose of Code Signing. Under request handling, "Allow private key to be exported" MUST be ticked. Under Subject Name ensure "Supply in the request" is set. Under Issuance Requirements ensure "CA certificate manage approval" is ticked. Click OK and close the Template Console.

In the CA Manager, right click Certificate Templates and select new -> Certificate template to issue. Select your newly created template.

Open a command prompt and run certmgr to open the certificate manager for the user account. Right click personal and select All tasks -> Request new certificate. Click next until you see a list of certificates you can enrol for. You should now see your new certificate template with a warning "More information is required..." (because you selected the "Supply in the request" option.) Tick this certificate template, expand and click on Properties. In the Subject tab, select "Common Name" from the drop down list and enter your certificate name as noted above. Click Add. You may want to identify this certificate later by added a friendly name and description under the general tab. When finished, click OK. Click on Enroll and you should be told that the request is pending.

In the CA Manager, note the Request ID (important for later) and approve the request. We are not finished with the CA Manager yet...

In certmgr, refresh the tree and you will have a Certificate Enrollment Requests branch. Expand this to find a certificate with issued to "your certificate name" (as noted above) and issued by "your certificate name" with a private key, specifying a password. This is practically useless, but we need to to get the Private Key. Export the certificate with the private key to a pfx file. Use openssl to extract the private key to a PEM file:

openssl pkcs12 -in filename.pfx -nocerts -nodes -out filename.pem

This extracts the key after specifying the password noted above. The certificate is useless to us, so once you have the PEM file, you can practically dispose of this certificate. Now you need to convert the PEM to a PVK file.

pvk -in filename.pem -topvk -out filename.pck

You will be asked to specify a new password for the private key and to re key it to verify. This password will be needed later to sign installers - so remember it.

Because of the bug in the certificate (it being issued by itself and therefore untrusted) you now need to retrieve the certificate from the CA. In CA Manager, go to Issued Certificates and list them in Request ID order. Find the Request ID (noted when you approved the request) and double click the request to view the certificate details. Note that this version of the certificate has no private key and is issued to "Your certificate name" but is correctly issued by your CA. This is what we want. On the details tab, click the "Copy to File" button to begin the export wizard. Save the certificate as a DER X.509 certificate with a .spc extension. (A .cer extension will do, but for the purposes of identifying this file later, let's just give it .spc)

Okay you now have a .spc certificate with code signing extensions, and a .pvk file that corresponds to the .spc certificate. In order to turn this into something useful, you now need to use the Platform SDK Tools:

pvk2pfx.exe -pvk filename.pvk -pi password -spc filename.spc -pfx newfilename.pfx -po password

The password corresponds to the important password you noted when creating the pvk file. I would keep the second password the same. If you import this pfx file you will now have the correct certificate, with the correct extension, subject and issued by, for signing your installers.

Finally, for ease of use, I use Tech-Pro's codesign from within Visual Studio's tools menu to do all my signing (because it works.) Of course you may use signtool and the command line or any other method using this certificate. Now all my installers are signed and can be used within the organisation without the need to reduce security AND I can continue to distribute them via active directory just as I do with commercial applications.