<div dir="ltr"><div>I think that would actually end up being more complex.<br><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help</div><div><div class="h5"><div><br>On Jun 5, 2016, at 9:31 PM, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). <br><br></div><div>This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented.<br></div><div><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>We should really be generating 2048 bit keys. </div><div><br></div><div>I don't like adding to our boot time, we have already seen it grow and this would be yet another case.</div><div><div><div><br></div><div>On Jun 5, 2016, at 8:57 PM, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup.<br><br></div><div>I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. <br></div><div><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><div><br></div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"<br></div></div></blockquote></div><div><br></div><div>Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production.</div></blockquote><div><br></div></span><div>IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue.</div><div><div><div><br></div><br><blockquote type="cite"><div><br></div><div>Stuart</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <span dir="ltr"><<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>So I guess we should talk about how this should actually work. <br><br></div>In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process.<br><br></div><div>In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div>Stuart<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Jun 2, 2016, at 11:29 AM, Harold Campbell <<a href="mailto:hcamp@muerte.net" target="_blank">hcamp@muerte.net</a>> wrote:<br>
><br>
> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote:<br>
>> Hi All,<br>
>><br>
>> I would like to propose that we add support for HTTP/2 out of the box<br>
>> in Wildfly 10.1.<br>
>><br>
><br>
> This lowly user desperately wants a release containing the fix to WFLY-<br>
> 6283 sooner rather than later. I'm sure other people have other pet<br>
> bugs awaiting release.<br>
><br>
> I have no opinion on HTTP/2 being added other than to ask that pent up<br>
> bug fixes be kept in mind.<br>
<br>
<br>
</span>Hi Harold,<br>
<br>
That fix is already in master, so it will be included in 10.1.<br>
<br>
--<br>
Jason T. Greene<br>
WildFly Lead / JBoss EAP Platform Architect<br>
JBoss, a division of Red Hat<br>
<br>
</blockquote></div><br></div>
</div></div><br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br></blockquote></div></div></blockquote></div>
</blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>wildfly-dev mailing list</span><br><span><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>