Help with signing the Windows application?

I've been having troubles getting the Windows application signed lately and it means I'm no longer able to release Windows versions of Joplin. As some of you may know signing the app is required to avoid warnings and even error messages that prevent the app from launching on Windows. Basically without a certificate, Windows makes the app look like malware.

Obtaining this certificate is a chore as you need to go through a Kafkaian process, from one website to another, and one "support" worker to another and how to do this changes every year and makes very little sense. I always keep a note of how I've done it but my notes are always useless the next year due to the way it changes all the time.

Anyway, after several weeks of back and forth I eventually got the new certificate... except I have no idea how to use it. They gave me a number of CRT files:

  • 00BDE1C03B9184843D8C70CD9946C88FDC.crt
  • AAACertificateServices.crt
  • SectigoPublicCodeSigningCAR36.crt
  • SectigoPublicCodeSigningRootR46_AAA.crt

However we need a .p12 file. So I've tried various ways to convert them but nothing seems to work, and that's largely because I don't understand what these files are (they gave no information about them), or what precise p12 file we need for the app.

This was one of the attempts:

Desktop release v2.9.8 · laurent22/joplin@907dc76 · GitHub (full error copied below)

At this point I'm stuck and it means we can't publish new desktop versions anymore, so I'm wondering if anyone here is familiar with signing Windows applications? Any idea of what needs to be done based on the name of the files above or the errors in the build log? Any help would be much appreciated.

Full error:

⨯ Exit code: 1. Command failed: C:\Users\runneradmin\AppData\Local\electron-builder\Cache\winCodeSign\winCodeSign-2.6.0\windows-10\x64\signtool.exe sign /t http://timestamp.digicert.com /f C:\Users\RUNNER~1\AppData\Local\Temp\t-NhUGIl\0.p12 /d Joplin /du https://github.com/***/joplin#readme /p 53e2ad310f2be2acb6745e97673004c351c2460b77fcfd71619c0d6b74d43cf9 (sha256 hash) /debug D:\a\joplin\joplin\packages\app-desktop\dist\win-unpacked\Joplin.exe
SignTool Error: No certificates were found that met all the given criteria.


The following certificates were considered:
	Issued to: Cozic Ltd

	Issued by: Sectigo Public Code Signing CA R36

	Expires:   Thu Sep 11 23:59:59 2025

	SHA1 hash: BCB839AE269000E3C6E485A69848F7F2FA8F5EBF


	Issued to: AAA Certificate Services

	Issued by: AAA Certificate Services

	Expires:   Sun Dec 31 23:59:59 2028

	SHA1 hash: D1EB23A46D17D68FD92564C2F1F1601764D8E349


	Issued to: Sectigo Public Code Signing CA R36

	Issued by: Sectigo Public Code Signing Root R46

	Expires:   Fri Mar 21 23:59:59 2036

	SHA1 hash: 0BC5E76773D2E44FC9903D4DFEFE451553BBEC4A


	Issued to: Sectigo Public Code Signing Root R46

	Issued by: AAA Certificate Services

	Expires:   Sun Dec 31 23:59:59 2028

	SHA1 hash: 329B78A5C9EBC2043242DE90CE1B7C6B1BA6C692


After EKU filter, 4 certs were left.
After expiry filter, 4 certs were left.
After Private Key filter, 0 certs were left.

SignTool Error: No certificates were found that met all the given criteria.
failedTask=build stackTrace=Error: Exit code: 1. Command failed: C:\Users\runneradmin\AppData\Local\electron-builder\Cache\winCodeSign\winCodeSign-2.6.0\windows-10\x64\signtool.exe sign /t http://timestamp.digicert.com /f C:\Users\RUNNER~1\AppData\Local\Temp\t-NhUGIl\0.p12 /d Joplin /du https://github.com/***/joplin#readme /p 53e2ad310f2be2acb6745e97673004c351c2460b77fcfd71619c0d6b74d43cf9 (sha256 hash) /debug D:\a\joplin\joplin\packages\app-desktop\dist\win-unpacked\Joplin.exe
SignTool Error: No certificates were found that met all the given criteria.
																																																																																																																																																																																																																																																																																																																																																																																																						
The following certificates were considered:
	Issued to: Cozic Ltd

	Issued by: Sectigo Public Code Signing CA R36

	Expires:   Thu Sep 11 23:59:59 2025

	SHA1 hash: BCB839AE269000E3C6E485A69848F7F2FA8F5EBF

Issued to: AAA Certificate Services

	Issued by: AAA Certificate Services

	Expires:   Sun Dec 31 23:59:59 2028

	SHA1 hash: D1EB23A46D17D68FD92564C2F1F1601764D8E349

Issued to: Sectigo Public Code Signing CA R36

	Issued by: Sectigo Public Code Signing Root R46

	Expires:   Fri Mar 21 23:59:59 2036

	SHA1 hash: 0BC5E76773D2E44FC9903D4DFEFE451553BBEC4A

Issued to: Sectigo Public Code Signing Root R46

	Issued by: AAA Certificate Services

	Expires:   Sun Dec 31 23:59:59 2028

	SHA1 hash: 329B78A5C9EBC2043242DE90CE1B7C6B1BA6C692

After EKU filter, 4 certs were left.
After expiry filter, 4 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
2 Likes

Does this help?

Hmm, not really. I can convert a crs to p12 but it's more in the details that things aren't working, and it's not clear why.

Can you sign the files manually on a local machine?
Here is the signing tool mentioned in the log

No I can't either, same error as on the GitHub action

Seems like the cer(crt) file can be specified for signing.

The following command signs the file using a certificate stored in a file. The private key information is protected by a hardware cryptography module, and the cryptographic service provider (CSP)and key container are specified by name. This command is useful if the certificate is not properly installed.

SignTool sign /f HighValue.cer /csp "Hardware Cryptography Module" /k HighValueContainer MyControl.exe

I have never signed a Windows app but let's assume the log error is reliable then we can work from there. CRT is certificate and p12 is certificate + YOUR private keys. Seen the error have something to do with private key, maybe there some error in your crt to p12 converting process. Maybe you don't include your private key in the p12 file at all. As these involve private key maybe try these methods on local machine first.

Attempt 1: try follow this one to get .crt and .key file openssl - Convert a code signing certificate from Sectigo/Comodo into a .pfx file that is actually usable - Stack Overflow and create p12 then sign again

Attempt 2: try create p12 with crt and local machine private key then try sign it locally. Create a .pfx/.p12 Certificate File Using OpenSSL - SSL.com or https://www.digicert.com/kb/code-signing/exporting-code-signing-certificate.htm

Attempt 3: maybe some weird error with windows environments. Try this one windows - Code signing with signtool fails due to private key filter - Stack Overflow

Attempt 4: if all else is failed try run signtool.exe with admin privilege

2 Likes

That was my thought too, but I think I do since I'm passing all the crt files, whatever they are, to openssl when building the p12.

1 Like

So the most likely problem is the creation of p12, maybe we can focus on that. Those CRT file seems to be your certificate, intermediate certificate, and root certificate. Basically they certify each other. This is my guess based on file name you can check with with the hash to be sure

  • 00BDE1C03B9184843D8C70CD9946C88FDC.crt (CAR36 certify Cozic Ltd, your)
  • AAACertificateServices.crt ( AAA self-signed, root )
  • SectigoPublicCodeSigningCAR36.crt (RootR46 certify CAR36, intermediate)
  • SectigoPublicCodeSigningRootR46_AAA.crt (AAA certify RootR46, intermediate)

We need to combine intermediate and root certificate first IBM Documentation

cat SectigoPublicCodeSigningCAR36.crt SectigoPublicCodeSigningRootR46_AAA.crt AAACertificateServices.crt > bundle.crt

Then generate p12 file. Maybe something like this

openssl pkcs12 -inkey YOUR_KEY.key -in 00BDE1C03B9184843D8C70CD9946C88FDC.crt -export -out 0.p12 -CAfile bundle.crt -chain
3 Likes

Maybe you can install the certificate first, then access them by name.

The log output is quite similar to yours in this case.
I got this post from there

Another post about signing in electron with crt file

@laurent : When creating your CSR (Certificate Signing Request), you used a private key. This should be the -inkey parameter of @hieuthi second command.

1 Like

@mat-m, the thing is that I didn't use a private key. They just sent me the four CRT files I mentioned above and nothing else. Or is one of these the private key?

@laurent , I think they won't send you the private key file because they just need your public key.

According to a lot of tutorials online, I think these are the general steps to signing an application:

  1. Generate a private key file(or use an existing one), the file usually contains both the public key part and the private key part.
  2. Make a certificate signing request associated with the private key file. The CSR file should contains the public key part
  3. Send the CSR file to your CA
  4. Get crt file(s) from CA
  5. Combine the crt file with your private key file(commands are listed above)
  6. Use the combined file to sign your code.

During the process, the private key part is never sent to anyone. the crt file is associated with your private key part only because you provided the related public key part in CSR file.
I wonder how you contacted the CA. Do steps 1~4 match you?

Here is another situation. Maybe you are actually contacting to an agent who does steps 1~5, and he is supposed to give you the combined private key file in step 5, but he only gave you the crt file from step 4

By the way, if you bought the code signing certificate directly from Sectigo(according to the filename you provided), you can contact the service support from them. They claims to have the 24/7 full service support

@Laurent
At one point , you should either :

  • have submitted a CSR (a file),
  • or fill a form (with Organization Name, at least), in which case they should would provide the private key.

If one of the file is the private key, it should start with
-newkey rsa:2048 -keyout PRIVATEKEY.key -out MYCSR.csr

Any update on this issue?

The problem seems to be the missing of the private key. But depending on how you requested the certificate, it would be difficult for us to guess where that private is. For example: if you request the certificate yourself through your personal computer/joplin website server, there is a chance the default private key in the server/computer was used (this is just a guess)

If one of the files you mentioned has private key in this, you can actually try to check it yourself. If it is the case then it is most likely in 00BDE1C03B9184843D8C70CD9946C88FDC.crt . Just open it with text editor and see if there is two distinctive blocks of text. You can also try open the other files as well (they should have one block of text).

1 Like

Yes the problem is probably the lack of private key. I can't believe how bad their process is anyway.

I think I ordered using Chrome and at that point, their process should have created a private key... but that doesn't work with Chrome. You need to go back to the 90s and use Internet Explorer (or Netscape, who knows) to get that part working - then it creates a private key, which you can export. And those idiots sent me a bunch of useless crt files with no information on how to retrieve the private key.

Anyway I tried contacting Sectigo and got no answer, so now I'm trying from CheapSslSecurity and we'll see if we get any answer. I told them I need the private key or some explanation on how to get it.

I see. If you still have access to the same machine and Internet Explorer used to request the certificate then you can try extract the private key use this method. https://www.digicert.com/kb/code-signing/exporting-code-signing-certificate.htm

Does the signing work now?