Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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).]
Comment 6Andrew John Hughes
2017-07-04 03:16:41 UTC
I'll look into this after the imminent security update.
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: