> 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

> Related question: are we even allowed to ship such keystores? It is how RHQ does it :-)

> - 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).

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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > >

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 <http://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.

" 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(a)redhat.com <mailto:infosec@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)