Bug 1467189 - keytool says "Input not an X.509 certificate" when importing a cert
keytool says "Input not an X.509 certificate" when importing a cert
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.7.0-openjdk (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Andrew John Hughes
BaseOS QE - Apps
Depends On:
  Show dependency treegraph
Reported: 2017-07-03 02:53 EDT by Hisanobu Okuda
Modified: 2017-08-16 12:59 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-16 12:59:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hisanobu Okuda 2017-07-03 02:53:16 EDT
Description of problem:
I have a customer who is seeing the following exception:

[root@pvm-hokuda-rhel6 ~]# keytool -v -importcert -keystore mystore.jks -alias ca -storepass testing -file ca.pem 
keytool error: java.lang.Exception: Input not an X.509 certificate
java.lang.Exception: Input not an X.509 certificate
        at sun.security.tools.keytool.Main.addTrustedCert(Main.java:2537)
        at sun.security.tools.keytool.Main.doCommands(Main.java:992)
        at sun.security.tools.keytool.Main.run(Main.java:337)
        at sun.security.tools.keytool.Main.main(Main.java:330)
[root@pvm-hokuda-rhel6 ~]# 

As far as confirmed by openssl, the CA certificate is valid:

[root@pvm-hokuda-rhel6 ~]# openssl verify ca.cer.pem
ca.cer.pem: C = xx, O = xxx, OU = xxx, CN = xxxx Certification Authority
error 18 at 0 depth lookup:self signed certificate
[root@pvm-hokuda-rhel6 ~]# 
[root@pvm-hokuda-rhel6 ~]# openssl x509 -text -noout -in ca.pem
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: ...
    Signature Algorithm: sha256WithRSAEncryption
[root@pvm-hokuda-rhel6 ~]# 

Version-Release number of selected component (if applicable): and does not show the exception.

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 4 Chris Dolphy 2017-07-03 15:42:26 EDT
The appears to be a specification violation.

The issue occurs when trying to parse this section:

A3 81 24

81 indicates it's long form (multi-byte) and a single byte.  Then 24 is the length.

The check that leads to "DerInputStream.getLength(): Should use short form for length" checks for long form length octet that has a value less than 127 and rejects it because it should have used short form (single-byte).

However, according to spec whether to use long form or short for is at sender's option:

For the definite form, the length octets shall consist of one or more octets, and shall represent the number of octets in the contents octets using either the short form (see or the long form (see as a sender's
NOTE – The short form can only be used if the number of octets in the contents octets is less than or equal to 127.

The disclaimer at the end doesn't mean that short form must be used if the length is less than 127, but that the short form only is possible with values less than 127.  

[1] https://www.itu.int/rec/T-REC-X.690-201508-I/en
Comment 5 Chris Dolphy 2017-07-03 16:02:27 EDT
And I'm wrong.  DER rules specify smallest number of octets should be used:

Distinguished encoding rules The encoding of a data values employed by the distinguished encoding rules is the basic encoding described in clause 8,
together with the following restrictions and those also listed in clause 11.

Length forms
The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with b).]
Comment 6 Andrew John Hughes 2017-07-03 23:16:41 EDT
I'll look into this after the imminent security update.

Note You need to log in before you can comment on or make changes to this bug.