signer information does not match signer information of other classes in the same package

[Gubaer]

I maintain the scripting plugin on Git Hub. I build it there daily using GitHub actions.

For around two weeks, the builds fail with error messages like the following:

java.lang.SecurityException: class "org.openstreetmap.josm.gui.layer.LayerManagerTest$TestLayer"'s signer information does not match signer information of other classes in the same package

Does this ring a bell with somebody? Did something change in how the JOSM jar or the josm-unittest.jar is built?

[anonymous]

Related to #23107 I think

[stoecker]

Interesting. Now what's that again.

JOSM is now signed with a certificate signed by my own "CA" (i.e. essentially self-signed). There are two signing keys, one is "JOSM Team" which is used on JOSM server for the JAR, effectively active since approx 1 week. The second is for the MACOS and Windows package on GitHub (effectively active probably not yet) called "JOSM Team (GitHub)".

Since the old certificate went EOL JOSM wasn't signed at all.

Though the error message is a bit strange. It should either be signed or not signed or unknown CA, but not signing differs. Can you please check in detail what the cause is?

[taylor.smock]

I assume you are talking about ​https://github.com/Gubaer/josm-scripting-plugin .

I also assume you are using gradle.

A known problem with the gradle builds is that the unittest library they use is whatever we built last. This means that when the signing key changes, gradle builds will have problems.
The easiest workaround is to increase the min JOSM version to the version where we had to change signing keys.
A slightly harder workaround is to convert to the standard "ant" build and use something like ​https://github.com/JOSM/JOSMPluginAction .

[Gubaer]

I assume you are talking about ​​https://github.com/Gubaer/josm-scripting-plugin .

Yes

I also assume you are using gradle.

Yes

The easiest workaround is to increase the min JOSM version to the version where we had to change signing keys.

Did you change the signing key around Nov 20? Did you introduce around Nov 20 a self-signed root certificate for the root CA CN=Stoecker.eu Root Certificate 2023, C=DE, ST=Germany, L=Bischofswerda, O=Stoecker.eu/emailAddress=cert@dstoecker.de?

Validity of the root certificate and of the certificate for the code signing key in the josm-latest.jar and josm-unittest.jar starts at Nov 20 18:31:50 2023 GMT.

So, JOSM 18902 built on Nov 22 could be a candidate for the min JOSM version?

Not specific to the problem at hand here and slightly offtopic:
Why did you switch to a root CA associated with one of JOSM's administrators (stoecker)? Since you probably replaced a commercial CA with a self-signed CA, couldn't you have replaced it with a CA associated with the JOSM organization/team? Similar to what you did for the code signing certificate whose subject is C=DE, ST=Germany, O=JOSM Team, CN=JOSM Team/emailAddress=cert@josm.openstreetmap.de.

[taylor.smock]

Replying to Gubaer:

The easiest workaround is to increase the min JOSM version to the version where we had to change signing keys.

Did you change the signing key around Nov 20? Did you introduce around Nov 20 a self-signed root certificate for the root CA CN=Stoecker.eu Root Certificate 2023, C=DE, ST=Germany, L=Bischofswerda, O=Stoecker.eu/emailAddress=cert@dstoecker.de?

Validity of the root certificate and of the certificate for the code signing key in the josm-latest.jar and josm-unittest.jar starts at Nov 20 18:31:50 2023 GMT.

So, JOSM 18902 built on Nov 22 could be a candidate for the min JOSM version?

Yes

Not specific to the problem at hand here and slightly offtopic:
Why did you switch to a root CA associated with one of JOSM's administrators (stoecker)? Since you probably replaced a commercial CA with a self-signed CA, couldn't you have replaced it with a CA associated with the JOSM organization/team? Similar to what you did for the code signing certificate whose subject is C=DE, ST=Germany, O=JOSM Team, CN=JOSM Team/emailAddress=cert@josm.openstreetmap.de.

Please read #23107. TLDR is the code signing companies now require that the certificate be stored in a FIPS 140-2 compliant hardware device.

[Gubaer]

I see, thanks!

[Gubaer]

Just out of curiosity: The root CA key for your root CA CN=Stoecker.eu Root Certificate 2023, C=DE, ST=Germany, L=Bischofswerda, O=Stoecker.eu/emailAddress=cert@dstoecker.de is stored in a FIPS 140-2 compliant hardware device? Which type/brand?

[taylor.smock]

Replying to Gubaer:

Just out of curiosity: The root CA key for your root CA [...] is stored in a FIPS 140-2 compliant hardware device? Which type/brand?

AFAIK, it is not stored on a hardware device. stoecker would know more.
The root CA for the key we are currently using is self-generated, which means it is highly unlikely to ever get into the stock CA list. I won't say that will never happen, but the odds are close to zero.

[Gubaer]

AFAIK, it is not stored on a hardware device. stoecker would know more.

That's why I was asking. I would like to know more about it because such a device cannot cost too much in the context of a private sysadmin and an OS project. It could be attractive for me, too :-)

I guess the CN=Stoecker.eu Root Certificate 2023, C=DE, ST=Germany, L=Bischofswerda, O=Stoecker.eu/emailAddress=cert@dstoecker.de is managed in the file system using openssl. In this case, the CAs and the code signing keys are probably kept in the file system too.

[stoecker]

Answering the questions without reference:

• I use my own CA, because I anyway use my own CA for other purposes. I simply generated two code signing certs with it.
• Trust will not be given to the CA, but to the invidual signing certs via manual exceptions, so again the CA doesn't mean much.
• The CA itself is not network-stored, but as it's not official that makes no big difference.
• In my opinion even a self-made CA should be a real entity and not some virtually non-existing "JOSM organization".
• Signing certs are normal openssl generated files and kept on the disk to be usable when required
• We investigated officialy certs for 2 months and the current result is: Expensive (up to 4 times of before) and not really useful anymore for the required purpose.

[brycenesbitt]

I'm here for a certificate error from OpenWebStart.
More details says:

Version 3
Serial 8987037773214364425749078634563074239981186615
Signature Algorithm SHA512withRSA
Issuer EMAILADDRESS=cert@…, O=Stoecker.eu, L=Bischofswerda, ST=Germany, C=DE, CN=Stoecker.eu Root Certificate 2023
Validity Validity: [From: Mon Nov 20 10:31:50 PST 2023,

To: Tue Aug 14 11:31:50 PDT 2040]

Subject EMAILADDRESS=cert@…, O=Stoecker.eu, L=Bischofswerda, ST=Germany, C=DE, CN=Stoecker.eu Root Certificate 2023
Signature 0000: 94 B8 72 1C F0 8F 40 07 52 D5 00 A8 2A A7 C4 76 ..r...@.R...*..v
0010: 72 98 2C 77 1D 52 49 81 CD 22 C1 F3 1C 67 ED 07 r.,w.RI.."...g..
....
01F0: 83 87 C5 D2 3E 29 3A 08 40 38 9C 69 CE D7 2C 7C ....>):.@…..,.

MD5 Fingerprint 28:BD:A4:F3:EA:74:75:1B:31:C0:93:B6:7D:BD:B9:17
SHA1 Fingerprint FE:16:22:6A:43:94:2F:38:98:A0:2E:44:7B:51:5C:C8:C6:76:0D:FE

[stoecker]

As the ticket and the startup page says you have to accept it. We don't have a commercial cert anymore.