Just recently completed updating to X509ExtendedTrustManager, but not
comprehensively yet, as some code is still using X509TrustManager, but
will look into updating it too in the near future ...
Thanks,
Peter.
On 17/09/2018 10:57 PM, Norman Maurer wrote:
Should I open an issue somewhere to keep track of it or will you take care of
it ?
Bye
Norman
On 11. Sep 2018, at 17:01, Norman Maurer<norman.mau...@googlemail.com> wrote:
This sounds great.
I have no idea how many people still use X509TrustManager, sorry.
It may be a good idea to add something to the java docs to tell people to
prefer X509ExtendedTrustManager as well.
Bye
Norman
Am 11.09.2018 um 16:44 schrieb Xuelei Fan<xuelei....@oracle.com>:
Hi Norman,
It may be doable by adding a delegation mode to public TrustManagerFactory:
TrustManagerFactory.init(X509TrustManager proxy)
However, the X509ExtendedTrustManager should be recommended for now since its
introducing in JDK 7.
Do you know how many users are still using the X509TrustManager implementation?
Thanks,
Xuelei
On 9/11/2018 3:32 AM, Norman Maurer wrote:
Hi all,
Would it be possible to consider exposing
SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to
reuse it when a custom SSLEngine / SSLContextSpi is provided ?
I am asking because it provides really nice extra functionality by wrapping for
X509TrustManager implementation and do extra hostname checks etc. At the moment
we can not make use of this extra functionality in netty with our custom
SSLEngine implementation as there is no way to access this. Which means
depending on if the user use our implementation or the default implementation
the behaviour if quite different when using a X509TrustManager in the sense
that when using the default implementation a lot of extra checks are done.
As the extra checks done in AbstractTrustManagerWrapper is not really depending
on the underlying SSLContextSpi implementation (at least as far as I was able
to understand it so far) it would be nice to be able to make use of it.
Bye
Norman
