United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6468285 : keytool ability to backdate self-signed certificates to compensate for clock skew

Details
Type:
Enhancement
Submit Date:
2006-09-07
Status:
Closed
Updated Date:
2011-05-16
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
security-libs
OS:
generic
Sub-Component:
java.security
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
2.0
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

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
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.
                                     
2006-09-08
EVALUATION

Will provide a full evaluation later.
                                     
2006-09-11
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.
                                     
2007-08-27
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]
                                     
2007-09-14



Hardware and Software, Engineered to Work Together