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

Re: OpenShift v3 now running in HTTPS mode by default



Figured it out - Mac default openssl doesn't support TLSv1.2 in Mavericks.  We should doc this - you'll need a curl / openssl with tls1.2 support+ because we have no intention of enabling anything lower.

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