JDK-8238452 : Keytool generates wrong expiration date if validity is set to 2050/01/01
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7,8,11,14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-02-04
  • Updated: 2020-06-09
  • Resolved: 2020-02-26
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 11 JDK 13 JDK 14 JDK 15 JDK 7 JDK 8 Other
11.0.8-oracleFixed 13.0.4Fixed 14.0.1Fixed 15 b12Fixed 7u271Fixed 8u261Fixed openjdk8u262Fixed
Related Reports
Relates :  
JDK-8240988 - Incorrect copyright header in CertificateValidation.java
Description
Keytool has an option that user can give the validity number of days for the
generated certificate.  With configuring validity so that the expire date is
between 2050/01/01 00:00 and 2050/01/01 07:59 (UTC), the expire date in the
certificate comes to 1950/01/01.

Steps to reproduce :

1. Create certificate
$ keytool -genkey -alias test -keyalg RSA -keysize 512 -keypass changeit
-validity 10924 -storetype JKS -keystore mykeystore -storepass changeit
-dname 'cn=xxx.yyyy.zzz, ou=Vvv, o=Www, c=JP'

10924 is the days from 2020/02/04 10:00 to 2050/01/01 10:00.  The value needs
to be changed in line with the day and timezone.

2. Check certificate
$ keytool -list -v -storepass changeit -keystore mykeystore

In generated certificate 'valid from' field will contain the wrong value.

Expected Value :
  Valid from: Tue Feb 04 10:05:50 JST 2020 until: Sun Jan 01 10:05:50 JST 2050
Actual Value :
  Valid from: Tue Feb 04 10:05:50 JST 2020 until: Sun Jan 01 10:05:50 JST 1950
Comments
Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
02-06-2020
Fix Request (8u) Fixes the keytool problem and keeps codebases in sync (I see 8u261). Patch does not apply cleanly to 8u due to minor conflicts. 8u RFR (reviewed by phh): https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011390.html
23-03-2020
Fix Request (11u) Fixes the keytool problem and keeps codebases in sync (I see 11.0.8-oracle). Applies cleanly to 11u, new test fails without the patch, passes with it. Patched JDK passes tier1.
18-03-2020
Fix Request (14u) Certificate generates with wrong expire date without this patch if the validity configured will set that the expire date is between 2050/01/01 00:00 and 2050/01/01 07:59 (UTC) . Patch applies cleanly to 14u and test case is also covered.
28-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/c27d95f72ba8 User: coffeys Date: 2020-02-26 15:18:01 +0000
26-02-2020
Thanks Max. I'm in the process of writing test case.
25-02-2020
Brilliant investigation. I can contribute a regression test if you like.
25-02-2020
Issue was introduced with fix for https://bugs.openjdk.java.net/browse/JDK-4086008 in jdk-1.2. In the fix YR_2050 variable which is introduced to check if the date is JAN01 00:00 2050 GMT has been set to wrong value JAN01 00:00 2050 PST. In certificate notBefore and notAfter time are set to either UTC or Generalized time depending on whether time is less than YR_2050 or greater. Since the value of YR_2050 is set wrongly , there is an issue in certificate time also.
25-02-2020