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

Re: OpenShift v3 now running in HTTPS mode by default



> 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]