JS signing fails Windows valdation

[sms2000]

I have an issue when signing JS files.
Windows is failing to verify the signature with "This digital signature is not valid".

The same certificate and the signing process works well with PS1 scripts and with DLL/EXE binaries.

The digest algorithm is sha256.

[sms2000]

As it's occurred, the osslsigncode signs JS files incorrectly, but Jsign does the job properly.
Can the OSSL be updated to run JSign when processign JavaScripts?

[olszomal]

Hi, thanks for the report. To investigate, we need more details:

1. Operating system and version

2. Versions

• openssl version -a
• osslsigncode --version (master or last release)

3. Exact commands & full stdout/stderr

• The full osslsigncode signing command you used
• Verification with osslsigncode
• Verification with Windows signtool
• Anything else you used or settings you changed that could affect the test results

4. Files

• Unsigned JS example
• Signed JS file (by osslsigncode)
• Signed JS file by JSign for comparison
• Certificate chain used for verifying (PEM)

If you prefer not to post the files publicly, you can send them directly to me. All other information should be shared publicly in the issue.

[sms2000]

1. Operating system and version

   AstraLinux
   [xxxxxxxx@digicertsrv ~]# uname -a
   Linux digicertsrv.localdomain 4.18.0-553.el8_10.x86_64 unable to compile with openssl-1.0.2 #1 SMP Fri May 24 08:32:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

2. Versions

   [xxxxxxxx@digicertsrv ~]# **openssl version -a
   OpenSSL 1.1.1k FIPS 25 Mar 2021
   built on: Mon Dec 18 08:57:35 2023 UTC
   platform: linux-x86_64
   options: bn(64,64) md2(char) rc4(16x,int) des(int) idea(int) blowfish(ptr)
   compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM=""/dev/urandom"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
   OPENSSLDIR: "/etc/pki/tls"
   ENGINESDIR: "/usr/lib64/engines-1.1"
   Seeding source: os-specific
   engines: rdrand dynamic

[xxxxxxxx@digicertsrv ~]# osslsigncode --version
osslsigncode 2.10, using:
OpenSSL 1.1.1k FIPS 25 Mar 2021 (Library: OpenSSL 1.1.1k FIPS 25 Mar 2021)
libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.6/openssl/zlib nghttp2/1.33.0
Default -CAfile location: /etc/pki/tls/certs/ca-bundle.crt

Please send bug-reports to Michal.Trojnara@stunnel.org

3. Signing command

osslsigncode sign -pkcs11module /usr/lib64/libeTPkcs11.so -h sha256 -t http://timestamp.digicert.com -certs ~/signing_keys/certificate.pem -key certkey -readpass ~/signing_keys/token.password -in -out

[olszomal]

@sms2000 Thank you for providing the signed files for analysis.

>signtool verify /pa /v ossl_bad.js
Verifying: ossl_bad.js

Signature Index: 0 (Primary Signature)
Hash of file (sha256): 528E89A787DCD710716859DE2314DFFDCF5AF12F2AC9D1BA37E5BB4809344FEC

Signing Certificate Chain:
    Issued to: DigiCert Assured ID Root CA
    Issued by: DigiCert Assured ID Root CA
    Expires:   Mon Nov 10 01:00:00 2031
    SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

        Issued to: DigiCert Trusted Root G4
        Issued by: DigiCert Assured ID Root CA
        Expires:   Mon Nov 10 00:59:59 2031
        SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6

            Issued to: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
            Issued by: DigiCert Trusted Root G4
            Expires:   Tue Apr 29 00:59:59 2036
            SHA1 hash: 7B0F360B775F76C94A12CA48445AA2D2A875701C

                Issued to: xxxxxxxxx Ltd
                Issued by: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
                Expires:   Mon Jun 07 00:59:59 2027
...	

Based on the signtool verify /pa /v output for ossl_bad.js, the signing chain is built as follows:

• Root CA: DigiCert Assured ID Root CA
• Intermediate CA: DigiCert Trusted Root G4
• Intermediate CA: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
• Leaf certificate: xxxxxxxxx Ltd

Please make sure that in your Microsoft Certificate Store:

• “DigiCert Assured ID Root CA” is present in Trusted Root Certification Authorities
• “DigiCert Trusted Root G4” is present in Intermediate Certification Authorities

If either of these certificates is missing or placed in an incorrect store, Windows may fail to build the trust chain correctly, which can lead to verification errors.

You can download the necessary trusted root and intermediate certificates from DigiCert here:
DigiCert Trusted Root Authority Certificates

[sms2000]

@sms2000 Thank you for providing the signed files for analysis.

Please make sure that in your Microsoft Certificate Store:

* “DigiCert Assured ID Root CA” is present in Trusted Root Certification Authorities

* “DigiCert Trusted Root G4” is present in Intermediate Certification Authorities

If either of these certificates is missing or placed in an incorrect store, Windows may fail to build the trust chain correctly, which can lead to verification errors.

You can download the necessary trusted root and intermediate certificates from DigiCert here: DigiCert Trusted Root Authority Certificates

Added both.
Same results.

Anyway, there is still concern why OSSL signed JS fails Windows Authority check but the same file signed by JSign with the same PKC11 passes.

[olszomal]

Please compare the output of the command signtool verify /pa /v for both files (osslsigncode-signed and JSign-signed).
You will see that the signatures contain different certificate chains, which explains the different Windows Authority validation results.

Please use the exact same certificate chain (leaf certificate and all intermediate CAs) that JSign embeds when signing with
osslsigncode sign -certs ~/signing_keys/certificate.pem.