I'm new to code signing and I'm trying to create as secure a process for signing our code as possible. I created a .pfx file by exporting my certificate from IE and created a password for it. I'm able to sign code using the pfx file with the following command:
signtool.exe sign /f mypfx.pfx /p mypass myexetosign.exe
This works fine, so I copied signtool.exe, the pfx file, and a different executable to sign to a USB flash drive. I took the USB flash drive to a second computer and tried the same command again, but this time I get SignTool Error: The specified PFX password is not correct. I'm certain the password is correct. Is there an extra step I'm missing to move this to another machine? My ultimate goal is to do the code signing in an offline static environment.
What I've encountered is that during the export, the encryption of the pfx is SHA256 or 3DES-SHA1.
If importing on a different machine, make sure the same SDK is used, so the same encryption can be used to decrypt.
The error explains this, if you try to decrypt with the wrong encryption, garbage comes out, which could be the result of a wrong password as well
Related stackoverflow question:
Why I get "The specified PFX password is not correct" when trying to sign application with signtool?
Related
I want to sign an Oracle VirtualBox Virtual Appliance, an OVA file. I am looking for instructions.
I have had extensive conversations with Comodo and Sectigo. They don't know how and had trouble even understanding the question.
When I load my VM in VirtualBox it says that it is unsigned but gives no information as to how to correct that.
I have a code signing certificate, and I have no trouble signing and timestamping an executable file:
signtool sign /t http://timestamp.comodoca.com t_hello.exe
Done Adding Additional Store
Successfully signed: t_hello.exe
Attempting with an .ova file gives an error:
signtool sign /t http://timestamp.comodoca.com ACoreTpl.ova
Done Adding Additional Store
SignTool Error: This file format cannot be signed because it is not recognized.
SignTool Error: An error occurred while attempting to sign: ACoreTpl.ova
I took a shot at downloading a tool from VMWare, but it did not work on my VirtualBox appliance. It just gave error messages.
Unless the error message is meaningless and just hardcoded in VirtualBox, there is code inspecting something. I really don't want to go fishing through the code, but at this point it seems like I might have to.
The purpose of this exercise is so that I can publish a working system as a virtual appliance that is 'known good' and can be verified as the real thing when it loads.
[Note: There are images in the document I pasted this from, but they would not paste in here.]
I was able to muddle through a work-around. The workaround involves getting a tool from VMWare (ovftool.exe), which seems a bit strange. It allows the import of the OVA, showing the certificate and marking it as 'safe'. It still has a couple of issues. One is an annoying warning message issued while creating the signed file, for which I was unable to find a cure. The other is that it does not seem to contact a timeserver to timestamp the file. Presumably that means that when the signing certificate expires, you get warnings again when loading.
I would still like to know how you are supposed to do it properly according to Oracle. Surely, Oracle is not using VMWare's software to sign their Virtual Appliances.
This is my journey under Windows 10. At the end, I have a publishable appliance.
You need a virtual appliance (*.ova)
You need a signing certificate.
You need to have OpenSSL installed.
You need the program ovftool.exe from VMWare
To get the .ova file, you need to export one of your VMs as a virtual appliance:
Open the export virtual appliance dialog:
File->Export Appliance [Alternatively E]
Choose the virtual machine to export. Fill in whatever Virtual system settings apply.
For appliance settings, set the Format to Open Virtualization Format 1.0
Make sure the 'Write Manifest file' checkbox is checked.
Click on the button to write file.
You should have the signing certificate installed in the certificate store. If you don't have this already, you need to consult your certificate provider.
To get the signing certificate in a usable form, you have to jump through a few hoops to get an old-timey Privacy Enhanced Mail (PEM) file.
You need to get the certificate into a file first.
Start the Certificate Manager by running certmgr.msc
Open Personal->Certificates and right-click on your signing certificate
Open the All tasks menu and choose Export
This should open the Certificate Export Wizard
Click [Next]
Choose the radio button marked "Yes, export the private key"
Click [Next]
Choose "Personal Information Exchange - PKCS (.PFX)"
Check "Include all certificates in the certification path if possible"
Check "Export all extended properties"
Check "Enable certificate privacy"
Click [Next]
Check the Password checkbox, and enter and confirm a password [using password "IMPPass" in this example]
Change the Encryption dropdown to AES256-SHA256
Click [Next]
Assign the filename and path for the exported certificate. In this example, I called it "MyCert". Note that you don't put the file extension on the name here. The Certificate Export Wizard adds it when it writes the file. You should save it on the path where you saved the OVA file.
Click [Next]
Review settings and Click
It should pop up a message box saying the export was successful. Dismiss it by clicking on the button.
You need to do the next steps at the command line.
Open a console window.
Change to the directory where you have saved your OVA and PFX files.
cd c:<yoursavelocation>
You now need to convert the certificate to a form that can be used (.pem). To do this, you need to use OpenSSL. Here is the form of the command:
openssl pkcs12 -in MyCert.pfx -out MyCert.pem
Respond to the prompts for Import Password and PEM pass phrase:
Enter Import Password: IMPPass
Enter PEM pass phrase: PEMPass
Verifying - Enter PEM pass phrase: PEMPass
Finally, you can sign the exported OVA with ovftool with a command like this:
ovftool --privateKey=MyCert.pem --shaAlgorithm=SHA1 DamnSmall.ova DSL.ova
Opening OVA source: DamnSmall.ova
Opening OVA target: DSL.ova
Writing OVA package: DSL.ova
Transfer Completed
The manifest validates
Enter passphrase for MyCert.pem: PEMPass
A warning is issued here, but it will not interfere with the signing.
Warning:
No supported manifest(sha1, sha256, sha512) entry found for: 'DamnSmall-disk001.vmdk'.
Completed successfully
At this point, there should be a signed file called DSL.ova. It will indicate that when imported in VirtualBox.
To test, import the newly created and signed OVA file. Open the import dialog:
File->Import Appliance or alternatively I
Enter the path and name of the signed Virtual Appliance.
Click [Next]
The Appliance settings dialog should have text in the bottom left corner indicating that you have signed the appliance, and that it is trusted.
Appliance is signed
I am trying to run certutil -repairstore and keep getting prompted for a smart card. This is a VM on AWS and a smart card is not an option. Any thoughts on how to bypass the smart card and get the repair to complete are appreciated
One of the other answers touched on it, but I wanted to add some context/detail as well as I spent a lot of time searching for the root of this problem. Killing the smart card-related services did not work, nor did disabling the related policy with gpedit.
When you run certutil with the -repairstore option, Windows runs through its list of CSPs (Configuration Service Providers), one of which is the "Microsoft Smart Card Key Storage Provider" - that's the one that causes the prompt to enter your smart card. As the above answer stated, the most likely cause is that you are attempting to install a certificate file (.crt, .cer, .pem, etc.) that does not have a corresponding key on the VM, so Windows is cycling through the various CSPs looking for a valid key but cannot find one. There are two possible solutions to this problem:
You should generate your CSR (Certificate Signing Request) through IIS > Server Certificates > Create Certificate Request. This will ensure that the key is generated locally and the appropriate key store is aware of it. Use that CSR to get your certificate from GoDaddy or whoever your provider is, then you should be able to go to IIS > Server Certificates > Complete Certificate Request to install the certificate and avoid certutil altogether.
If you still can't get it to work and are sure the key was generated locally, the -csp option for certutil will allow you to specify which CSP to use when validating the certificate thereby eliminating the need for Windows to try the smart card CSP. You can get the installed CSPs on your system by running certutil -csplist - the "Provider Name" value is what you pass to certutil. For example, certutil -csp "Microsoft Software Key Storage Provider" -repairstore ... would force certutil to validate against the Microsoft Software Key Storage Provider. Make sure you use quotes since there are spaces in the names.
Make sure you make the original certificate request on the same windows server where the domain is hosted. Then complete the request with the p7b provided by the ssl supplier and you won't have any problems.
This question might be a bit old but I came across this error with another cause:
I have mutliple servers trying to import the certificate.
However, the cert request was generated from one server. In that case, I imported to the original server which create the request and export everything from the mmc (including private key) and re-import the pfx file to the over servers.
Try to add -silent to the command
I and another guy are developing an add-in project for PowerPoint using C# and VSTO. Our project is being kept in a repository and every time when one of us gets a newest version from the repository, updated by another one, he gets a compiler problem with signing. Up to now, we solved this compiler problem by generating a test certificate on the corresponding machine every time after updating from repository.
My question is: Is it possible to avoid somehow this every-time generating of a test certificate after taking the solution, compilable on other machine, from the repository in order to have it compilable on both machines?
We tried everything:
We used the same .pfx file for both of our PC's (i.e. we sent this file to the repository).
We tried to uncheck the checkbox "Sign the ClickOnce Manifest" in the Properties window of the Solution and to remove the .pfx file at all.
We tried to use our own .pfx files with putting them into the ignore list.
But there was no result!
We have a similar scenario and we are doing the following:
'Sign the ClickOnce manifest' is signed with a locally generated .pfx key that is checked into the repository.
The assembly is signed with a strong name key.
On the build server the manifest is re-signed using the company's digital certificate for deployment using the instructions provided in this article - http://blogs.msdn.com/b/vsto/archive/2009/04/29/signing-and-re-signing-manifests-in-clickonce.aspx
Let me answer my own question. The solution is probably found. The steps are the following:
One developer should generate a new .pfx file defining the password. As a result, he can already develop the add-in correctly, on his machine; but other developer still can not, on their machines.
Using the same tab of the project's "Properties" window, this developer has to select the same .pfx file with the "Select from File..." button, giving the password.
The .pfx file should be sent to the repository (i.e. one shouldn't include it into the ignore list). As a result, other developers will not be required to generate anytime other .pfx files anymore.
We are ready!
The "magic" is that knowing the password by all developers is crucial. When the .pfx file is added to the project as it is described in the item 2, it means that all developers know the password.
I need an access to .k12 or .pem files for all https websites I am visiting on Mac OSx machine. Can anyone help me know the path where these files can be found.
Also, need to know a way to decrypt some packets using the key.
There are a couple of ways to get a certificate file in OSX. One way is to export the certificates from Keychain Access. Select Certificates in the Category (lower left) panel, choose Select All from the Edit menu (or hit ⌘A), and then choose Export Items... from the File menu (or hit ⇧⌘E). You can export your certificates as a .p12 file or a .cer file. The problem with this approach is you have to perform these steps periodically to keep your file in sync with the latest updates from Apple.
Another way is to install OpenSSL and use the cert.pem file that comes with it. Similarly, you'll have to keep OpenSSL up to date.
You would simply access the tool named "Keychain Access" in the Utilities folder of your Applications directory.
Once there, you can filter each keychain to only show certificates.
As for decrypting packets using a given key, there are plenty functions doing that within the Security framework, but this question would require clarification (Language requirement etc).
I was looking for this too. I couldn't find the files anywhere so I thought how about exporting them.
From the Keychain Access:
On left pane, click on the KEYS. On right pane, CTRL-Click on the desired certificate.
The Public key should be exported as a PEM file.
The Private Key should be exported as a P12 file.
The Certificate should be exported as a CRT file.
The Private key export option will as for a passphrase and then the user's keychain password. Upon import you will be asked for this passphrase.
NOTE: The private key, contains the public key.
I use Windows XP SP3. I resell digital signature certificates. I get the clients data, key them into a portal and download the dsc onto my machine. I use Internet Options and export the certificate to a pfx file with a password and send it off to the client. Since, this is being done over and over again, during export to pfx, inadvertently the wrong certificate is selected. Once the pfx file is generated, is there any way of knowing the common name in the pfx file without having to reinstall the certificate. I have looked into openssl, but not sure if it can be achieved by a batch file as a password has to be physically entered. Ideally, after exporting say 10 pfx files, I would like to run a batch file which would display only the common names. Once I confirm that the names are correct (I have exported correctly), I can delete the certificates from the store.
You should write your own application, that will perform batch processing of PFX files.
The pseudo code using CryptoAPI are as follows.,
Read the pfx files from disk one by one using PFXImportCertStore. You will get the certificate store context.
Acquire the certificate context PCCERT_CONTEXT phPfxCertCtx = CertEnumCertificatesInStore
Get the subject name. phPfxCertCtx->pCertInfo->Subject
You can have a predefined list of subjects to compare the subject names that are read now.
Close the context and certificate store, CertCloseStore with CERT_CLOSE_STORE_FORCE_FLAG.