Jarsigner parameters with Azure Trusted Signing

[frnds1]

After various combinations of parameter values to sign a .jar with jarsigner and Azure Trusted Signing service with various errors I was hoping to get a clarity on the required values.

For example:

jarsigner --debug -J-cp -Jjsign-6.0.jar -J--add-modules -Jjava.sql \
          -providerClass net.jsign.jca.JsignJcaProvider \
          -providerArg weu.codesigning.azure.net.net \
          -keystore NONE \
          -storepass "{ ... }" \
          -signedjar "C:\signed\mylib.jar" \
           "C:\obfuscated\mylib.jar" \
           trustedsigningaccount/accountlogin

generates:

jarsigner: Certificate chain not found for:  trustedsigningaccount.
trustedsigningaccount must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

Mapping the jsign Azure Trusted Signing params did not work either. For example, using -storetype TRUSTEDSIGNING generates an error.

[ebourg]

Hi, Azure Trusted Signing support will be in Jsign 7.0 which hasn't been released yet, but you can use the development snapshot:

https://github.com/ebourg/jsign/actions/runs/12225169009/artifacts/2290985972

[frnds1]

Thank you. Sigh. Yes. Forgot token time limit. Exe signing worked however, I had to change the storepass value to access token only instead of the full JSON string.

When I use the same parameter values for the jar signing format (including --debug), now the output is:
loadProviderByClass: net.jsign.jca.JsignJcaProvider
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
at java.base/sun.security.validator.Validator.validate(Validator.java:264)
at java.base/sun.security.validator.Validator.validate(Validator.java:231)
at jdk.jartool/sun.security.tools.jarsigner.Main.validateCertChain(Main.java:2435)
at jdk.jartool/sun.security.tools.jarsigner.Main.certsAndTSInfo(Main.java:2081)
at jdk.jartool/sun.security.tools.jarsigner.Main.signJar(Main.java:1968)
at jdk.jartool/sun.security.tools.jarsigner.Main.run(Main.java:288)
at jdk.jartool/sun.security.tools.jarsigner.Main.main(Main.java:133)
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
... 8 more
jar signed.

Warning:
The signer's certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The signer certificate will expire within six months.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2024-12-15).

Verify results in the jar signed message with the warning like above.

[frnds1]

Is there another test I can run or change parameters in a way to avoid this issue? Or is does this issue have to do with the difference of Azure Trusted Signing certificate differences?

[ebourg]

You probably have to add the Azure root certificate to the JDK keystore.

[frnds1]

Thank you. I am testing the new 7.0 jar. Do I need to build a jar with the jca and/or the store jar?

[ebourg]

No need to build a jar file, you can download it from the release page

[frnds1]

Thank you. But now I get an old error message:
jarsigner: Certificate chain not found for: account/profile. account/profile must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain.

[ebourg]

Are you sure the authentication token used is valid? Try signing an .exe file with Jsign and the same token, if there is a problem you should get a meaningful error message.

[frnds1]

Thank you. You are correct. I thought the test case ran within the 2hr window, but it was just after. With new token, I'm back to the prerelease results:
jar signed.

Warning:
The signer's certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The signer certificate will expire within six months.
No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2024-12-15).

I was unclear about Azure root certificate to the JDK keystore process.

[ebourg]

Now you have to import the Microsoft Identity Verification Root Certificate Authority 2020 certificate in the JRE truststore:

keytool -importcert -alias microsoft-identity-root-ca -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file "Microsoft Identity Verification Root Certificate Authority 2020.crt"

[frnds1]

Thank you. After more testing I see that specifying the digest algorithm doesn't seem to impact the error:

Signature algorithm: SHA384withRSA, 4096-bit key
[certificate is valid from 4/16/20, 11:36 AM to 4/16/45, 11:44 AM]
[Invalid certificate chain: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

Jarsigner doc says 384 is the default. But if I specify: -sigalg SHA256withRSA -digestalg SHA-256 there is no difference in the result. If I specify a timestamp it generates the same SHA384withRSA invalid certificate chain error whether I specify -tsadigestalg SHA-256 or not.

Jarsigner doc says it relies on the providerclass if you specify an algorithm. Is there a way to validate the signing request as it appears to be fixated on 384.

[ebourg]

[certificate is valid from 4/16/20, 11:36 AM to 4/16/45, 11:44 AM]

This is the validity range of the Microsoft Identity Verification Root Certificate Authority 2020 certificate. I think you are confusing the signature generated by jarsigner with the signature of the Microsoft Identity Verification Root Certificate Authority 2020 certificate, which is indeed SHA384withRSA and will never change.

[frnds1]

Thank you. I saw the doc reference and it triggered the question. I ran verify to validate the requested digest was used each time. The concern is the keytool import is a logistical issue for us with access to all the build systems (images) that may be impacted.

Why is this issue unique to jarsigner and trusted signing? It doesn't happen with jsign/exe trusted signing and other signtools with trusted signing. It doesn't happen with jarsigner and other certificate issuers.

[ebourg]

This is specific to jarsigner with Azure Trusted Signing because the root certificate used is not in the JDK truststore (nor cross signed by a root certificate in the truststore).

I've opened a PR to suggest the addition of the Microsoft Identity Verification Root Certificate Authority 2020 certificate to the JDK truststore:

openjdk/jdk#23360

[frnds1]

I meant to confirm the cert import does correct the signing issue. The reason for all the questions is that the more I can internally document the issues now, the better the chances are of explaining what is required downstream. Thank you for all your help.

[dharanitharan-selvaraj]

@frnds1 Could you please share the final command that worked, along with any necessary pre-steps for it to function? Thank you in advance

[frnds1]

Steps we used for signing with jarsigner and jsign with Azure Trusted Signing services:

1. Setup jdk keystore to see Microsoft Root Certificate:

• Download Microsoft Identity Verification Root Certificate Authority 2020.crt
• Copy certificate to C:\Program Files\Java\jdk-xx\lib\security
• Import the certificate with:
  keytool -importcert -alias microsoft-identity-root-ca -keystore "C:/Program Files/Java/jdk-xx/jre/lib/security/cacerts -storepass changeit -file "Microsoft Identity Verification Root Certificate Authority 2020.crt"

2. Get the access token for Azure Trusted Signing services:

• Install Microsoft Azure CLI if not already installed
• Run Windows PowerShell
• Login to Azure (it will prompt for sign in verification):
  powershell>az login
• Once logged in, get access token:
  powershell>az account get-access-token --resource https://codesigning.azure.net

3. Note the expiresOn value from the returned JSON string that gives you approximately 2 hours.

4. Copy the accessToken value from the returned JSON string to your jarsigner command(s)

5. Sign the jar file:
   jarsigner -tsa "http://timestamp.acs.microsoft.com" -tsadigestalg SHA-256 -sigalg SHA256withRSA -digestalg SHA-256 -J-cp -Jjsign-7.0.jar -J--add-modules -Jjava.sql -providerClass net.jsign.jca.JsignJcaProvider -providerArg "xxx.codesigning.azure.net" -keystore NONE -storetype TRUSTEDSIGNING -storepass "pasted-accessToken-value-from-JSON-string" -signedjar "outpath\signed\mylib.jar" "inpath\tobesigned\mylib.jar" trustedsigningaccount/accountlogin

[ArlindoARodrigues]

Hi @ebourg , first of all sorry by my poor english, nice to meet you.. I have tried to sign my jar files, I have used this parameters:

jarsigner -tsa "http://timestamp.acs.microsoft.com" \
          -tsadigestalg SHA-256 -sigalg SHA256withRSA \
          -digestalg SHA-256 \
          -J-cp -Jjsign-7.0.jar -J--add-modules -Jjava.sql \
          -providerClass net.jsign.jca.JsignJcaProvider \
          -providerArg "eus.codesigning.azure.net" \
          -keystore NONE \
          -storetype TRUSTEDSIGNING \
          -storepass %token% \
          -signedjar teste.jar app.jar TSALINXSA/LinxCodeSigning

and I got this result:

jar signed.

Warning:
The signer's certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The TSA certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The timestamp will expire within one year on 2025-11-19.
POSIX file permission and/or symlink attributes detected. These attributes are ignored when signing and are not protected by the signature.

The signer certificate will expire on 2025-02-28.

the new suposted signed file was created but I don see the signature in properties, what I was missed out? Can you help me?

[ebourg]

@rsbvntcoder Your error looks more like an outdated JRE/JDK. Type java -version to see the version used.

[rsbvntcoder]

Just like I thought there is no JRE or JDK installed, there is no java runtime on my system. I did not see it was required for JSign. Is that required for JSign to work?
"The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java."

[rsbvntcoder]

I have installed the latest version of JDK available to us through self-service which is 17 and I tried it again but got the same error.

[ebourg]

What do you get when you type java -version ?

[rsbvntcoder]

Java(TM) SE Runtime Environment (build 17.0.12+8-LTS-286)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.12+8-LTS-286, mixed mode, sharing)