BattlEye validation issue due to missing intermediate certificates

vinnyvinny1989 commented 1 month ago

Hello all. First of all, thank you for your work. I'm trying to use jsign to sign files, but I have a problem that I can't solve.

I have Sectico hardware token. My files must be signed to work with Battleye anti-cheat program.

The problem is, when i sign files using Microsoft signtool, everything is ok. Command to sign: signtool sign /s my /as /fd SHA256 /tr http://timestamp.sectigo.com important_file.exe

But when I'm trying to use jsign, Battleye shows me the error message. Command to sign: jsign --storetype ETOKEN -d SHA-256 --storepass <password here> -t http://timestamp.sectigo.com important_file.exe

Battleye told me that the problem is that the files are signed by jsign don't have certificate chain. So they can't pass their validation. Maybe someone can tell me what parameters I need to enter to sign a file with a certificate chain?

I also noticed that the files are signed by jsign are smaller than files are signed by signtool (screenshot in attachment). I would really like to use jsign instead of signtool because with jsign I can specify password directly in sign command, and add sign system to CI/CD jsign_signtool_diffrence .

ebourg commented 1 month ago

The signature added to the file contains the certificate chain. signtool puts the whole chain in the signature, but the root certificate doesn't have to be included since it's already in the Windows truststore. For this reason Jsign doesn't put the root certificate in the signature and that's why the signed file is smaller.

Is the signature valid in the Digital Signatures tab of the Windows file properties? If so then that's a flaw in the Battleye verification algorithm.

If you don't mind rebuilding Jsign (with mvn package -DskipTests) you can modify the isSelfSigned() method in the AuthenticodeSigner class to always return false and see if that makes a difference with Battleye.

vinnyvinny1989 commented 1 month ago

I tried to compile jsign with isSelfSigned() method which return false and sign file. Unfortunately without success. Result file was the same size as before.

Also, I'm not very strong in coding, was it correct? private boolean isSelfSigned(X509Certificate certificate) { return false; }

ebourg commented 1 month ago

Yes that's correct. And after building the project you've used java -jar jsign\target\jsign-6.1-SNAPSHOT.jar --storetype ETOKEN ... ?

By disabling isSelfSigned()you should get a larger file, unless the certificate chain stored on the eToken contains only one certificate, but in this case Windows should tell you that the signature is invalid.

vinnyvinny1989 commented 1 month ago

Yes, my command was java -jar jsign-6.1-SNAPSHOT.jar --storetype ETOKEN -d SHA-256 --storepass <password here> -t http://timestamp.sectigo.com important_file.exe

About file sizes: filesizes_comparsion

ebourg commented 1 month ago

Could you send the two files signed by signtool and jsign to ebourg@apache.org? I'll give them a look.

vinnyvinny1989 commented 1 month ago

I wrote you an email.

Also, Battleye gave me the trick how to avoid this issue.

sign the file with signtool
export *.p7b certificate from file
sign another file with --certfile option

And voila, the problem has been solved, Battleye verification passed. Maybe this will be useful to someone. But if signtool can do it without exported *.p7b it will be more convenient to add this features to jsign

jsign --storetype ETOKEN -d SHA-256 --storepass <password here> --certfile exported_cert.p7b -t http://timestamp.sectigo.com important_file.exe

ebourg commented 1 month ago

Thank you for the files.

The file signed by signtool contains 6 certificates:

3 for your signing certificate and the intermediate certificates (Sectigo Public Code Signing CA EV R36, Sectigo Public Code Signing Root R46). The root certificate 'AAA Certificate Services' isn't included.
3 for the timestamping certificate chain (DigiCert Timestamp 2023, DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, DigiCert Trusted Root G4). The root certificate 'DigiCert Assured ID Root CA' isn't included.

So I was wrong when I said that signtool adds the root certificates to the signature, and tweaking isSelfSigned() cannot have any effect on this issue.

The file signed by Jsign contains 4 certificates:

One is your signing certificate
3 are for the timestamping chain, the same as above

So it seems the issue is caused by the lack of the 2 intermediate certificates (Sectigo Public Code Signing CA EV R36, Sectigo Public Code Signing Root R46) from the signature generated by Jsign. Since these certificates are in the Windows truststore the signature is considered valid by Windows. But external verification tools will fail to validate the signature if they don't have a similar list of intermediate certificates.

On the BattlEye side, they should pull the intermediate CA certificates from the Windows truststore when validating files, and not just the list of root CA. That's definitely an issue worth reporting.

On the Jsign side, it would be nice if the signing certificate chain could be completed automatically with the missing intermediate certificates similarly to signtool. But since Jsign is cross-plaform and cannot fetch the certificates from the Windows truststore, the list of certificates will have to be bundled with Jsign. This will be useful for implementing the verification feature anyway. Ther list of root and intermediate CA certificates is available from the Common CA database.

In the meantime, the workaround is to set the --certfile parameter pointing to a file containing the two intermediate certificates:

ebourg commented 1 month ago

Alternatively, if you can load the full certificate chain on the SafeNet eToken you could avoid the --certfile parameter. I don't know if that's possible though.

ebourg commented 1 month ago

Digging further, I thought Windows had a list a intermediate CA certificates but I was wrong. Windows adds the intermediate certificates automatically to its trustsore as it discovers them. It does that by fetching the parent certificates using the URL from the authorityInfoAccess field (OID 1.3.6.1.5.5.7.1.1) of the certificate.

This means Jsign could complete the certificate chain automatically. That would remove the need to set the --certfile parameter for all USB tokens that can only store the signing certificate and not the whole chain.

vinnyvinny1989 commented 1 month ago

Thank you for your work and explanation. I also sent a link to the issue to the BattlEye team, they might find it interesting too.

vinnyvinny1989 commented 1 month ago

The BattlEye team wrote me:

the API we use should process the whole chain automatically, but it returns the error of incomplete certificate chain in this case. So it appears some intermediate certificates are not stored on the system (under the system service account which BE runs under) yet and as we found, this failure then happens because for compatibility reasons (sometimes we encountered timeouts, etc.) we do not use AIA retrieval (i.e. downloading intermediate certificates from the internet). So I don't think we can solve this from our end currently.

ebourg commented 1 month ago

@vinnyvinny1989 The missing intermediate certificates are now downloaded automatically. Could you give it a try an confirm it works for you please?

vinnyvinny1989 commented 1 month ago

@vinnyvinny1989 The missing intermediate certificates are now downloaded automatically. Could you give it a try an confirm it works for you please?

To do this I need to rebuild jsign from master branch?

ebourg commented 1 month ago

Yes, or you can download the CI build: https://github.com/ebourg/jsign/actions/runs/9038916734/artifacts/1492735001

vinnyvinny1989 commented 1 month ago

Yes, or you can download the CI build: https://github.com/ebourg/jsign/actions/runs/9038916734/artifacts/1492735001

Confirmed. Everything works well. Thank for your work again!

ebourg commented 1 month ago

Great! Thank you for the feedback

ebourg / jsign

BattlEye validation issue due to missing intermediate certificates #217