UCF applet’s certificate expired… ORLY?

Two days ago EMC published a very strange ETA, some quotes:

Impact: SEVERITY RATING: High (Operational Issue)
Impact Description: Many EMC Documentum products have applets which contain code signing certificates from authorities such as Verisign and Thawte. When the certificate reaches its expiration date, users attempting to download the applet to a client machine receive a warning dialog stating that the certificate has expired.
Issue: Users receive a “certificate is expired” warning when downloading applets with an expired certificate on a particular client machine. Certificates are checked for expiration when applets are downloaded for the first time to the client machine. Users can click past the warning, depending on their security settings. In some cases they may be allowed to elect not to see the message again. In other cases, they won’t be allowed to run it at all.
Cause: Code signing certificates for Documentum products expire August 28, 2014. EMC security policies require certificates to be re-signed annually, so users must update applets each year.

The severity is so high that EMC decided to publish this information the day before apocalypses – just in time πŸ™‚ πŸ™‚ πŸ™‚ But stop! Do you really think that guys, who earn money on security, are idiots and didn’t foreknow such situations? Sure they aren’t:

Prior to J2SE 5.0, the signature generated by jarsigner contained no information about w hen the signature was generated. With no other information available, systems/deployers (including users of the Java Plug-in) often based their validity assessment of a signed JAR file on the validity of the signing certificate. When the signing certificate expires, systems/deployers conclude that the signature, and hence, the JAR file, has expired. Because signing certificates typically expire annually, this caused customers significant problems by forcing them to re-sign deployed JAR files annually.

Starting in J2SE 5.0, jarsigner can generate signatures that include a timestamp, thus enabling systems/deployer (including Java Plug-in) to check whether the JAR file was signed while the signing certificate was still valid. In addition, APIs were added in J2SE 5.0 to allow applications to obtain the timestamp information.

In J2SE 5.0, the Java Plug-in was enhanced to check signature timestamps (if available) when validating JAR files. The Java Plug-in will no longer present a dialog when it encounters an expired or revoked certificate when validating a signed jar, provided that the signature timestamp confirms that the signature was generated prior to the expiration or revocation date.

The TSA’s certificate must be available from the Plug-in’s keystore or certificate stores when the Plug-in is validating a JAR file containing a signature timestamp.

2 thoughts on “UCF applet’s certificate expired… ORLY?

  1. Pingback: How to provide backward compatibility with old java clients during UCF updates | Documentum in a (nuts)HELL
  2. Pingback: Silent UCF. HowTo | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s