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

Re: OpenShift v3 now running in HTTPS mode by default



I'm wondering if we should be proactive and require 1.2 by default, with an option to step back.  Almost all the major browsers are at that point (ie 10 and older excluded), http2 will require it, and if folks offload ssl into a proxy layer we have a better chance of forcing the proxies to talk to us at that higher level.


> On Jan 22, 2015, at 8:48 AM, Brenton Leanhardt <bleanhar redhat com> wrote:
> 
> +++ Clayton Coleman [21/01/15 19:53 -0500]:
>> 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.
> 
> Just a nit, technically the minimum version we have set in the TLS
> code for both Kubernetes and Origin is TLSv1.0.  See:
> 
> https://github.com/openshift/origin/blob/master/pkg/cmd/server/origin/master.go#L305
> https://github.com/openshift/origin/blob/master/pkg/cmd/server/origin/master.go#L424
> https://github.com/openshift/origin/blob/master/Godeps/_workspace/src/github.com/GoogleCloudPlatform/kubernetes/pkg/client/transport.go#L67
> https://github.com/openshift/origin/blob/master/Godeps/_workspace/src/github.com/GoogleCloudPlatform/kubernetes/pkg/client/transport.go#L84
> 
> The way you can verify that TLS 1.0 is supported is to connect to the
> master with openssl directly:
> 
> openssl s_client -connect localhost:8443 -cipher RC4-SHA -tls1
> 
> That will show:
> 
> SSL-Session:
>   Protocol  : TLSv1
>   Cipher    : RC4-SHA
> 
> I picked RC4-SHA because it's supported by Go
> (http://golang.org/pkg/crypto/tls/#pkg-constants) and it's a TLS 1.0
> cipher:
> https://www.openssl.org/docs/apps/ciphers.html#tls_v1_0_cipher_suites_
> 
> The problem in Mavericks is almost certainly that the subset of the
> cipher suites it supports doesn't match Go.  I just wanted to mention
> this in case people have to debug similar situations in the future.
> 
> --Brenton
> 
>> 
>> ----- 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.
>> 
>> _______________________________________________
>> dev mailing list
>> dev lists openshift redhat com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


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