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

Re: OpenShift v3 now running in HTTPS mode by default



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