Jarsigner alias parameter with Azure Trusted Signing

[cascoli-athena]

Hi folks...I'm new here to the forum so bear with me if i'm not asking the question in the right spot!

I'm trying to setup code signing using jarsigner, jsign#-#.jar and Azure Trusted Signing. I already have ATS working using the std Windows based tools (signtool.exe) so i know code signing works with ATS that way. I've got things setup (pretty much) to use jarsigner along with jsign7-4.jar behind the scenes to digitally sign a jar file.

Cmd I'm using:

---

jarsigner -tsa "http://timestamp.acs.microsoft.com" -tsadigestalg SHA-256 -sigalg SHA256withRSA -digestalg SHA-256 -J-cp -Jjsign-7.4.jar -J--add-modules -Jjava.sql -providerClass net.jsign.jca.JsignJcaProvider -providerArg "xxx.codesigning.azure.net" -keystore NONE
-storetype TRUSTEDSIGNING -storepass "" -signedjar "signed/mylib.jar" "unsigned/mylib.jar" trustedsigningaccount/accountlogin

I get the following error:
Error: jarsigner: Certificate chain not found for: xxxxxx/yyyyyy. xxxxxxx/yyyyy must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

It's the whole "alias" piece i'm a bit lost on. xxxxxx = ATS code signing acct name and yyyyyy = certificate profile name

1. Are these the correct values that should be used? In the windows based ATS signing, i have a metadata.json file that has these two values so i assume that's what java is looking for when i put in the alias value of xxxxxx/yyyyyy
2. My understanding is that jarsigner will look in my cacerts file for "something" that matches the xxxxxxx/yyyyyy somehow? And because it's not in there, that's where the error is coming from? I DID import the Microsoft Identity Verification Root Certificate Authority 2020.crt file thinking that was the issue but then saw that it throws a different error for that piece. Is there something special that i need to have in my cacerts file for java to know that a storetype of TRUSTEDSIGNING and my alias of xxxxxx/yyyyyy should match up somehow?
3. I also saw a reference to the potential of the jarsigner command needing -certchain in order to have the correct chain of certs path for the code signing cert, root and intermediate certs, etc....so not sure if that's in play here either.

I feel like i'm close but just missing the concept behind the alias xxxxxx/yyyyy piece. Any help would be greatly appreciated. Thanks!!!

[ebourg]

Did you manage to sign a .exe file with your Azure Trusted Signing account but using Jsign instead of signtool? At first glance the syntax looks correct, but even if you figure out what is wrong wou'll hit a wall because the Azure root certificate isn't supported by the JDK, so the signature verification of your jar files will fail.

[cascoli-athena]

No i hadn't actually tried that. I was just googling through the net to see if others were able to use ATS to digitally sign jar files but using other mechanisms that would somehow integrate with ATS. It does look like others were able to make it work somehow using jarsigner and jsign in the background but I just don't understand how the whole "alias" piece works. But you're saying the JDK won't recognize the Azure Root Certificate at all even if i were able to get it imported into cacerts file?

[ebourg]

It will work if you import the Azure root certificate into cacerts.

[cascoli-athena]

Ok...i'll try to give that a whirl. Azure Trusted Signing is funny because the signing certs have a lifespan of like 3 days. I'll need to figure out how to export the certificates out of Azure for the root (to go into cacerts) but probably also the code signing cert. I presume the codee signing cert will have to be exported on the fly since you can't export it once and have it work for the entire year, etc. Thanks for the help!!!

[ebourg]

No need to import the code signing certificate into cacerts, only the root and intermediate certificates.

[cascoli-athena]

Even better! Cuz trying to import that daily rotating cert sounded like a pain. Thanks!!!