JDK-8074935 : jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u91,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-03-11
  • Updated: 2018-05-03
  • Resolved: 2015-03-23
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 8 JDK 9
8u101Fixed 9 b57Fixed
Related Reports
Duplicate :  
JDK-8146592 - X509Factory throws IllegalArgumentException if parsing error occured
Relates :  
JDK-8158633 - BASE64 encoded cert not correctly parsed with UTF-16
Relates :  
JDK-8202598 - [linux] keytool -certreq inconsistent with platform line.separator
Description
jdk7 keytool used to validate that input pem files were RFC 1421 compliant, but jdk8 keytool no longer does so, which seems like a bug. (but may be intentional; hard to tell)

See http://en.wikipedia.org/wiki/Base64#Privacy-enhanced_mail

SSCCE:

 $ (keytool7=$HOME/jdk/jdk7/bin/keytool keytool8=$HOME/jdk/jdk8/bin/keytool; perl -pe 's/^([A-Za-z])/!\1/' ./test/java/security/cert/CertPathValidator/OCSP/RootCert.pem > /tmp/corrupted.pem; echo 7: ; $keytool7  -printcert -file /tmp/corrupted.pem | head; echo 8: ;  $keytool8  -printcert -file /tmp/corrupted.pem | head -3;)
7:
keytool error: java.lang.Exception: Failed to parse input
8:
Owner: CN=Root CA, O=Sun, C=US
Issuer: CN=Root CA, O=Sun, C=US
Serial number: 0
Comments
There is a JIRA tracking problem. The JIRA entry for JDK-8074935 shows that the backport (JDK-8146876) supposedly went into 8u92/8u101, but looking at the mercurial log for 8u76/8u75, it was clearly introduced in 8u76.
08-06-2016
If you compare http://en.wikipedia.org/wiki/Base64#Privacy-enhanced_mail with http://en.wikipedia.org/wiki/Base64#MIME you can see that it is explicitly more lenient. MIME does not specify a fixed length for Base64-encoded lines, but it does specify a maximum line length of 76 characters. Additionally it specifies that any extra-alphabetic characters must be ignored by a compliant decoder, although most implementations use a CR/LF newline pair to delimit encoded lines. A non-lenient form of Base64 decoding would be useful for ahead-of-time validation, which is what we were using keytool for. But you surely don't want to write yet another Base64 decoder. So this is a regression, but as you say, "mostly harmless".
16-03-2015
This is not intended, but jdk8 uses the new Base64.getMimeDecoder() to decode the content and a MIME decoder always ignores characters not found in the base64 alphabet. I suppose this is harmless.
16-03-2015