We have become aware of an warning message that will start appearing on March 9. End users may see this signature error when using the CM System applets. (Warning image attached below.)
The level of security set for browsers will determine if this message pops up. We have a patch available for download to bring the signature up to date. However if the users check the box for trust the content from this publisher’ box, the browser will be set to not display this message again.
We are testing another option to resolving this issue. The option is for you to send us a copy of your production JAR’s and we will sign them and send them back to you. I will post instructions once testing has been completed.
If applying the patch is not possible for you, we can sign your JARS and send them back to you. If interested in this, please make copies of the following JARS and put them in your Percussion ftp directory. (If you don’t have an FTP account please email support for one.)
It is a shame that we have to address this again… However, the Ephox jar’s certificate will expire on May 14th, 2011 and I believe some of the certificates for the jars mentioned (such as help.jar) has already expired. It would be nice if Percussion put these on a calendar so that we have at least a month to implement the patch (going from development to production).
I had requested for replacement jars a month ago and we have a bug number: RX-16789, but have yet to receive the newly signed jars. I had hoped a month’s notice would be ample time to get the new jars, but clearly I was mistaken… I expect we will have to go through the jar signing process (via ftp…as soon as that method is “available” again) as applying a patch this late without testing does not seem prudent.
Since the end of 2008, Percussion has been signing our applet jars to include a TSA timestamp. This ensures that the expiration date of the certificate is valid at the time the jar is signed. As long as the jars are signed with a valid, unexpired certificate, then they can continue to be used without issue after the certificate used to sign them has expired, and users of the applets will not see security warnings. Ephox employs the same practice as well.
Percussion is proactively managing certificates to ensure they are up to date. We re-sign all of our applet jars with each release or patch that includes them using valid, unexpired certificates. Customers that keep up to date with patches and releases will have jars signed by the most up to date certificates. In the event that you are not up to date, rest assured that our software will continue to be secure, and your users will not see security warnings.
Testing this out by changing the date on a Mac (to say May 15th), then editing an item with an ephox field (with Safari) yields in a “Digital Signature could not be verified”, and clicking on the certificate details clearly shows that the certificate has expired. If this behavior is something that we want to teach our end users (to ignore expired certificates) it would be an acceptable solution. We would, of course, prefer to have an unexpired certificate and that the notice be “The digital certificate from “Ephox Corporation” has been verified” (as it will be until May 14) as opposed to the “could not be verified” that will show up over the weekend.
After some investigation we’ve found that while the latest version of Ephox does have a timestamped jar, the version that ships with CM System v6.7 does not, which explains the behavior you saw in your testing. We’ve opened a support issue with Ephox and will update this thread as we know more.
I followed up with Jay on this and here’s what he mentioned.
We were able to get a fix for this from Ephox a year ago - available in the EditLive6_7_5_39 upgrade kit - but it does not appear that it was signed properly when fixed, hence the expiration warnings a year later. Ephox has discontinued development support for EditLive 6.7 so we will not be able to acquire an update. CM System 7.03 has a newer EditLive 7.5 where they have properly signed the applet so the expiration warnings do not occur again. Because of this, upgrading to CM System v7 is recommended to solve the problem. In the meantime, users can select “accept always” on the cert warning.