<div dir="ltr">On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec <span dir="ltr">&lt;<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think I&#39;ve just found the reason why we can not migrate in OpenSSL by default :(<div><br></div><div>In server scenario we obtain S<b>SL</b>Context (the one from JDK; Netty has similar S<b>sl</b>Context) from WildFly. It is already configured along with sercurity realms, domains etc. We then get into this branch of code [1].</div><div><br></div><div>In order to do fancy things like SNI we need to remap JDK&#39;s SSLContext into Netty&#39;s SslContext and the only implementation that can consume SSLContext we have at hand is JdkSslContext.</div><div><br></div><div>I honestly have no idea how we could refactor this... And that&#39;s a shame because OpenSSL is way faster...</div></div></blockquote><div><br><br></div><div>I tried migrating the SSL engine to Netty&#39;s in [1] and hit the same wall. What I was told is that the SSLContext in Wildfly is now (version 11?) a capability under &#39;org.wildfly.security.ssl-<wbr>context&#39;  and <br></div><div>can be replaced, but I did not try doing that.<br></div><div><br><br>[1] <a href="https://issues.jboss.org/browse/ISPN-6990" target="_blank">https://issues.jboss.org/<wbr>browse/ISPN-6990</a><br></div><div><br></div><div>Gustavo<br></div></div></div></div>