JDK-6468285 : keytool ability to backdate self-signed certificates to compensate for clock skew
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-09-07
  • Updated: 2017-05-16
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 Other
7 b22Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-6621363 - Backport of 6468285 to 6-open not complete
Description
keytool does not allow the "warping" of time to be able to adjust the validity dates of certificates to deal with clock skew across distributed systems.

There appear to be no public APIs in J2SE allowing this to be done.

nss's 'certutil' does have this feature, it's possible to "warp the clock" to be able to generate certificates with different start dates.

When deploying a distributed application infrastructure across mutliple nodes such as that commonly used by JES, and when configuring this infrastructure to have mutual trust between different nodes by exchanging and inserting public certificates in each other's trust-stores, if there is clock-skew between the nodes there is a window of time in which the certificate of one node is not seen as valid on the other node, since it's validity period is some time in the future due to clock skew.

keytool could permit self-signed certificate generation to set the start date to, say, one day before, to allow for 24 hours of clock skew.

Additionally, when this problem arises, it is hard to diagnose without specific code in place to check clocks, since a TrustManager will simply throw an exception without any explanation as to the problem of validity periods.

This affects users of all Java versions, we, in particular, use Java 5 and Java 6.
Comments
EVALUATION Solution: add a new option "-startdate <startdate>" to specify the issue time of the newly created certificate. Here, the value can be one of these two forms: 1. ([+-]nnn[ymdHMS])+ 2. [yyyy/mm/dd] [HH:MM:SS]
14-09-2007
WORK AROUND Generating backdated keys on a non-production system is probably viable for one-off Internet-facing production systems, but is far less practical for systems that are merely using SSL for internal communications, where the creation and management of the certificate may not even be visible to the user. I don't think ssh uses certificates per se, and so isn't affected by this issue, but imagine the trouble that would be caused if you had to apply this workaround for ssh connections.
27-08-2007
EVALUATION Will provide a full evaluation later.
11-09-2006
WORK AROUND Generating all the key pairs after setting the system clock to a previous date/time, maybe on another machine which is not in the production environment.
08-09-2006