Bug 848742

Summary: Certification file name is incorrect when doing auto-subscribe on RHEL 5.9 client/server i386
Product: Red Hat Enterprise Linux 5 Reporter: gaoshang <sgao>
Component: python-rhsmAssignee: candlepin-bugs
Status: CLOSED ERRATA QA Contact: Entitlement Bugs <entitlement-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.9CC: alikins, awood, bgollahe, bkearney, khong, liliu, syeghiay
Target Milestone: betaKeywords: TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-rhsm-1.0.6-1.el5 Doc Type: Bug Fix
Doc Text:
Cause: Arbitrary bit length certificate serial numbers were not supported. Consequence: Certificates could be created with incorrect file names. Fix: Support arbitrary length certificate serial numbers. Result: Certificates are created with the correct file name.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-08 07:17:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 771748    
Attachments:
Description Flags
cert file
none
cert file 2
none
cert files none

Comment 1 RHEL Program Management 2012-08-16 11:57:13 UTC
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.

Comment 2 gaoshang 2012-08-17 05:53:59 UTC
I have also checked against the RHEL 5.9 Server with the same build, but the issue dose NOT happen.

Comment 3 gaoshang 2012-08-17 09:45:46 UTC
I have double-checked this issue again and find this bug also can just be reproduced on RHEL 5.9 Server i386 and RHEL 5.9 Client i386, but it does NOT happen to RHEL 5.9 Server x86_64 and RHEL 5.9 Client x86_64, so I doubt it is related to arch and it's a i386 special issue.

Comment 4 Adrian Likins 2012-08-22 14:13:48 UTC
Are the certs that got written as the -1-key.pem/-1-cert.pem available?

Comment 5 gaoshang 2012-08-23 02:54:33 UTC
(In reply to comment #4)
> Are the certs that got written as the -1-key.pem/-1-cert.pem available?

The certs are not available. It can not unsubscribe in GUI. Following error dialog show up: "Entitlement Certificate with serial number -1 could not be found." But with command "subscription-manager unsubscribe --all", I can unsubscribe.
Attached the cert files

Comment 6 gaoshang 2012-08-23 02:57:34 UTC
Created attachment 606435 [details]
cert file

Comment 7 gaoshang 2012-08-23 03:14:09 UTC
Created attachment 606436 [details]
cert file 2

Failed to upload cert file "-1-key.pem" directly, so I compressed it. please decompress it with command "tar -zxvf key2.tar.gz"

Comment 8 gaoshang 2012-08-23 03:18:47 UTC
Created attachment 606437 [details]
cert files

Comment 9 Li Bin Liu 2012-08-27 06:14:14 UTC
Hi James,

 This bug is always blocking the Alpha build test, would you pls help take a look and resolve the issue asap? Thanks!

Comment 10 James Bowes 2012-08-28 20:18:53 UTC
fixed in master, 09e8c89c4ab865f

should be in python-rhsm 1.0.6

Comment 13 gaoshang 2012-08-29 06:36:12 UTC
This bug has been verfied and passed on 5.9 client 386

Comment 14 gaoshang 2012-08-29 06:40:59 UTC
This bug has been verfied and passed with python-rhsm-1.0.6-1.el5 on RHEL 5.9 client i386.

Comment 17 gaoshang 2012-08-30 10:41:48 UTC
On RHEL 5.9 client i386 with python-rhsm-1.0.6-1.el5, verified the issue as per the above steps and can get cert files with correct name under /etc/pki/entitlement/ as below:
#ls /etc/pki/entitlement/
3729695934511236014-key.pem 3729695934511236014.pem 

So marked this bug status as verified.

Comment 19 errata-xmlrpc 2013-01-08 07:17:28 UTC
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