Symptom
Using the FDI Package signing tool (stand alone or integrated with FDI Package IDE), the digital certificate that was purchased and installed on the machine is not listed. You are unable to sign the FDI Package.
Solution
First, make sure you are using the most recent version of the FDI Package signing tool.
See FDI Package Signing Tool - A Free Utility for Members
If the certificate is available in the certificate store, but does not show up in the FDI Package signing tool, the most common reason is that the private key is not available for signing.
The test for this is easy.
From the certificate store, you can open the certificate by simple opening the code signing certificate. For example, double clicking on the certificate from the Personal certificate store.
See Finding your digital certificate
If the key IS shown as above, then this article does not apply. Please contact us so we can further troubleshoot.
If the key isn't shown (the text shown in the red box is missing), then the private key isn't installed and therefore you cannot sign the FDI Package.
Now, if the key isn't there, how does this get fixed? Well, that depends on how the certificate was originally obtained.
When someone obtains a digital signing certificate, they key is ALWAYS generated by the original requester. The Certificate Authorities (CA) (like Digikey, Sectigo, etc), NEVER has the private key. They all work this way. This means you cannot go to the CA to get the key. They don't have it. They did not send it to you. They cannot send it to you.
Here are some possibilities:
1. This method is no longer supported by most Certificate Authorities. The most common way is that the key is generated on the machine that requests the certificate. But, It's not in a file. The key is protected in the certificate store of that machine that generated it. One option is to to run the FDI signing tool on the original computer that obtained the code signing certificate. It is also possible to EXPORT the certificate and key from the original computer to another computer. And, when exporting, you MUST export the private key. It will be an option.
Here are some instructions for exporting and then re-importing a certificate with private key to another machine:
https://support.globalsign.com/ssl/ssl-certificates-installation/import-and-export-certificate-microsoft-windows
These directions are the same, no matter which CA is used. I must give caution when exporting the private key. Use a temporary, strong password when exporting and then re-importing. After that, throw away that password and delete the exported file. Do not email an exported certificate with private key. Treat the exported file like a credit card number. It's only used for that one time you transfer private keys.
Private keys are the secrets that must NEVER be shared. If private keys are mistakenly shared, you must revoke the digital certificate with the CA. This will cause all FDI Package that were signed (even in the past) with this certificate to fail future validation. We cannot emphasise this enough. You must protect your private key. FieldComm Group recommends using eTokens to protect private keys.
2. A second, and most common (and recommended) method today is that a key is generate is using a usb token. While it looks like a standard usb memory stick, these usb tokens actually have a mini application that securely protects the private key. Safenet eTokens are common but other manufacturer make them as well. If this is the case, the important thing to know is that the USB token must be connected to the computer to sign the package. These tokens, by design, do no export the private key. Using these tokens typically require 3rd party software, installed on the signing pc. SafeNet authentication client is common, and the software is typically provided by the CA when the digital certificate is provided. Make sure the client is installed and the USB token is inserted. Tokens are protected with a PIN so you will need that to unlock the token. A pin prompt window will appear during the signing process. FieldComm Group always uses eTokens for signing packages and applications.
Here are some instructions for exporting and then re-importing a certificate with private key to another machine:
https://support.globalsign.com/ssl/ssl-certificates-installation/import-and-export-certificate-microsoft-windows
These directions are the same, no matter which CA is used. I must give caution when exporting the private key. Use a temporary, strong password when exporting and then re-importing. After that, throw away that password and delete the exported file. Do not email an exported certificate with private key. Treat the exported file like a credit card number. It's only used for that one time you transfer private keys.
Private keys are the secrets that must NEVER be shared. If private keys are mistakenly shared, you must revoke the digital certificate with the CA. This will cause all FDI Package that were signed (even in the past) with this certificate to fail future validation. We cannot emphasise this enough. You must protect your private key. FieldComm Group recommends using eTokens to protect private keys.
2. A second, and most common (and recommended) method today is that a key is generate is using a usb token. While it looks like a standard usb memory stick, these usb tokens actually have a mini application that securely protects the private key. Safenet eTokens are common but other manufacturer make them as well. If this is the case, the important thing to know is that the USB token must be connected to the computer to sign the package. These tokens, by design, do no export the private key. Using these tokens typically require 3rd party software, installed on the signing pc. SafeNet authentication client is common, and the software is typically provided by the CA when the digital certificate is provided. Make sure the client is installed and the USB token is inserted. Tokens are protected with a PIN so you will need that to unlock the token. A pin prompt window will appear during the signing process. FieldComm Group always uses eTokens for signing packages and applications.
Example eToken (might look different)
Example Safenet Client Application. In this example, the eToken for FDI Package Signing is plugged into the signing computer. Your token may have a different name.
3. A third, and probably even less common, is using an HSM. To oversimplify, think of an HSM is a more complicated usb token with a lot more features. More than likely, these work over a network. Using these to sign FDI Packages may work, but support for this is not available due to the complexity of the client configuration. An HSM will require IT support on your side. That said, the libraries used in the FDI Package to sign are the same libraries that Microsoft calls in their native (non-cloud) signtool. So, if the HSM is compatible with the native Microsoft Signtool, then it may be compatible with the FDI Package signing tool. But, FCG cannot offer support for this use case.
4. Many Certificate Authorities are now offering cloud based signing using their own web apps and APIs. An example of this is DigiCert's KeyLocker. Sometimes these are referred to as a Cloud HSM. Generally, these are not supported. FDI Package signing is not compatible with Azure KeyVault.