Awesome! Another idea I had on how we could get away with it being in server boot, is to
have a pre-boot first time setup task, either launched from the shell/batch scripts or as
a special pre-step before the AS module loads. We could then report boot time as the time
AFTER first time installation tasks have completed, which I think is fair because the
server hasn't yet been started.
On Jun 5, 2016, at 11:53 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
I have some initial work on this at:
https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576
If you go to
https://localhost:9993 it will generate the certificate (although all that
will be served is a 404 page as the console is not installed).
Stuart
> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
> I think that would actually end up being more complex.
>
> Stuart
>
>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <jason.greene(a)redhat.com>
wrote:
>> 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
>>
>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
>>>
>>> 2048 bits adds close to a second to first boot on my machine (obviously
subsequent boots are unaffected).
>>>
>>> This is probably a bit much, I will work on getting a POC for the lazy
loading approach implemented.
>>>
>>> Stuart
>>>
>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
>>>> We should really be generating 2048 bit keys.
>>>>
>>>> I don't like adding to our boot time, we have already seen it grow
and this would be yet another case.
>>>>
>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Stuart
>>>>>
>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
>>>>>>
>>>>>>>> What will be default keysize? It has to be probably
choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy"
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>> So I guess we should talk about how this should
actually work.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Stuart
>>>>>>>>>
>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene
<jason.greene(a)redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell
<hcamp(a)muerte.net> wrote:
>>>>>>>>>> >
>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart
Douglas wrote:
>>>>>>>>>> >> Hi All,
>>>>>>>>>> >>
>>>>>>>>>> >> I would like to propose that we add
support for HTTP/2 out of the box
>>>>>>>>>> >> in Wildfly 10.1.
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> > This lowly user desperately wants a release
containing the fix to WFLY-
>>>>>>>>>> > 6283 sooner rather than later. I'm sure
other people have other pet
>>>>>>>>>> > bugs awaiting release.
>>>>>>>>>> >
>>>>>>>>>> > I have no opinion on HTTP/2 being added
other than to ask that pent up
>>>>>>>>>> > bug fixes be kept in mind.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Harold,
>>>>>>>>>>
>>>>>>>>>> That fix is already in master, so it will be
included in 10.1.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jason T. Greene
>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect
>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev