Description of problem: kernel command-line args that anaconda parses don't seem to be happy with https from a server with a self-signed cert specifically, these kernel command-line directives: repo= url= ks= Version-Release number of selected component (if applicable): F17
From inside the ks.cfg file, "--noverifyssl" no longer works in F17 either for these directives: url repo According to http://fedoraproject.org/wiki/Anaconda/Kickstart it should, but F17 doesn't. Can we get this fixed in F18?
Please attach the log files from /tmp to this bug report as individual, uncompressed attachments.
Let me retract comment #1... when the kernel command line has no https in it, the url and repo kickstart directives in ks.cfg *do* work just fine with an self-signed SSL cert, so long as --noverifyssl is provided as an option. That said, when ks= and repo= on the kernel command line use https, with the same self-signed SSL cert on the webserver side, dracut dies with the following message: curl: (77) Problem with the SSL CA cert (path? access rights?) [dracut Warning: failed to fetch <file>] This is repeated for <file> of ks.cfg file, .treeinfo, and squashfs.img. As such, anaconda never really gets started... and I'm left at a dracut:/# prompt. Seems like dracut's use of curl is too strict when fetching from https locations?
Another note: the same issue exists for ks= and repo= on the kernel command line when the SSL cert *is* signed by a CA that most all browsers accept. So this really does seem to be a CA issue, where curl literally doesn't know who or what to trust... which completely breaks dracut/anaconda. Should curl be made to use its --insecure option by default?
Putting this back on anaconda for now, it could be the way we're calling curl to get the kickstart file, that could be anaconda code.
noverifyssl should work for this, but currently we aren't handling that in any of the anaconda-dracut code (kickstart or not).
How does one specify noverifyssl for the kernel command line bits? Is "noverifyssl" itself legal on the kernel command line?
yes.
I can verify that with a properly signed cert, and ks=http and repo=https and noverifyssl on the kernel command line... we still get the following error: curl: (77) Problem with the SSL CA cert (path? access rights?) So can we get this fixed in Fedora 18? Perhaps use the same list of acceptible CAs that Firefox uses? Or at least make noverifyssl work so as to be able to disregard CAs altogether? Both would be great, but the later really is just plain broken and needs to be addressed.
Created attachment 623762 [details] dracut patch
Created attachment 623763 [details] anaconda patch
How does it fix things? Does anaconda now trust select CAs, or disregard CAs from an identity perspective altogether?
anaconda-18.15-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.15-1.fc18
https://fedoraproject.org/wiki/Anaconda_Boot_Options?rd=Anaconda/Options#noverifyssl Note that this depends on a new dracut being built with an associated change.
Package anaconda-18.15-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.15-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15903/anaconda-18.15-1.fc18 then log in and leave karma (feedback).
anaconda-18.16-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.16-1.fc18
anaconda-18.17-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.17-1.fc18
Are the requisite changes in dracut happening too?
https://admin.fedoraproject.org/updates/FEDORA-2012-16223/dracut-024-1.fc18
anaconda-18.18-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.18-1.fc18
anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18
This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.