Community
Participate
Working Groups
I am not very knowledgeable of the topic domain, but am opening this bug to close the loop on some discussions taking place on orbit-dev list. Hopefully others can chime in, if there's questions. The issue is that there are some third party bundles that are security related, and have been signed by an "industry standard" signing certificate, JCE. These bundles consist of an API and an Implementation. To be valid, they both must be signed by this JCE certificate. Some of my web searches may be 'out of date', that is, there could be more recent references, but I get the impression it is not hard to get one of these (in terms of time or expense?) http://stackoverflow.com/questions/1756801/how-to-sign-a-custom-jce-security-provider And more technical details are at http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6 Our goal, in Orbit, is to "re-sign" some third party bundles, so that we can more easily tweak some names and data of these third party bundles, to conform to Eclipse and Orbit's requirements or conventions. It may be possible we can provide these bundles 'as is', already signed by the third party, ... but ... my intuition is this would be more difficult than re-signing them, with our own certificate. Not to mention, I think more "accurate", in that these bundles would then show as signed by "JCE from Eclipse Foundation" (I think) rather than generic JCE or JCE from someone else? I realize this is a bit vague of a request, but wanted to "get the ball rolling" and see if there was an opportunity here?
Oracle's instructions how to order a JCE signing certificate http://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate-361306.html
(In reply to Matthias Sohn from comment #1) > Oracle's instructions how to order a JCE signing certificate > http://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate- > 361306.html Thanks, Matthias. I find that one "caution" paragraph confusing: = = = = = IMPORTANT NOTE: Oracle does not issue general code-signing certificates for applet or Web Start deployment. The process described here is only for obtaining certificates for use with the Java Cryptography Extensions framework. A certificate received from this process will not work for anything other than authenticating JCE providers to the JCE framework (that is, the certificate will not work for deployment purposes.) ... = = = = I assume the "will not work for deployment purposes" refers only to the "applet" and "web start" aspects ... I assume the certificate obtained can be used for "production quality and deployment of JCE providers" (just not applets, etc.)
(In reply to David Williams from comment #2) > (In reply to Matthias Sohn from comment #1) > > Oracle's instructions how to order a JCE signing certificate > > http://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate- > > 361306.html > > Thanks, Matthias. I find that one "caution" paragraph confusing: > = = = = = > IMPORTANT NOTE: Oracle does not issue general code-signing certificates for > applet or Web Start deployment. The process described here is only for > obtaining certificates for use with the Java Cryptography Extensions > framework. > > A certificate received from this process will not work for anything other > than authenticating JCE providers to the JCE framework (that is, the > certificate will not work for deployment purposes.) > > ... > = = = = > I assume the "will not work for deployment purposes" refers only to the > "applet" and "web start" aspects ... I assume the certificate obtained can > be used > for "production quality and deployment of JCE providers" (just not applets, > etc.) that's also my understanding
Since our CQs for the bouncycastle libraries are approved now https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9552 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9553 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9554 I'd like to add these libraries to Orbit now. We had to remove some classes from the bouncycastle JCE provider bcprov-jdk15on.jar due to legal issues so we need the JCE signing certificate in order to re-sign the modified library for adding it to Orbit so that we can redistribute it with JGit. So could the foundation order an JCE signing certificate and make it available on build.eclipse.org ?
Once we issue a CSR we'll be asked to sign and fax this document: http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/2138834.pdf Since this involves cryptography and export control, I will consult with Legal.
Since this is "moving along" now, I have opened Orbit bug Bug 478088 - Need change of build process to sign some jars with JCE certificate The process we use in Orbit, depends on the process defined by the Eclipse Foundation, but I would imagine something for the "batch zip-file" process where we'd simply put the jars/zip in another directory, defined for the JCE signature. I think the CBI maven jar-signer already has the ability to specify a different URL/port for signing ... so assume JCE made available via some other port, and any bundle needing that, simply override the "standard" url/port in their individual pom file. But, will add Mikael for confirmation and awareness. One slight uncertainty -- perhaps you, Matthias, know -- is how this plays with a "signed jar" certificate. Off hand, I would assume it is "the same thing", just a little more special -- that is, the jar does not have to be signed twice, once with a jar signing certificate, and once with the JCE certificate. And that any thing in the rest of our code that's checking for "signed jar" certificate, would see a JCE certificate as also a signed jar certificate. Depending on how that uncertainty is answered, there *might* be some effect on Equinox or p2 installation process? But, if it appears, to equinox and p2, as a normal "signed jar certificate", then it would not impact them at all. But, I'll add Tom and Pascal, just in case they know anything about it, or need some "early warning".
(In reply to David Williams from comment #6) > I think the CBI maven jar-signer already has the ability to specify a > different URL/port for signing ... so assume JCE made available via some > other port, and any bundle needing that, simply override the "standard" > url/port in their individual pom file. But, will add Mikael for confirmation > and awareness. We can setup a new webservice at a different url, e.g. http://build.eclipse.org:31338/jce-sign once we have the JCE certificate. This url can be specified in the maven cbi-jarsign-plugin configuration (either with <configuration> in the pom or with -Dcbi.jarsigner.signerUrl). Orbit can also decide to use the webservice directly (e.g. by using curl). We still have to figure out whether this signing service can be accessed by any committer at eclipse (like the standard signing service) or if it has to be restricted to the Orbit's HIPP.
(In reply to Denis Roy from comment #5) > Once we issue a CSR we'll be asked to sign and fax this document: > http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/2138834. > pdf > > Since this involves cryptography and export control, I will consult with > Legal. Any progress on this ? I have added the bouncycastle libraries to orbit-recipes. Currently the build is failing since eclipse-jarsigner can't sign the original bundles which are already signed with a JCE signature. I pushed a workaround https://git.eclipse.org/r/#/c/67506 stripping the original JCE signatures so that eclipse-jarsigner can sign these bundles until the JCE certificate and corresponding signing service are available.
This has to be put on hold until our new release engineer can set up a signing service.
ping, any idea when this could be tackled ?
Denis, do we have the required JCE certificates in place?
I have not looked at this at all, sorry.
Can we please get this done somewhen in the near future ?
Fred, can you assess what we need to do here? As far as I know, we don't have any other certs other than the code signing cert we use currently.
As discussed, we will need to get a JCE certificate. As mentioned in comment 5 you wanted to consult with legal first.
I am looking into this with Legal.
"Send, via email, the CSR for your Java Cryptography Extension provider" I can produce a CSR using openssl, but since this is Java specific, something tells me the CSR needs to be issued from Java's keytool or even from within Java API http://www.journaldev.com/223/generating-a-certificate-signing-request-using-java-api Fred/Mikael, since you guys will be setting up and running the signing webservice, can you produce the CSR, or is an openssl CSR sufficient?
(In reply to Denis Roy from comment #17) > "Send, via email, the CSR for your Java Cryptography Extension provider" > > I can produce a CSR using openssl, but since this is Java specific, > something tells me the CSR needs to be issued from Java's keytool or even > from within Java API > > http://www.journaldev.com/223/generating-a-certificate-signing-request-using- > java-api > > > Fred/Mikael, since you guys will be setting up and running the signing > webservice, can you produce the CSR, or is an openssl CSR sufficient? My guess is either keytool or openssl could be made to work, but since the official directions [1] show the use of keytool I would just go with that. [1] https://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6
I have created a CSR and have submitted the request.
Response back: "I noticed that in your description, you have "providers" instead of "provider". One more question: are you applying certificate for signing your own provider or acting as a sub-CA to sign other JCE providers. Only requests for signing their own provider will be accepted."
(In reply to Denis Roy from comment #20) > Response back: > > "I noticed that in your description, you have "providers" instead of > "provider". > One more question: are you applying certificate for signing your own > provider or acting as a sub-CA to sign other JCE providers. > Only requests for signing their own provider will be accepted." Little that I know, I'd say Yes, "provider", The Eclipse Foundation and no -- no sub-CA going on -- we are only signing jars that would normally be signed by the Eclipse Foundation.
Agreed, David. I've forwarded the response.
(In reply to Denis Roy from comment #20) > One more question: are you applying certificate for signing your own > provider or acting as a sub-CA to sign other JCE providers. > Only requests for signing their own provider will be accepted." While we will sign a custom version of bountycastle (a JCE provider), it is not really "our own", just a modified version of https://bouncycastle.org/java.html. Signing a JCE and a jar may be the same technical process, but the process to get the certificates are very different.
"Ok then, Oracle has recently rolled out a new CA that signs certificates using SHA-2 and uses a different Root CA certificate. Would you like us to issue your cert from this new root CA? One thing to be aware of is that this new JCE provider root was added to 8u111/7u121/6u131 so earlier versions of Oracle JDK/JRE would not load your provider if signed by a certificate issued from this new CA. OpenJDK doesn't have this restriction and should load and run your provider, as would the aforementioned Oracle JDK/JRE releases and anything later. Please let us know if you would like to proceed with this new CA." Thoughts?
I think we should stick with a certificate issued from the "old" CA. It may be too restrictive to ask users to use 8u111/7u121/6u131 or later. Matthias, you are the targeted primary user, what do you think?
(In reply to Mikaël Barbero from comment #25) > I think we should stick with a certificate issued from the "old" CA. It may > be too restrictive to ask users to use 8u111/7u121/6u131 or later. > > Matthias, you are the targeted primary user, what do you think? yes, let's stick to a certificate issued by the old CA so we don't impose additional restrictions on our users which Java version they need to have. JGit requires Java 8 since 4.6 (latest release is 4.8)
Response sent. Thanks
The completed certification form has been sent. http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/2138834.pdf
thanks a lot, finally we are making progress :)
We've got the signed certificate, now to create a signing service.
nice, I owe you a beer at EclipseCon Ludwigsburg
The slow process is on me. We've been having the certificate for quite some time now, but the bug slipped through my watch. To offer the signing capability, we need to expose a new URL but the service will be basically the same as https://wiki.eclipse.org/IT_Infrastructure_Doc#Web_service_.28Instant.29 I would propose http://build.eclipse.org:31338/jce-signing-service curl -o signedfile.jar -F file=@unsigned-jar.jar http://build.eclipse.org:31338/jce-signing-service
+1
+1 could we then call this new service in the orbit-recipes Tycho build using eclipse-jar-signer maven plugin and setting cbi.jarsigner.signerUrl=http://build.eclipse.org:31338/jce-signing-service ?
(In reply to Matthias Sohn from comment #34) > +1 > > could we then call this new service in the orbit-recipes Tycho build using > eclipse-jar-signer maven plugin and setting > cbi.jarsigner.signerUrl=http://build.eclipse.org:31338/jce-signing-service ? Yes, this is goal. Will keep you posted as soon as the service is up and running (should be on Wed. at worst).
I'm a bit late with that. I'm still confident to have this done by end of the week. Thanks for your patience.
You can now sign jars with a JCE certificate by using the following URL http://build.eclipse.org:31338/api/sign/jce Note that you still need to sign your jar with the standard certificate as well. JCE certificates are not general purpose code signing ones. Unfortunately, there is still an issue today: both our certificates have the same short name. Thus, the signature files will be overridden by the last one used. I will fix that early next week. You can already play with this today.
(In reply to Mikaël Barbero from comment #37) > Unfortunately, there is still an issue today: both our certificates have the > same short name. Thus, the signature files will be overridden by the last > one used. I will fix that early next week. You can already play with this > today. This is fixed. You can know sign jar with a JCE certificate by using the http://build.eclipse.org:31338/api/sign/jce service URL
(In reply to Mikaël Barbero from comment #37) > You can now sign jars with a JCE certificate by using the following URL > > http://build.eclipse.org:31338/api/sign/jce > > Note that you still need to sign your jar with the standard certificate as > well. JCE certificates are not general purpose code signing ones. How can I sign the same jar twice using the eclipse-jarsigner-plugin ? And in which order should I do this double signing ? Here is the change trying to sign bcprov using JCE signing service https://git.eclipse.org/r/#/c/119370/
the corresponding test build including maven debug log is currently running here https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/563/console This build log (it's huge) can be downloaded using $ curl -O https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/562/consoleText
pasted the wrong URL, this is the correct build log URL $ curl -O https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/563/consoleText
(In reply to Matthias Sohn from comment #39) > How can I sign the same jar twice using the eclipse-jarsigner-plugin ? > And in which order should I do this double signing ? > > Here is the change trying to sign bcprov using JCE signing service > https://git.eclipse.org/r/#/c/119370/ You need to define 2 executions with 2 different configurations: <plugin> <groupId>org.eclipse.cbi.maven.plugins</groupId> <artifactId>eclipse-jarsigner-plugin</artifactId> <version>1.1.4</version> <executions> <execution> <id>sign</id> <phase>package</phase> <goals> <goal>sign</goal> </goals> <configuration> <resigningStrategy>OVERWRITE</resigningStrategy> <signerUrl>http://build.eclipse.org:31338/sign</signerUrl> </configuration> </execution> <execution> <id>sign-jce</id> <phase>package</phase> <goals> <goal>sign</goal> </goals> <configuration> <resigningStrategy>OVERWRITE</resigningStrategy> <signerUrl>http://build.eclipse.org:31338/api/sign/jce</signerUrl> </configuration> </execution> </executions> </plugin> This is only needed in bouncycastle/pom.xml, you can keep your releng/mavenparent/pom.xml file untouched.
(reopening)
(In reply to Mikaël Barbero from comment #42) > (In reply to Matthias Sohn from comment #39) > > How can I sign the same jar twice using the eclipse-jarsigner-plugin ? > > And in which order should I do this double signing ? > > > > Here is the change trying to sign bcprov using JCE signing service > > https://git.eclipse.org/r/#/c/119370/ > > You need to define 2 executions with 2 different configurations: > > <plugin> > <groupId>org.eclipse.cbi.maven.plugins</groupId> > <artifactId>eclipse-jarsigner-plugin</artifactId> > <version>1.1.4</version> > <executions> > <execution> > <id>sign</id> > <phase>package</phase> > <goals> > <goal>sign</goal> > </goals> > <configuration> > <resigningStrategy>OVERWRITE</resigningStrategy> > <signerUrl>http://build.eclipse.org:31338/sign</signerUrl> > </configuration> > </execution> > <execution> > <id>sign-jce</id> > <phase>package</phase> > <goals> > <goal>sign</goal> > </goals> > <configuration> > <resigningStrategy>OVERWRITE</resigningStrategy> > <signerUrl>http://build.eclipse.org:31338/api/sign/jce</signerUrl> > </configuration> > </execution> > </executions> > </plugin> > > This is only needed in bouncycastle/pom.xml, you can keep your > releng/mavenparent/pom.xml file untouched. How is that going to work? Wouldn't resigningStrategy OVERWRITE for the second jce signing overwrite signing of the previous signing step ? Any idea how to configure that using profiles ? Can I put the same profile defined in mavenparent/pom.xml and bcprov/pom.xml with different configuration ?
> How is that going to work? Wouldn't resigningStrategy OVERWRITE for the > second jce signing overwrite signing of the previous signing step ? Indeed, it's a stupid copy/paste. > Any idea how to configure that using profiles ? Can I put the same profile > defined in mavenparent/pom.xml and bcprov/pom.xml with different > configuration ? My best idea to handle you use case would be to keep your parent pom as-is (ie as on master, without introducing jarsigner.signerUrl property), and just modify org.bouncycastle.bcprov_1.52.0/pom.xml, adding <build> <plugins> <plugin> <groupId>org.eclipse.cbi.maven.plugins</groupId> <artifactId>eclipse-jarsigner-plugin</artifactId> <version>1.1.4</version> <executions> <execution> <id>sign-jce</id> <phase>package</phase> <goals> <goal>sign</goal> </goals> <configuration> <signerUrl>http://build.eclipse.org:31338/api/sign/jce</signerUrl> </configuration> </execution> </executions> </plugin> </plugins> </build> both executions (sign and sign-jce) should execute. I'm not able to say out of the box in which order, and then which one needs the OVERWRITE resigningStrategy. Printing the effective pom for org.bouncycastle.bcprov_1.52.0/pom.xml with the command "mvn help:effective-pom" should help you find the order (plugin are executed in the order they are defined in the <build/plugins> section of the effective pom).
Ok, I configured that and configured the orbit gerrit validation job to sign this build. This fails with the following error https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/569/console [WARNING] [Wed Mar 21 19:12:02 EDT 2018] HTTP request failed. HTTP Error 500 (reason: Server Error) HTTP Error 500 Problem accessing '/jar-signing-service' Reason: Server Error Caused by: java.io.IOException: The '/usr/java/jdk1.8.0_51/bin/jarsigner' command exited with value '1' '/usr/java/jdk1.8.0_51/bin/jarsigner' output: jarsigner: unable to open jar file: /tmp/jce-jar-signing/SigningServlet-1713966440573346507-org.bouncycastle.bcprov-1.52.0-SNAPSHOT.jar at org.eclipse.cbi.webservice.signing.jar.JarSigner.signJar(JarSigner.java:231) at org.eclipse.cbi.webservice.signing.jar.SigningServlet.doSign(SigningServlet.java:66) at org.eclipse.cbi.webservice.signing.jar.SigningServlet.doPost(SigningServlet.java:54) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:860) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ...<troncated output>... For complete output, see '/jobs/genie.orbit/gerrit-orbit-recipes/workspace/bouncycastle/org.bouncycastle.bcprov_1.52.0/target/org.bouncycastle.bcprov-1.52.0-SNAPSHOT.jar-8640549432963972734-RemoteJarSigner.log' is the signing service down or is this a problem on my end in https://git.eclipse.org/r/#/c/119370/ ?
The signing service is not down. I'm looking into it.
Closing.
Does anyone know what the new path is for the JCE signing (previously http://build.eclipse.org:31338/api/sign/jce ) ? I've tried https://cbi.eclipse.org/api/sign/jce but that doesn't seem to be it.
URL is https://cbi.eclipse.org/jarsigner/jce/sign
@Roland The certificate expired on Apr 25 07:00:00 2020 GMT though. Do you need a new one? If so, please reopoen this ticket. Thanks!
I think we need a new signing certificate otherwise we can't sign the bouncycastle JCE provider anymore so that Java accepts it as a JCE provider
@Denis, would you mind issuing a new CSR as you did in comment #19? Thanks.
Is this still the correct process to follow? https://www.oracle.com/java/technologies/javase/getcodesigningcertificate.html @Mikael In the past I've used the keystore on build.e.o to issue code signing CSRs. Is there a better place to do that now?
(In reply to Denis Roy from comment #54) > Is this still the correct process to follow? > https://www.oracle.com/java/technologies/javase/getcodesigningcertificate. > html looks like this is still correct
(In reply to Mikaël Barbero from comment #53) > @Denis, would you mind issuing a new CSR as you did in comment #19? Thanks. I've sent instructions via email.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/195.
