Bug 667122 - Anaconda doesn't work with https enabled repos.
Anaconda doesn't work with https enabled repos.
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Ales Kozumplik
Release Test Team
: 660565 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2011-01-04 09:32 EST by Patrik Martinsson
Modified: 2014-09-30 19:39 EDT (History)
7 users (show)

See Also:
Fixed In Version: anaconda-13.21.87-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-05-19 08:36:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dont know if you need anything from this, but here is a small part from the ks file. (1.33 KB, application/octet-stream)
2011-01-04 09:32 EST, Patrik Martinsson
no flags Details
anaconda log. (16.31 KB, application/octet-stream)
2011-01-04 11:15 EST, Patrik Martinsson
no flags Details

  None (edit)
Description Patrik Martinsson 2011-01-04 09:32:22 EST
Created attachment 471674 [details]
Dont know if you need anything from this, but here is a small part from the ks file.

Description of problem:
Try to add a a repo using https. 

Version-Release number of selected component (if applicable):
Anaconda used in Rhel 6. 

How reproducible:

Steps to Reproduce:
1. Add a repo like this in kickstart-file 
   repo --name=rhel6_test --baseurl=https://test.foo.bar

2. Try to install with that kickstart file. 
Actual results:
Anaconda telling me "Peer cert cannot be verified or peer cert invalid"

Expected results:
Anaconda adding the repository as expected. 

Additional info:
The repo is ok and the cert is issued by, issuer: CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US.

- If I use http instead of https it works as expected. 
- If I use wget on the https://test.foo.bar, it will not validate the certificate *unless* the link /etc/pki/tls/cert.pem -> valid ca-bundle.crt exists. If this link exist, wget validates our certificate as excpected, but anaconda still rejects with "Peer cert cannot be verified or peer cert invalid".
Comment 2 Ales Kozumplik 2011-01-04 10:35:37 EST

can you attach '/tmp/anaconda.log' to this bug? Also: what step do you see the error, is it during package selection?

Comment 3 Patrik Martinsson 2011-01-04 11:14:06 EST
Yes sure, it fails right after the partitioning process, i think it says something like "retrieving information from foo-repo", and then presents the error "Unable to read package metadaga. This may be to a missing repodata directory...." Attaching log.
Comment 4 Patrik Martinsson 2011-01-04 11:15:14 EST
Created attachment 471693 [details]
anaconda log.

note that i only added https on one of the repos during this test.
Comment 5 Ales Kozumplik 2011-01-04 13:24:43 EST
We are missing libnsspem.so in the image for some reason and I think this is what prevents libcurl from verifying a certificate. Fix coming shortly.

QA, this can be verified by trying to use urlgrabber or curl (must be scp'd into the installation's /tmp) to download any file from a https server that uses a cerficicate of a well known authority from /etc/pki/tls/certs/ca-bundle.crt, if you don't have such a private key/certificate then just overwrite ca-bundle.crt with a generated one.
Comment 6 RHEL Product and Program Management 2011-01-04 13:30:32 EST
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 8 Patrik Martinsson 2011-01-05 04:16:36 EST
I've confirmed this, I rebuilt the install.img with the libnsspem.so included in /usr/lib64/ (running 64bit), and now the https enabled repo works. 

Before I did the rebuild I tried to scp over curl, tried to run curl in verbose but it was complaining about missing the libnsspem.so. After copying over the lib to /tmp, adding /tmp to LD_LIBRARY_PATH, running curl to a https adress works as expected. 

Thanks for the quick response on this.

Btw, I mounted the img (mount -o loop install.img /foo) copied it over to /bar, inserted the libnsspem.so into /bar/usr/lib64/ and ran mksquashfs on /bar to genereate a new install.img.
Comment 9 Ales Kozumplik 2011-01-06 09:13:56 EST
*** Bug 660565 has been marked as a duplicate of this bug. ***
Comment 10 Ales Kozumplik 2011-01-06 10:45:27 EST
Fixed by b3c70555b64c9a1accb294f31c4dfeb14c33d0b2.
Comment 11 Andrew Hecox 2011-01-06 11:03:16 EST
Ales -- is there a test spin we can use? Thanks!
Comment 12 Ales Kozumplik 2011-01-07 02:43:57 EST

you'll need to wait for a nightly build that includes anaconda-13.21.87-1. We did the build of *-86 just yesterday, it's going to take at most 7 days before we do *-87 (but possibly much sooner if there are emergency fixes that need to make it to the nightlies) and then around one day until it makes it to the nightlies. So I would say you can test this with nightlies from Monday 16th.

Comment 13 Andrew Hecox 2011-01-11 23:21:46 EST
Thanks Ales, I'll test once available...
Comment 15 Alexander Todorov 2011-03-09 09:12:20 EST
libnsspem.so is present in stage2 image for 0308.n.1 tree and using cutl against https URL signed by well known CA works as expected.
Comment 16 errata-xmlrpc 2011-05-19 08:36:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.