[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift v3 now running in HTTPS mode by default



Neither works individually


> On Jan 21, 2015, at 7:21 PM, Jordan Liggitt <jliggitt redhat com> wrote:
> 
> 
>> On Jan 21, 2015, at 6:47 PM, Clayton Coleman <ccoleman redhat com> wrote:
>> 
>> 
>> 
>> ----- Original Message -----
>>> As of today[1], HTTPS is the default for the OpenShift master, the OpenShift
>>> command-line client, and the OpenShift web console.
>>> 
>>> When running in HTTPS, "openshift start" now does the following:
>>> 1. Generates a certificate authority
>>> 2. Creates a self-signed certificate for the API server
>>> 3. Creates client certificates for system components to use when
>>> communicating with the API
>>> 4. Creates client certificates and a .kubeconfig file for an admin user
>>> 
>>> The generated certificates are placed under "openshift.local.certificates"
>>> (changeable using the "--cert-dir" parameter).
>>> 
>>> 
>>> 
>>> Why is this awesome?
>>> It makes sure we have the wiring in place for all parts of the system to be
>>> able to speak securely to each other, and lets us start turning on
>>> authentication and authorization
>>> 
>>> 
>>> 
>>> How do I access the OpenShift master?
>>> The default url is now https:// <ip>:8443 (available locally as
>>> https://localhost:8443 )
>>> 
>>> 
>>> 
>>> Why does osc, curl, my web browser, and <my favorite tool> complain about SSL
>>> certificates
>>> "openshift start" creates a certificate to serve on https. API clients need
>>> to include the root certificate bundle in the list of trusted certs. This is
>>> located in $CERT_DIR/master/root.crt
>>> 
>>> 1. To get your browser working:
>>> - add an exception to trust the generated certificate the first time you
>>> access the master.
>>> 
>>> 2. To get osc working:
>>> - Preferred: use the generated admin user by passing
>>> --kubeconfig=$CERT_DIR/admin/.kubeconfig or setting
>>> KUBECONFIG=$CERT_DIR/admin/.kubeconfig (make sure you have read access to
>>> the files under $CERT_DIR/admin)
>>> - Acceptable: pass "--certificate-authority=$CERT_DIR/master/root.crt"
>>> - Bad (don't get used to doing this): pass "--insecure-skip-tls-verify=true"
>>> 
>>> 3. To get curl working:
>>> - Preferred: pass "--cacert $CERT_DIR/master/root.crt" or set
>>> CURL_CA_BUNDLE=$CERT_DIR/master/root.crt
>>> - Bad (don't get used to doing this): pass "--insecure"
>> 
>> Hrm - I'm getting an "Invalid certificate chain" from curl on Mac.
>> 
>> $ curl --cacert $CURL_CA_BUNDLE https://localhost:8443 -v
>> * Adding handle: conn: 0x7fed29803a00
>> * Adding handle: send: 0
>> * Adding handle: recv: 0
>> * Curl_addHandleToPipeline: length: 1
>> * - Conn 0 (0x7fed29803a00) send_pipe: 1, recv_pipe: 0
>> * About to connect() to localhost port 8443 (#0)
>> *   Trying 127.0.0.1...
>> * Connected to localhost (127.0.0.1) port 8443 (#0)
>> * SSL certificate problem: Invalid certificate chain
>> * Closing connection 0
>> 
>> curl: (60) SSL certificate problem: Invalid certificate chain
>> More details here: http://curl.haxx.se/docs/sslcerts.html
>> 
>> curl performs SSL certificate verification by default, using a "bundle"
>> of Certificate Authority (CA) public keys (CA certs). If the default
>> bundle file isn't adequate, you can specify an alternate file
>> using the --cacert option.
> 
> Set CURL_CA_BUNDLE or pass --cacert. Looks like you're trying to do both. 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]