Red Hat Bugzilla – Bug 1467189
keytool says "Input not an X.509 certificate" when importing a cert
Last modified: 2017-08-16 12:59:28 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 OK [root@pvm-hokuda-rhel6 ~]# [root@pvm-hokuda-rhel6 ~]# openssl x509 -text -noout -in ca.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: ... ... Signature Algorithm: sha256WithRSAEncryption ... xx:xx:xx:xx [root@pvm-hokuda-rhel6 ~]# Version-Release number of selected component (if applicable): 1.7.0.141-2.6.10.1.el6_9 and 1.7.0.131-2.6.9.0.el6_8 1.7.0.121-2.6.8.1.el6_8 does not show the exception. How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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: ~~~ 8.1.3.3 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 8.1.3.4) or the long form (see 8.1.3.5) as a sender's option. 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
And I'm wrong. DER rules specify smallest number of octets should be used: 10 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. 10.1 Length forms The definite form of length encoding shall be used, encoded in the minimum number of octets. [Contrast with 8.1.3.2 b).]
I'll look into this after the imminent security update.