Signing a jar file tells me "Failed to load certificate from"

[obones]

Hello,

Following discussion #178, I'm trying to sign a JAR file with a key stored in a Google Cloud HSM, in a Windows environment.
I have thus written the following command in a batch file:

setlocal
@set GOOGLE_TOKEN=file:D:\Path\To\Signature\token

"%JAVA_HOME%\bin\jarsigner" -J-cp -JE:\Downloads\Prog\java\jsign-6.0.jar -J--add-modules -Jjava.sql ^
           -providerClass net.jsign.jca.JsignJcaProvider ^
           -providerArg projects/myproject/locations/europe/keyRings/TheKeyRing ^
           -keystore NONE ^
           -storetype GOOGLECLOUD ^
           -storepass "%GOOGLE_TOKEN%" ^
           -tsa $http://timestamp.entrust.net/TSS/RFC3161sha2TS ^
           -digestalg SHA-256 ^
           -tsadigestalg SHA-256 ^
           -signedjar MyProject.signed.jar ^
           -certchain "D:\Path\With spaces\to\public_key\Certificate_google_cloud.cer" ^
           MyProject.jar ^
           KeyName/cryptoKeyVersions/1 

Where JAVA_HOME points to a java 11.0.24+8 installation.

Sadly, this fails with the following message:

jarsigner error: java.lang.RuntimeException: Failed to load the certificate from

Yes, that's the entire error message, there is nothing after the "from" word.

Looking around here or at large did provide any hint as to what I missed, but to me me it's like there is an empty parameter that I did not provide.

Any help would be greatly appreciated.

[ebourg]

Did you try with the latest snapshot ? https://github.com/ebourg/jsign/actions/runs/10063296846/artifacts/1731567034

[ebourg]

Could you try signing a .exe file with Jsign? If there is a permission issue with the Google account jarsigner may hide it, but Jsign will display more details.

[obones]

I tried and it found an issue with the timestamping server URL where I had an extra $ sign at the front.
I removed it and the exe file was signed just fine. Sadly applying the same fix to the command line for signing the JAR file, while obviously necessary, did not change the outcome: I still get the same error message.
Note that if the authentication token is invalid/expired I do get an appropriate error message explaining that authentication could not be performed. Getting a new token allows to go past that state and end up with the dreaded "Failed to load certificate from" error message

[ebourg]

Did you try with other versions of Java?

[obones]

I just did, and it does not change the result.
However, I finally found what was wrong: Using the version alias!
If I give KeyName/cryptoKeyVersions/1 as the last argument, I get the "Failed to load certificate from" error. But if I only give KeyName then it successfully signs the JAR.
There are warnings, but I'm quite confident they don't come from your code:

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

POSIX file permission and/or symlink attributes detected. These attributes are ignored when signing and are not protected by the signature.

The second one, I can't quite do anything about it and the first I believe comes my .cer file maybe missing the entire chain, but it's fine for other usages so I guess I can ignore the warning.

[ebourg]

Thank you for the feedback, I'm glad to hear it works.

If the .cer file contains only the final certificate and not the intermediate CA certificates that may explain the warning.

I'll look into the jarsigner code to understand why it fails with the versioned alias.

[ravikiran-schrodinger]

Hi, I am also trying to sign my jar file, faced exactly same issues as mentioned in this thread ("Failed to load certificate from"). Followed the solution proposed (just the alias name) and it indeed fixed the above issue. Below is the command that I used:

jarsigner -verbose -keystore NONE -storepass $ACCESS_TOKEN -storetype GOOGLECLOUD -providerClass net.jsign.jca.JsignJcaProvider -providerArg projects/infosec-hsm/locations/global/keyRings/coredev-windows-signing -J-cp -J$JSIGN_JAR_PATH -J--add-modules -Jjava.sql -J-Dfile.encoding=Cp1252 -sigfile bldmgr -tsa http://timestamp.digicert.com -certchain $CODE_SIGNING_CERT myfile.jar coredev-windows

and it says:

jar signed.

Warning: 
POSIX file permission and/or symlink attributes detected. These attributes are ignored when signing and are not protected by the signature.

I dint get the The signer's certificate chain is invalid. warning as my cert contains the complete chain.

Now comes the problem: When I try to verify the signed jar, I get the below error:

jarsigner -verify -verbose -certs myfile.jar 
jarsigner: java.lang.SecurityException: cannot verify signature block file META-INF/BLDMGR

@obones, have you tried verifying the jar after it was signed?

@ebourg, any help would be really appreciated.

Note: I am on Mac trying to sign a jar file and the jsign was downloaded by apache-maven in my pom.xml:

    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>3.1.0</version>
    <dependencies>
	    <dependency>
		    <groupId>net.jsign</groupId>
		    <artifactId>jsign</artifactId>
		    <version>7.1</version>
	    </dependency>
    </dependencies>

[ebourg]

Hi, if you can send the signed jar file to [email protected] I'll get a look.

[ravikiran-schrodinger]

Hi @ebourg, I have sent the problematic signed jar which fails when trying to verify.

[ebourg]

Thank you for the file. I got a quick look at it, I'm not sure but there is something weird in the signature, it contains the full certificate chain (DigiCert Trusted Root G4, DigiCert Trusted G4 Code Signing, Schrodinger Inc) but the actual certificate specified as the signer in the SignerInfos structure is "DigiCert Trusted Root G4" instead of "Schrodinger Inc". That seems wrong.

I wonder if Jsign returns the certificate chain in the wrong order, and jarsigner picks the root certificate instead of the signing certificate. You may try inverting the order of the chain in JsignJcaProvider and see if it improves the situation.

[ebourg]

Actually I think the issue is simply your $CODE_SIGNING_CERT file, try reverting its order.

[ravikiran-schrodinger]

Thanks a lot for the pointer. I will try reverting the order and get back to you shortly.

…

On Fri, Jul 4, 2025 at 12:23 PM Emmanuel Bourg ***@***.***> wrote: Actually I think the issue is simply your $CODE_SIGNING_CERT file, try reverting its order. — Reply to this email directly, view it on GitHub <#246 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVRAEA5WBIZU6PMN5N47FPL3GYQGTAVCNFSM6AAAAACAWQ3BN6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRVHE3TQMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ravikiran-schrodinger]

Hi @ebourg,

Actually I think the issue is simply your $CODE_SIGNING_CERT file, try reverting its order.

This indeed worked like a charm. We could successfully sign our jar files and verify them.
Thanks a lot for the pointer.