We have often seen applications that include some class libraries that happen to be signed. The application themselves do not use code signing for security reasons. However, classes from such signed libraries are excluded from the CDS archive, leading to slower start-up time.

We should try to include such signed classes in CDS to improve start-up time.

=============

Currently, signed classes are excluded from the CDS archive in here:

https://github.com/openjdk/jdk/blob/ffa35d8cf181cfbcb54497e997dbd18a9b62b97e/src/hotspot/share/classfile/systemDictionaryShared.cpp#L281-L286

  if (k->signers() != nullptr) {
    // We cannot include signed classes in the archive because the certificates
    // used during dump time may be different than those used during
    // runtime (due to expiration, etc).
    return warn_excluded(k, "Signed JAR");
  }

This comment was based on misunderstanding of how code signing works:

- One concern was that if the certificate used to sign a class has expired, then a SecurityException may need to be thrown during java.lang.ClassLoader::loadClass(). Such behavior may not be easy to replicate inside the CDS class loading code.

- Another concern was that the certificate used to validate the class signature may be obtained from a location outside of the JAR file. I.e., is it possible to say "ignore all certificates stored in the JAR file; use these certificates instead to validate the code signatures"??

For simplification, we decided to exclude all signed classes for simplification.

==================

As shown in the attached test case (SignerTest.java), ClassLoader::loadClass() does not seem to check for certificate expiration.

Also, it might be true that code signatures are checked only with the certificates stored in the JAR file?

[UPDATE]
https://docs.oracle.com/javase/8/docs/technotes/guides/security/time-of-signing.html

"Prior to Java SE 5.0, the signature generated by jarsigner contained no information about when 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 Java SE 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 Java SE 5.0 to allow applications to obtain the timestamp information."

https://stackoverflow.com/questions/35729788/what-happens-if-the-certificate-of-a-signed-jar-with-timestamp-expires

"Prior to Java 5 SE, signed jar's whose signing certificate had expired would no longer be valid or usable.

With Java 5 SE and greater, signed jar's whose signing certificate expires will continue to work. The expired certificate, however, can not be used to sign any further jar's."

However, according to
https://blogs.oracle.com/java/post/understanding-why-java-signed-code-needs-to-be-re-signed-periodically-even-if-time-stamped

"Time-stamping can greatly extend the valid lifetime of signed code, sometimes for long enough that the code is no longer used, but if signed code remains in use long enough it will eventually need to be re-signed.

Expiration dates are only one of the reasons why a signature may no longer be trusted. The certificates involved in code signing or time-stamping may be revoked if they are compromised, or the algorithms used for creating them may be cracked before the certificate expires. Anything that voids the code-signing certificate will affect the code’s signature. Anything that voids the time-stamping certificate will void the time-stamp."