Description of problem: Parsing of customer's X509 candlepin certificates in RHUI's /usr/lib/python2.6/site-packages/rhui/common/certificate.py Extensions class results in the traceback/errors in rhui.log: Unexpected error caught at the shell level Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/rhui/tools/shell.py", line 86, in safe_listen self.listen(clear=first_run) File "/usr/lib/python2.6/site-packages/rhui/tools/shell.py", line 112, in listen Shell.listen(self) File "/usr/lib/python2.6/site-packages/rhui/common/shell.py", line 186, in listen item.func(*args, **item.kwargs) File "/usr/lib/python2.6/site-packages/rhui/tools/screens/entitlements.py", line 104, in new_certificate self.cert_manager.add_certificate(cert_filename) File "/usr/lib/python2.6/site-packages/rhui/tools/cert_manager.py", line 276, in add_certificate if not _is_valid_download_url(e.download_url): File "/usr/lib/python2.6/site-packages/rhui/tools/cert_manager.py", line 301, in _is_valid_download_url if valid_url in download_url: TypeError: argument of type 'NoneType' is not iterable Version-Release number of selected component (if applicable): rh-rhui-tools-2.1.13-1.el6_3.noarch How reproducible: 100% with affected certs Steps to Reproduce: 1. Generate a certificate from RH Customer Portal 2. Check if the certificate will be affected by the bug - "openssl x509 -in <path to .pem> -text -noout" - look for OID values which are solely '..' - x509.as_text() will show it has the value '..\n'. 3. Attempt to 'upload' the certificate to RHUA Actual results: Failure with above traceback Expected results: Successful import Additional info: The issue comes down to the __ext function in the Extensions class which reads: def __ext(self, x509): # get extensions substring text = x509.as_text() start = text.find('extensions:') end = text.rfind('Signature Algorithm:') text = text[start:end] text = text.replace('.\n', '..') return [s.strip() for s in text.split('\n')] Since both '.\n\n' and '..\n' are valid OID values, we have an issue, because the text.replace('.\n', '..') matches both instances, and makes the latter '...\n', this creates an issue in that the next OID may merge into the value for the previous OID. By changing it on the customer's RHUI to text.replace(' .\n', ' ..'), we have worked around the issue for now.
aligned against our 2.1.1 release
patch looks good to me, i can't think of a better way to do it. Thanks for the detailed work debugging this issue. commit cc0c060c832e2f04390196d496690b3e5d1ca07a
Hi, I'm not sure about the test automation here; generating a custom certificate in candlepin is outside of the scope for us and keeping the customer certificate as a test case data doesn't seem appropriate either. Any suggestions? Thanks, milan
Does the automation test case need to actually verify that the certificate is valid, or just that it will parse correctly? If it doesn't need to be verified, just modify an existing test certificate as this bug describes to exhibit the problem. The certificate won't pass signature validation, but that's not really what needs to be tested here. Other than that, I'm not sure how else to test this via automation. I could probably add a unit test for the __ext method that tests the fix if needed.
OK(In reply to comment #5) > Does the automation test case need to actually verify that the certificate > is valid, or just that it will parse correctly? If it doesn't need to be > verified, just modify an existing test certificate as this bug describes to > exhibit the problem. The certificate won't pass signature validation, but > that's not really what needs to be tested here. > > Other than that, I'm not sure how else to test this via automation. I could > probably add a unit test for the __ext method that tests the fix if needed. I'll try to reproduce with a fabricated cert. If it "works" and I get the same stack as in report, no problem automating... Thanks, milan
[root@rhua ~]# rpm -q rh-rhui-tools rh-rhui-tools-2.1.15-1.el6_3.noarch [root@rhua ~]# rhui-manager cert upload --cert /root/bug876423_testcert.pem The given certificate contains one or more entitlements that are not compatible with the RHUI. For questions, please visit: https://access.redhat.com/support/contact/customerService.html
Created attachment 692849 [details] Reproducer screen log Attaching a reproducer (RHUI 2.1)
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-0571.html