I'm working on a web application, which is packaged in an an Ear, and is distributed to various locations around the world. To handle automatic logins via user smartcards, we're now integrating in a third party applet. If I understand correctly, with the new security restrictions, the applet needs to be signed with the certificate of the server that the Ear is installed to. That means the installer would have to pull the applet out of the Ear file, sign it, and get it back in the Ear. Is there a best practice for this? Or even better, some kind of tool to automate it?
Well, sometimes no answer is an answer in itself. I figured from the lack of replies that my question must be nonsensical in some way, so I pursued it with the third party and some research. In fact, the third-party app was unsigned only because it was still in development. Now the third-party has signed with a trusted certificate, so it doesn't need to be manually signed for each server it is installed on.
So thanks for ... nothing! It turned out to be very useful information.
I was going to answer, but then I reread your premise and decided my answer wouldn't fit.
However let me tell you about my experience with signed applets.
We had an applet we wanted our customers to use, so naturally we got the Java code signing kit from Verisign, our certificate supplier. The signed applet worked for our customers just fine... until we tried to serve the applet from an HTTPS page. Then we started getting confusing messages about certificate errors. Evidently there was a conflict between the code-signing and the site certificate, even though they came from the same supplier. So we stopped using HTTPS for that application and everything worked fine again.
Fast forward a couple of years, when our applet signing was about to expire. I went through the signing process all over again -- this was a couple of years later so I was a beginner again. But this time I called Verisign for help and they pointed me to a page where I was supposed to make an extra step which somehow linked the signed applet's certificate with the site's certificate. I didn't remember doing that the first time. Anyway the new signed applet worked just fine in HTTP pages. I wanted to try it in HTTPS pages, but since that would have been testing in production and everybody was happy with using HTTP, I didn't. My guess is that it would have worked in HTTPS pages as well.
I don't think that the recent security changes in Java 7 affect this issue, though.
So, the relevance to you: if your sites plan to serve the signed applet via HTTPS, they might run into the problem that we had.
I'm sorry I can't remember the technical term for the certificate which linked our applet to the site certificate. Getting appointed to be an applet security expert every two years doesn't actually build any expertise. I'm not surprised that the state of Internet security is so bad, when the security tools are so hard for even experienced people to understand.
My brain just coughed up another piece of information -- the mysterious certificate I had to apply to the signed applet was Verisign's, not my company's. I never had access to my company's site certificate. So what you originally said:
the applet needs to be signed with the certificate of the server that the Ear is installed to
isn't correct. Which it sounds like you already figured out.
Yes, that's what I figured out. The applet I originally received had to be signed by server certs, but only because it hadn't yet been signed by a trusted authority. The test servers are all running self-signed certificates, which each client has to explicitly trust. Now that the applet has been signed by its third-party creator, the logistics of deployment are much easier.
We haven't hit the https problems you mentioned, and all access to our application is via https. Strange, but I'll keep an eye out for it anyway. I hadn't really given much thought to the applet cert expiring either, so there's another thing to get into the release notes. Thanks!