Hi,
In general, TLS 1.3 is not fully compatible with Servlet since for some reason the JEP decided to exclude Post-Handshake Authentication in Java. See
https://openjdk.java.net/jeps/332.
This is exactly what Servlet needs.
Technically I don't think Servlet does need it, it's just the way the TCK is written needs it. AFAIK the spec does not explicitly require support for post handshake auth.
From memory the issue with the TCK is that if you use REQUIRED for the client auth mode and always request certificates some tests will fail that are not expecting an
authenticated user, which is why post handshake auth is required. My memory may be a bit out of date though, it has been a few years since I ran into this. Technically
these tests could probably be challenged, or worked around by only exposing the user/client cert info if auth is actually required (it has been a few years though, so my
memory may be incorrect).
Stuart
This is a client cert test, so I would suggest it is almost certainly due to TLS differences between JDK8 and JDK11 (it is probably now using TLS 1.3 instead of 1.2). I would check the TLS config to make sure everything is correct for client cert authentication, but I don't really know anything about Glassfish so I can't really help with that.
Stuart
Hi,
The TCK team needs help diagnosing a problem with the Servlet TCK
tests, described in
If someone could have a look and help the TCK team move this
forward, it would be appreciated.
Thank you,
-- Ed
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev