[Hawkular-dev] SSL by default

[Jiri Kremser]

Hello *,

  I am adding some tests for hawkular ruby client over SSL and I was able
to make the calls with the SSL verification turned off, but if I turn it
on, the verification phase fails when talking to
hawkular.torii.gva.redhat.com. I am using the right CA .pem file as a param
to the http client.

Using this script https://github.com/mislav/ssl-tools/blob/8b3dec4/doctor.rb
I figured out, it's because of the:

"
The server presented a certificate that could not be verified:
  subject: /O=Red Hat/OU=prod/CN=Intermediate Certificate Authority
  issuer: /C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=Red Hat
IT/CN=Red Hat IT Root CA/emailAddress=infosec at redhat.com
  error code 2: unable to get issuer certificate
"

The root cause is that CA certificate has the empty issuer field. I'll set
up my own nginx as a reverse proxy with a certificate that will pass the
verification for now to record the VCRs for the client, but whatever method
for creating a default certificate we choose, it needs to pass the if
the SSL_VERIFY_PEER flag is set (
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html)

jk

On Thu, May 26, 2016 at 5:50 PM, Jiri Kremser <jkremser at redhat.com> wrote:

> Apart from the Agent, I'm not aware of any REST calls made by individual
> components, but I'd need to be aware of any problems that this change
> might cause.
>
> It's not a hawkular component, but hawkular ruby client uses only REST to
> communicate with hawkular. The underlying rest client has support for
> adding explicitly the CA, if not specified it's taken from the system.
> Adding client certificates is also possible, but that's not necessary, imho.
>
> There is also an option not to do the certificate check at all by passing :verify_ssl
> => false. This way we get the encrypted comm channel and save the trouble
> with adding the certificates. However, it's less secure, because it's not
> guaranteed that the server side is the one who it claims to be.
>
> jk
>
> On Thu, May 26, 2016 at 11:51 AM, Jiri Kremser <jkremser at redhat.com>
> wrote:
>
>> Hi,
>>   what about creating a default certificate that is issued by a commonly
>> accepted root CA (at least in the modern browsers, not sure about JVM if
>> there is something similar). On the internets there is a service
>> https://letsencrypt.org .I haven't tried yet, but it has also some API
>> for doing it automatically, so we can even go further. What I've tried is
>> the https://www.startssl.com and it worked perfectly, I can see the
>> green https in the chrome :] Both services are for free, but afaik, don't
>> allow to issue the "star" certificate, but for the dev purposes all we need
>> is the cert for the localhost, right?
>>
>> As for the production, we may provide some script + docs how to generate
>> the cert in the https://letsencrypt.org
>>
>> my 2c
>> jk
>>
>> On Wed, May 25, 2016 at 3:46 PM, Juraci Paixão Kröhling <
>> jpkroehling at redhat.com> wrote:
>>
>>> On 25.05.2016 15:16, John Mazzitelli wrote:
>>> >> My next step is to change the agent to accept certs on our keystore.
>>> >
>>> > If everything works as I am expecting it to work, you should just need
>>> to configure the agent's storage adapter to use the WildFly security realm
>>> where the keystore is defined, and it should "just work." But then again,
>>> its been a while since I tested the agent using secure comm to the server,
>>> but that is how I got it to work last time.
>>> >
>>> > See http://www.hawkular.org/docs/user/secure-comm.html
>>>
>>> Cool ! That would work for the local agent, which is the scenario I was
>>> planning on working on. For remote agents, we should *not* do this, as
>>> the keystore includes the private key for the cert, which should be
>>> known only to the server. But for the remote agent, I expect the server
>>> to use a proper certificate chain.
>>>
>>> >> Related question: are we even allowed to ship such keystores?
>>> >
>>> > It is how RHQ does it :-)
>>>
>>> That's good to know, thanks!
>>>
>>> >> - As mentioned in the previous point, the cert is self-signed. So, you
>>> >> might need to add "-k" to curl to bypass the cert verification.
>>> >> - Authentication with client cert is not yet available.
>>> >
>>> >
>>> > I do not know how to tell WildFly in its security-realm to do this
>>> same kind of bypass... did you look into that? Because the agent will need
>>> to be told about doing this bypass, too. The way I worked around it was I
>>> actually put my self-signed cert into my JVM's truststore (which isn't
>>> something I think we want to ask people to do).
>>>
>>> It depends on the HTTP client you are using. In the "production"
>>> scenarios, no change is needed, as the cert would probably have a valid
>>> chain.
>>>
>>> For dev scenarios, or scenarios where the cert is issued by an unknown
>>> root CA (like internal certificates), the common practice is to add the
>>> root CA to the JVM's keystore, similar to what you did. The reason is
>>> that this cert is not trusted by any known Certificate Authority, so, an
>>> admin would have to explicitly tell that this cert is known and is to be
>>> trusted. The cert we will be shipping on the keystore is *not* trusted
>>> and is intended to be used only on dev scenarios.
>>>
>>> Another practice is to do a certificate pinning, ie, tell your HTTP
>>> client that you know about this specific cert. The disadvantage of this
>>> is that we'd have to keep the server and client in sync. Looking at your
>>> instructions on secure-comm.html , this is probably what you are doing
>>> on the agent side.
>>>
>>> Unfortunately, there's no secure solution that I know of that would
>>> allow us to ship something usable for our production distribution.
>>>
>>> There was a thread some time ago on wildfly-dev about auto generating
>>> certificates on the first boot. I believe this was part of Elytron and
>>> we might be able to benefit from this in the future.
>>>
>>> - Juca.
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160527/62b74cc2/attachment.html