Description of problem: rct tool displays the version as blank in cert.pem Version-Release number of selected component (if applicable): [root@dhcp193-98 consumer]# subscription-manager version registered to: 0.7.12-1 server type: subscription management service subscription-manager: 1.0.21-1.el5 python-rhsm: 1.0.9-1.el5 How reproducible: Steps to Reproduce: 1. [root@dhcp193-98 consumer]# rct cat-cert cert.pem +-------------------------------------------+ Identity Certificate +-------------------------------------------+ Certificate: Path: cert.pem Version: Serial: 5035221250512063366 Start Date: 2012-10-08 07:42:56+00:00 End Date: 2028-10-08 07:42:56+00:00 Alt Name: DirName:/CN=dhcp193-98.pnq.redhat.com Subject: CN: 4ee6fd26-731c-4be1-8792-a0db45e103b3 2. 3. Where as when I do openssl x509 -in 'cert.pem' -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 45:e0:b3:0c:b2:45:0b:86 Signature Algorithm: sha1WithRSAEncryption Actual results: Version: Expected results: Version: 3.0 Additional info:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
I agree with Shwetha's observation that openssl shows a Certificate:/ Data:/ Version: value of "3 (0x2)". However, this is not actually the same data point that the rct tool is trying to report as Version. The Version that rct is reporting is either a 1.0 or a 3.0 and is only meaningful in the context of an entitlement cert to the subscription-manager developers. Since Shwetha did a cat-cert on a consumer cert, the blank Version value is actually correct. Unfortuantely the Version reported by rct cat-cert is NOT related to the Certificate:/ Data:/ Version: reported by openssl. This creates a confusing situation. Since the "Version:" label reported by openssl is not going to change, maybe we should consider changing the rct label from "Version: to "system.certificate_version:" to match the fact that the value actually corresponds to. Or, if we were to actually report a value for the consumer cert (and product cert), then the value should be 1.0 since it is not using the Huffman encoding. Not sure what the best choice is. Maybe there should be two entries for Version; one reflects the openssl certificate version, and the other reflects the system.certificate_version.
So, you would like to see Certificate: Cert Version in stead of Certificate: Version?
(In reply to comment #3) > So, you would like to see Certificate: Cert Version instead of Certificate: Version? No because any label that contains "Version" will be confusing to distinguish between the openssl certificate version and the system.certificate_version. That's why I suggested reporting two values. Or, maybe a better idea is to rename "Version" to "Rendition" and change the "system.certificate_version" fact to "system.certificate_rendition". Let's ask others what they think.
(In reply to comment #4) > Or, maybe a better idea is to rename "Version" to "Rendition" and change the "system.certificate_version" fact to "system.certificate_rendition". > > Let's ask others what they think. If we vote for this change, then we should do it now in rhel59. Moving severity to HIGH to make a faster decision.
I vote for leaving it as it is. Using openssl to view the contents of any certificate going forward is going to have near zero utility, since all of our juicy bits aren't readable by it in cert v3. Thus, there is little chance to have any confusion. Now, here is the interesting part! _All_ of the certificates we use (product/identity/entitlement) should have a version field that is printable by RCT. products and id certs should have a version of 1.0, entitlement certs should have a version of 1.0 or 3.0 (at the moment)
https://github.com/candlepin/python-rhsm/pull/36
fix is in python-rhsm commit 5bb0fd44992967ce787b0b9e0b9fa4de0e06cbb0 Author: Adrian Likins <alikins> Date: Tue Oct 9 12:01:24 2012 -0400 863961: set a default version for id certs
Verifying Version... [root@jsefler-rhel59 ~]# rpm -q subscription-manager subscription-manager-1.0.22-1.el5 [root@jsefler-rhel59 ~]# subscription-manager register --username testuser1 --org admin --force Password: The system has been registered with id: ca9a2f2a-7ae5-45a3-a764-855fdfa5886b [root@jsefler-rhel59 ~]# rct cat-cert /etc/pki/consumer/cert.pem +-------------------------------------------+ Identity Certificate +-------------------------------------------+ Certificate: Path: /etc/pki/consumer/cert.pem Version: 1.0 Serial: 3067866120326443039 Start Date: 2012-10-10 16:40:18+00:00 End Date: 2028-10-10 16:40:18+00:00 Alt Name: DirName:/CN=jsefler-rhel59.usersys.redhat.com Subject: CN: ca9a2f2a-7ae5-45a3-a764-855fdfa5886b VERIFIED: The Certificate: Version: now defaults to 1.0 for a consumer cert. Note: This simply means that the certificate does not contain any Huffman encoded/compressed/collapsed data in the x509 certificate OIDs. Do not confuse this version 1.0 with the version observed using openssl: [root@jsefler-rhel59 ~]# openssl x509 -text -in /etc/pki/consumer/cert.pem | grep -i version Version: 3 (0x2)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0039.html