Hi Jeremy, Please read https://bugs.openjdk.org/browse/JDK-7197159 for the reason behind the code.
That said, we will see if the exception message can be enhanced or there can be extra debug messages. I've filed https://bugs.openjdk.org/browse/JDK-8367344. Thanks, Weijun > On Sep 9, 2025, at 19:08, Jeremy Jackson <[email protected]> wrote: > > Hi All, > > In developing a Jetty application using SPNEGO, I encountered some > misleading error messages. > > The browser was sending tickets that had a "kvno" that the webserver > didn't have in it's keytab, yielding: > > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Checksum failed) > > Which does not point towards a solution, to say the least. > > There are 2 code paths, one (initiator) which requires the newest key be > returned, and another (acceptor) which requires an exact kvno match. > > The current logic returns the newest key even when exact match is > requested, instead of throwing BADKEYVER. > > For the acceptor case, this is an incorrect key, thus > triggering exceptions related to decryption failure. > > According to ChatGPT: > > RFC 4120 says that when a server receives an AP-REQ, “If the key version > indicated by the Ticket in the KRB_AP_REQ is not one the server can use > (e.g., it indicates an old key, and the server no longer possesses a > copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.” > > In looking at the code in > > src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java > > I can see that the BADKEYVER exception is never thrown, but is commented > out *close* to the required code path with the vague explanation "For > compatibility, will not fail here." > > I have created new test cases for all callers of EncryptionKey.findKey() > and implemed the missing exception logic. The result has been that > existing callers are unaffected. > > A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: > > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Specified version of key is not available (44)) > > As a first time contributor I would appreciate some guidance here. The > comments related to the missing exception are a bit troubling, and there > is also the commented out throw statement, and although I think I have > test coverage on all the callers of findKey(), I would welcome some input. > > Regards, > Jeremy >
