Rewrite profile and JavaPatcher settings question about signed Java applets

Answer and reply from another forum

 

Answer:

 

If the F5 is to rewrite & modify the java applet, then it must also strip off the original signature, as the rewritten applet will no longer match the signature from when you signed it. This is the point of signing code, to make sure no one can modify it, without being noticed. By using a java rewrite profile, you're telling the F5 to modify the applet. It must either re-sign the applet or strip the original signature and leave it unsigned.

 

You should still sign your code, note that the "Trusted Certificate Authorities" is where you would place your current code cert/ca, so the F5 only modifies applets signed by a trusted CA. The Signer & Signer Key are where you'd put (either the same, or ideally a new) signing cert & key so the F5 can re-sign the applet after modification. Some details here: https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-portal-access-11-5-0/5.html

 

The F5 is a generally considered a trusted security device, it likely contains all of your TLS/SSL certificates & keys used for HTTPS. I'm not sure why you'd trust it for that but not trust it for code signing keys.

 

Reply from OP:

 

It appears to me though, that the virtual server requires you to add a rewrite profile, as you get an error saying that if you have a portal access link with Java Patching enabled, the virtual server requires a signed applet.

 

Should the applet already be technically "secure" if it has been signed already. Would it not be the admins job be to ensure the applet they are uploading is already properly signed?

 

If the Applet was developed in-house, this process makes sense.

 

However if you buy an applet, and to use it in the F5, you need to provide your own code signing certificate that would raise 2 concerns. The first being the applet could be malicious anyway. Say for example it was intercepted in transit from the Vendor to the end customer and modified by say the reseller. The reseller could simple strip the code signing certificate and modify the applet.

 

The 2nd concern is that by requiring the customer to buy their own code signing certificate would make our solution more of a burden, requiring certificate management as well as the cost of maintaining the certificate.

 

There is no point for the vendor to provide a code signing certificate to the customer. The vendor would either have to create unique code signing certificates per customer or give the customer their own code signing certificate a private key. The latter is the obvious worst choice. I guess technically a reseller could provide the code signing certificate for their customers, but you still have the issue of the reseller being able to modify the code.

 

This seems to be an oversight. Or at the very least I am missing something big here.