Modify

Opened 10 months ago

Closed 6 months ago

#23107 closed task (fixed)

Code Signing certificate rollover

Reported by: stoecker Owned by: team
Priority: normal Milestone: 23.12
Component: Core Version:
Keywords: Cc: Don-vip, taylor.smock

Description

At 2023-09-12 our code signing certificate ends. Sectigo seems to have trippled prices to about 300€/year. SSL.com is still in the range 100€/year.

According to this table it should also work for Java

Would be fine if we could somehow verify if that's true before ordering a new certificate.

Attachments (2)

pom.xml (10.2 KB ) - added by taylor.smock 7 months ago.
Fairly minimal pom.xml for generating a signed jar. Currently does not work for jarsigning, see comment:31.
SecurityWarning.png (210.9 KB ) - added by taylor.smock 6 months ago.

Download all attachments as: .zip

Change History (52)

comment:1 by taylor.smock, 10 months ago

From looking at https://www.ssl.com/article/ssl-com-root-certificates/ (last updated 2015-06-03), maybe? It kind of depends upon which root is used.

The JDK does have 3 certs from SSL.com built-in (see https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrootevrsaca, https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrooteccca, and https://github.com/openjdk/jdk/blob/master/src/java.base/share/data/cacerts/sslrootrsaca ). All were added in 2020 to OpenJDK, and all were generated after the last update of the root certificates help article.

comment:2 by stoecker, 10 months ago

So it will not work with java version before 2020, it could work for >= 2020. Should be fine with me when that saves 600€.

comment:3 by Don-vip, 10 months ago

Nobody should run in 2023 a Java < 2020 so that's even a good choice if it forces users to upgrade a vulnerable version of Java.

comment:4 by Frederik Ramm, 9 months ago

Do we still need this code-signing stuff at all? Even if we get FOSSGIS to sponsor it, we're still burning > EUR 200/year of donation money to feed the certificate gatekeepers... and for what?

comment:5 by taylor.smock, 9 months ago

Do we still need this code-signing stuff at all?

The last ticket where we had to update the code signing certificate was #12115, and I was unable to find any other tickets where we discussed why we needed/wanted a code signing certificate.

I don't think we really need the code signing certificate for the installers for Mac/Windows, since I think both of those get signed separately using separate keys, but I could be wrong -- we could be reusing the code signing key for those.

With that said, we use distribute JNLP files; this is where we might need/want the code signing certificate.

As a specific example, OpenWebStart will show the user a "Security Approval Required" window. In that window, it says "The digital signature has been validated by a trusted source". I don't remember what Oracle webstart does, but I think it either skips showing the user a dialog entirely, or says something similar.

We have been pushing users to move to OpenWebStart from Oracle Webstart for quite some time now, and we want to move to Java 11 or Java 17 (see #17858), so a different option would be to use a self-signed certificate. It looks like OpenWebStart will accept that, although an system administrator can prevent users from granting permissions to content from an untrusted authority.

Even if we get FOSSGIS to sponsor it

If FOSSGIS doesn't sponsor it, we can probably get OSMF to sponsor it (the EWG wants to use 50% of their budget for core OSM software). Although there might be some red tape we don't want to deal with.

comment:6 by taylor.smock, 9 months ago

Milestone: 24.0823.08

comment:7 by stoecker, 9 months ago

Currently we sign the jar (for WebStart). Winows MSI and Exe are both signed with the same Cert (I'm not sure if the Java Sign is passed through or it's signed directly again).

comment:8 by stoecker, 9 months ago

Hmm, very likely the MacOS variant is also signed with the same cert. I don't know how to retrieve the values from GitHub. It seems I can only change them.

comment:9 by stoecker, 9 months ago

So essentially we sign everything. Only Linux doesn't need signatures. I suggest everybody drops these proprietary vendor-locked in operating systems!

Today I had to reboot my Linux because the system upgrade prevented new network connections. It's something I can't even start to explain to Windows users that I really get angry when I'm forced to reboot my system... Windows (MacOS no less) is so bad and still people use it. Strange.

comment:10 by taylor.smock, 9 months ago

Linux might need signatures to avoid scary warnings for the JNLP files. It depends upon the Webstart implementation.

Otherwise, it is typically up to the distribution to do the verification. Many build from source, some do not.

I do know that everything that uses the josm gradle plugin (maintained by floscher, not us) will need to update their compile version, since the test jar will have a different signature from the application jar. This will be the case regardless of whether or not we renew the signature.

comment:11 by taylor.smock, 9 months ago

Milestone: 23.0823.09

Ticket retargeted after milestone closed

comment:12 by taylor.smock, 8 months ago

Signing the Windows installers is now failing: https://github.com/JOSM/josm/actions/runs/6236521091/job/16928040720

SignTool Error: No certificates were found that met all the given criteria.

Have we gotten a new certificate, or do we need to remove the signing steps from the GitHub CI?

in reply to:  12 comment:13 by stoecker, 8 months ago

Replying to taylor.smock:

Signing the Windows installers is now failing: https://github.com/JOSM/josm/actions/runs/6236521091/job/16928040720

SignTool Error: No certificates were found that met all the given criteria.

Have we gotten a new certificate, or do we need to remove the signing steps from the GitHub CI?

Not yet. But we will. I tried a cheaper solution, but didn't get permission to use the certificate. That delayed renewal a bit :-)

comment:14 by taylor.smock, 8 months ago

Milestone: 23.0923.10

Ticket retargeted after milestone deleted

comment:15 by stoecker, 8 months ago

Ticket #23217 has been marked as a duplicate of this ticket.

comment:16 by SekeRob, 8 months ago

OT\ Re "So it will not work with java version before 2020" and other drives to get user to upgrade to a newer JAVA release, I recently updatedg the Java install on my machine to the latest latest v17 stable but not seeing it reflected in the startup of JOSM. Went to read and discovered that OpenWebStart installs it's own v17 which is slightly behind the one I manually installed. Their argument being them not wanting to break other app dependencies. And they're not the only one doing so, found I have 3 Java installs on the system. /OT

comment:17 by taylor.smock, 8 months ago

Java 17 was released on 2021-09-11.

I have opened a ticket on the OWS github for automatically updating the jvms.json file. I didn't see any arguments in my search about them not wanting to break other app dependencies (unless they were talking about the version of java they build and distribute for OWS itself; this specifically is not a system installation of Java).

comment:18 by taylor.smock, 7 months ago

Should I start planning on skipping the 23.10 release?

comment:19 by stoecker, 7 months ago

Let's hope not to.

comment:20 by taylor.smock, 7 months ago

I hope not as well. What I might end up doing is assume that the time before we get a new certificate is undefined, and just plan on doing a release a week after we get the new certificate. I am assuming I can get all the installers built via the GH action (macOS notarization might be a problem, see #23125).

in reply to:  20 comment:21 by stoecker, 7 months ago

Replying to taylor.smock:

I hope not as well. What I might end up doing is assume that the time before we get a new certificate is undefined, and just plan on doing a release a week after we get the new certificate. I am assuming I can get all the installers built via the GH action (macOS notarization might be a problem, see #23125).

Uh. October release will also fail. Certificate rollover is combined with more bullshit than expected. Seems since the rule changes in Q1 this year they went amok.

comment:22 by taylor.smock, 7 months ago

Thank you for letting me know. I didn't know there were rule changes this year.

It looks like we will need a physical device to store the key on ("FIPS 140-2 Level 2" or "Common Criteria EAL 4+"). I don't think that will work for either Jenkins or GitHub CI, but I could be wrong.

The alternative would be to use one of the cloud HSMs mentioned in the SSL.com guide (AWS, Azure, and Google). I don't think we can realistically do BYOA.
The problem being I don't understand their pricing scheme. I assume it is per hour that the key is on their servers, which make all of them a no-op.

I'm looking into alternatives. One I just found (and am looking into) is https://www.sigstore.dev/ . Which is allegedly for OSS applications. I found it from https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html via a search for open source code signing.

comment:23 by stoecker, 7 months ago

I wouldn't like that physical device much, but that probably will be a possible solution. I could attach it to one of our office servers and setup a signing service called from our JOSM instances. Maybe it's even possible to attach to the server at Hetzner.

comment:24 by taylor.smock, 7 months ago

Fair enough. I doubt that we will be able to attach it to the server at Hetzner though -- I suspect that all supported devices require a physical action (e.g. a keypress).

in reply to:  24 comment:25 by stoecker, 7 months ago

Replying to taylor.smock:

Fair enough. I doubt that we will be able to attach it to the server at Hetzner though -- I suspect that all supported devices require a physical action (e.g. a keypress).

Well, I'll for sure not get up each night a 0:00 to press a button in our office ;-)

comment:26 by taylor.smock, 7 months ago

Milestone: 23.1023.11

Ticket retargeted after milestone deleted

comment:27 by stoecker, 7 months ago

Signstore seems not to provide any code signing for Windows, MacOS or Java. The hardware tokens require a key press for each signing, making them worthless.

Actually after I now tried myself to get deeper into the topic I tend to drop signing completely. It's simply

  • expensive and
  • no longer automatable

Users will simply have to live with the warnings.

comment:28 by stoecker, 7 months ago

What we could do is provide and use an own certificate. That way it's possible to verify if the software was made by us. But no official certificate seems usable anymore.

comment:29 by taylor.smock, 7 months ago

I'll do a deeper dive into sigstore -- there is a maven plugin that can do jarsigning.

comment:30 by stoecker, 7 months ago

I disabled signing for all releases (hopefully), so we can do releases again independent from the fact if we ever sign them again or not. But I'll stop the hold, so that 23.11 should go out signed or not.

comment:31 by taylor.smock, 7 months ago

It looks like the maven plugin is currently borked for jarsigning. I've filed a ticket.

by taylor.smock, 7 months ago

Attachment: pom.xml added

Fairly minimal pom.xml for generating a signed jar. Currently does not work for jarsigning, see comment:31.

comment:32 by taylor.smock, 7 months ago

OpenWebStart really doesn't like unsigned jars (you can test with the josm-latest.jnlp).

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:592)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:373)
	at net.sourceforge.jnlp.Launcher.access$300(Launcher.java:71)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:660)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.classloader.SecurityDelegateImpl.getClassLoaderSecurity(SecurityDelegateImpl.java:102)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.setSecurity(JNLPClassLoader.java:387)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.initializeResources(JNLPClassLoader.java:776)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.<init>(JNLPClassLoader.java:350)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.createInstance(JNLPClassLoader.java:423)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:495)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:468)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:584)
	... 3 more

We might be able to work around that, but I'm not certain about that.
The most likely way to work around that would be to self-sign the jar. Users will probably still get a warning, but it might be enough for OWS to start.

comment:33 by stoecker, 7 months ago

Signing is no issue. I have even a CA cert available: https://www.dstoecker.eu/cert.html

Only issue is that nobody except me trusts it ;-)

comment:34 by stoecker, 7 months ago

I'll try tomorrow if it helps.

comment:35 by gaben, 7 months ago

I'm getting with Java 8 JNLP the following startup error on Windows:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:846)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2496)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:384)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:812)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:337)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:420)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:494)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:467)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:838)
	... 2 more

comment:36 by taylor.smock, 7 months ago

I found another alternative "for OSS projects" via https://github.com/sigstore/fulcio/issues/250: https://about.signpath.io/product/open-source . They claim to support jar files.

@gaben: It doesn't look like stoecker signed josm-latest.jar over the weekend, or at least the current https://josm.openstreetmap.de/download/josm-latest.jar wasn't signed.

EDIT: The signpath certificate is currently OV not EV. The linked fulcio ticket has someone who claims to work at sigstore saying that they are considering EV certificates for OSS.

Last edited 7 months ago by taylor.smock (previous) (diff)

comment:37 by stoecker, 7 months ago

Sorry. Had no time. It's not forgotten.

comment:38 by stoecker, 6 months ago

Could someone test please: download/josm-test.jnlp. Seems my Linux doesn't support Webstart anymore without effort ;-)

Last edited 6 months ago by stoecker (previous) (diff)

comment:39 by taylor.smock, 6 months ago

Looks like that works for me.

There is a warning message. I'll upload a screenshot.

EDIT:

Last edited 6 months ago by taylor.smock (previous) (diff)

by taylor.smock, 6 months ago

Attachment: SecurityWarning.png added

comment:40 by stoecker, 6 months ago

I enabled it for latest. We'll see when next latest is build.

comment:41 by stoecker, 6 months ago

Question remains what to do with MacOS and Windows. No signing? Use this Key?

comment:42 by taylor.smock, 6 months ago

I think we're OK for mac. I'll double-check that.

Windows: There is some kind of reputational score, so it may take some time before users stop seeing a "scary" warning. We'll want to start signing Windows installers with a new key a few months before the old one expires -- this will build the reputation score for the new key (from what I've read). Probably not an issue for awhile though:

Validity: [From: Wed Nov 15 10:16:21 MST 2023,

To: Tue Nov 15 10:16:21 MST 2033]

Root CA might be a problem -- I'm not certain how expired root certificates with unexpired issued certificates will be handled.

Validity: [From: Fri Dec 04 09:43:22 MST 2015,

To: Thu Dec 04 09:43:22 MST 2025]

in reply to:  42 comment:44 by stoecker, 6 months ago

Hmm,

Validity: [From: Fri Dec 04 09:43:22 MST 2015,

To: Thu Dec 04 09:43:22 MST 2025]

Maybe It's time to renew my root. It aged a bit ;-) ...at the weekend...

Last edited 6 months ago by stoecker (previous) (diff)

comment:45 by taylor.smock, 6 months ago

Max Ericson mentioned https://www.yubico.com/store/yubihsm-2-series/ -- he thinks that the descriptions don't read like they need physical interaction. I tend to agree -- one of the images seems to indicate that you can put it in a server case (on a motherboard USB port).

Unfortunately, the cost is significant -- $950. Maybe we can poke the OSM EWG for funding?

We'll probably have to either install a github runner on our server or pull the installers and sign them after the GH run.

EDIT: It looks like josm-latest isn't updating.

Last edited 6 months ago by taylor.smock (previous) (diff)

comment:46 by stoecker, 6 months ago

If it would work and not be obsolete in 2 years and we get it paid (and additionally the cert) I still don't want this. Such methods are the death of free OpenSource and I don't want to contribute to that.

EDIT: It looks like josm-latest isn't updating.

Permissions issue ;-)

in reply to:  46 comment:47 by stoecker, 6 months ago

Replying to stoecker:

If it would work and not be obsolete in 2 years and we get it paid (and additionally the cert) I still don't want this. Such methods are the death of free OpenSource and I don't want to contribute to that.

EDIT: It looks like josm-latest isn't updating.

Permissions issue ;-)

It helps to set permissions for the correct file. Tomorrow again...

comment:48 by taylor.smock, 6 months ago

Milestone: 23.11

Ticket retargeted after milestone closed

comment:49 by taylor.smock, 6 months ago

Milestone: 23.12

comment:50 by stoecker, 6 months ago

Resolution: fixed
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.