MC Launcher does not trust valid certificate

[rbeckman-nextgen]

We have a bunch of custom extensions and they are signed with a certificated signed by a proper CA and with the proper extensions.

Still, the Administrator launcher shows warnings about an untrusted certificated found, which is not the case when launched from a browser.

Here's the jarsigner output for one of the jar the launcher is complaining about:

s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope

Signed by "CN=Intégration Santé, O=Intégration Santé, L=Shawinigan, ST=Québec, C=CA" Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 2048-bit key Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Fri Apr 10 07:31:29 UTC 2020 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key

jar verified.

The signer certificate will expire on 2021-01-21. The timestamp will expire on 2029-03-22.

Imported Issue. Original Details: Jira Issue Key: MIRTH-4504 Reporter: sbraconnier Created: 2020-04-13T09:01:03.000-0700

[rbeckman-nextgen]

Here's the public certificate for criteria validation.

Imported Comment. Original Details: Author: sbraconnier Created: 2020-04-13T09:05:56.000-0700

[rbeckman-nextgen]

Hmm, is it actually a code signing certificate though? It's not enough just to be a CA-signed X.509 cert for HTTPS client/server communication. There are special extensions that designate a certificate specifically for code signing. That is usually a separate/special request with most major vendors like Entrust/Verisign/etc.

Also what's the full DN and fingerprint for the issuer certificate you're using?

Imported Comment. Original Details: Author: narupley Created: 2020-04-13T09:08:51.000-0700

[rbeckman-nextgen]

Thanks for uploading that, I see that it is a code signing cert. Will check on that issuer...

Imported Comment. Original Details: Author: narupley Created: 2020-04-13T09:11:37.000-0700

[rbeckman-nextgen]

Okay took a closer look at that. When we're validating whether or not to show a warning dialog, we look at whether the cert is directly or transiently signed by one of the "official" Java JCE code signing CA certs (CN=JCE Code Signing CA). For other third-party signers we still allow the connection, but show that dialog to the user so they know it's coming from an unofficial root CA signer.

A possible improvement we could make is once the user clicks yes to trust that signer, we could store that information on the system. However that would introduce a new attack vector wherein a malicious actor could edit that information, insert their own bogus signer, and then the user could launch Connect without any warnings and be none the wiser. Certainly food for thought and an interesting challenge to balance a good user experience with appropriate layers of security...

Imported Comment. Original Details: Author: narupley Created: 2020-04-13T15:26:03.000-0700

[rbeckman-nextgen]

Hmmm... I'm not sure I understand why digicert is not an official code signing CA cert. If I look at my unaltered cacerts file (jre1.8.0_202), I can find the digicert root ca signer (CN=DigiCert Assured ID Root CA). I can also find it into the OpenJDK 11 cacerts.

We assumed that paying to properly sign our extensions would make the warning goes away (and it did using a browser). Here's the product we use: https://www.digicert.com/code-signing/

At 473$ a year, I'm sure they would also like to know why they are not considered "official" :P.

That being said, if you cannot add digicert as a trusted root by default, could you propose us a few company names you known that signing our stuff with their stuff would make the warning disappear ??

Imported Comment. Original Details: Author: sbraconnier Created: 2020-04-14T05:37:17.000-0700

[rbeckman-nextgen]

I see your point, and maybe we are being too cautious there when it comes to those certificates. We'll look into relaxing our security warnings there.

Imported Comment. Original Details: Author: narupley Created: 2020-04-14T08:48:18.000-0700