[Hawkular-dev] SSL by default

[Stefan Negrea]

Hello,

I like Jiri's idea. Why not deliver the distribution without a certificate
but add documentation and tooling (scripts or code) to easily install a
certificate from letsencrypt.org? It's the cleanest solution since it will
avoid bundling a self-signed certificate. The main issue I have with
self-signed certificates is that users will most likely not change it,
which is a bigger issue than using unsecured connections.



Thank you,
Stefan Negrea

Software Engineer

On Thu, May 26, 2016 at 4: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
>>
>
>
> _______________________________________________
> 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/20160526/1b1e2863/attachment-0001.html