Sign ArcGIS Pro AddInX's With Certificate Stored On Hardware Token

[sgn_GSI]

I have traditionally used a DigiCert trusted certificate stored on my local machine to sign any ArcGIS Pro AddIns.

However, as of June 1st 2023, it looks like the Certificate Authority/Browser Forum has set new baseline requirements that all Commercial Certification Authorities must follow. The main requirement posing an issue is the following:

“all code signing certificate keys must be stored on a hardware security module or token that’s certified as FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent.”

From my experience of using the ArcGISSignAddIn utility and reading all of the documentation I can find, it looks like the certificate used for signing must be installed on the local machine.  Has anyone had success using a certificate stored on a hardware token to sign an AddIn?

DigiCert also offers the option to store the certificate on their "KeyLocker cloud storage". Has anyone had success signing an AddIn with a certificate stored on the Keylocker cloud storage?

Esri Documentation Sources:

https://support.esri.com/en-us/knowledge-base/how-to-digitally-sign-an-arcmap-addin-000014993#:~:tex...

https://github.com/Esri/arcgis-pro-sdk/wiki/ProGuide-Digitally-signed-add-ins-and-configurations

[CharlesMacleod]

Does your vendor's USB allow a certificate to be installed to the certificate store on the physical machine to which it is attached? As i understand it, (disclaimer on "understand"!) some vendors drivers support this (eg YubiKey - https://support.yubico.com/hc/en-us/articles/360016614840-Code-Signing-with-the-YubiKey-on-Windows) ....double-clicking  ArcGISSignAddin.exe invokes the UI allowing u to select the certificate from the store (with the USB token present) but to sign wld require the PIN or password for the USB (which is what protects the private key).....does your vendor's USB support this workflow?

[sgn_GSI]

We have used DigiCert in the past. I can't find any documentation for DigiCert or YubiKey that mentions the ability to install the certificate from the hardware token onto the local machine. From my understanding,  that would defeat the whole purpose of the new requirement imposed by the CA/B.

Has Esri acknowledged this new requirement and modified the ArcGISSignAddIn.exe to allow the ability to read a certificate off a hardware token?

[CharlesMacleod]

> that would defeat the whole purpose of the new requirement imposed by the CA/B.

I dont think so. the certificate in the store (read from the USB by the OS) wld be without the private keys (unlike w/ the old spec).

For YubiKey specifically, I believe it provides a smart card minidriver that the Microsoft crypto api loads when it encounters, in this case, a YubiKey. The certificate (in the store) from the USB, and -without- the private keys - has an associated cryptographic provider that gets called (by the api)  to compute the signature. This triggers the whole PIN/pwd prompt to protect access to the private key - which is on the USB - and is required to complete the signing process. Obviously the USB must be present or signing fails.

ArcGISSignAddin.exe is just a wrapper on top of the windows crypto api and shld just work. There's no external change to the crypto api afaik. yes we are looking at this.

[sgn_GSI]

Thank you very much for the explanation. My main concern was whether or not the certificate on the USB was accessible from the user certificate store on the local machine. I have proceeded with getting a DigiCert hardware token and a renewed certificate.

[sgn_GSI · Accepted solution]

For anyone following up, I was able to successfully sign an AddInX using a certificate issued by DigiCert on the hardware token they directly sell.

[CharlesMacleod]

awesome. tks for updating the post

[CharlesMacleod]

@sgn_GSI i did a quick scan of DigiCert's web site for KeyLocker: https://knowledge.digicert.com/solution/digicert-keylocker

Sounds like KeyLocker performs in the same role as the USB token - as in, KeyLocker wld hold the private keys but in the cloud. Note step 9: "Your certificate is issued and associated with the key generated and stored in KeyLocker"...

so probably a similar workflow as with a USB - once u sign up w/KeyLocker, they say u get a certificate without private keys that u then use for signing (I assume it goes in the store? same as w a USB) and the actual request for the private key during signing wld most likely trigger the call to the KeyLocker?

The designated "KeyLocker lead" is, I guess, whoever has the password allowing sign in to the KeyLocker (step 10) and who, presumably, is responsible for the signing.

Looks like they charge u for each signing (in batches of 1000) tho rather than a one time purchase cost of a USB based token or similar hardware device (w/ unlimited use until the certificate expires). However, there is the convenience of not needing a physical USB or smart card or other device.

Obviously, with these new workflows, automated signing/unattended signing is prob going to be a problem as signing cld require a pwd/PIN each time (whether KeyLocker or USB). With KeyLocker it sounds like u have to be careful too if u r running multiple builds w/signing as u cld quicky burn through your 1000 signings limit.

[sgn_GSI]

I had looked into the KeyLocker option but I came across this community post from not too long ago.

https://community.esri.com/t5/arcgis-pro-sdk-questions/arcgissignaddin-exe-receives-quot-internal/m-...

It looks like the ArcGISSignAddIn utility tool is not handling the KSP correctly. The limitation of only 1000 signings is a bit concerning if I were to automate signing each release build. The hardware token seems to be the better approach for the time being. Thanks again for all of your help.