Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1055476

Summary: Documentation misses option for wget
Product: OpenShift Container Platform Reporter: Juergen Hoffmann <juhoffma>
Component: DocumentationAssignee: Bilhar <baulakh>
Status: CLOSED WORKSFORME QA Contact: ecs-bugs
Severity: low Docs Contact:
Priority: unspecified    
Version: 2.0.0CC: jokerman, libra-onpremise-devel, lmeyer, mmccomas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Build Name: 20635, Deployment Guide-2-1.0 Build Date: 14-01-2014 10:00:13 Topic ID: 25162-575506 [Latest]
Last Closed: 2014-01-20 16:56:24 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:

Description Juergen Hoffmann 2014-01-20 10:59:10 UTC
Title: Installation Utility

Describe the issue:
The documentation states to run wget . This is missing the no-check-certificate option, since the domain name does not match (see below)
[root@broker ~]# wget
--2014-01-20 05:55:01--
Connecting to||:443... connected.
ERROR: certificate common name “*” doesn’t match requested host name “”.
To connect to insecurely, use ‘--no-check-certificate’.

Suggestions for improvement:
correct the command and add the no-check-certificate option to the command.

Additional information:

Comment 2 Luke Meyer 2014-01-20 16:56:24 UTC
I am not sure how you saw this; should have a correct matching cert, and does when I try exactly this command. Is it conceivable the version of wget you're using is old enough it doesn't support SNI to determine which vhost to check against?

I'm going to close this since I don't think it's a docs problem, if it's a problem at all. Can you re-check and maybe try with some other clients if it's still happening? There might conceivably be some kind of routing error at work here. * is the fallback for apps that don't have a cert for their alias. Re-open if needed and we'll try to direct it to the right place to get attention. We don't want our install site looking insecure.