After that the handshake works, and the 403 that we saw in the failing TCK run could be reproduced. As soon as I have some time (hopefully tonight, or tomorrow), I'll look into this specifically.
I just had time to look into this again, and it appeared to be a known issue actually. With Payara we ran into the same problem.
The failure is because of the difference in formatting of the distinguished name according to RFC 1779 vs RFC 2253, which are both technically independent from how the name is formatted in the certificate that's being used. The Servlet spec doesn't specify any mapping here.
In RFC 1779, the DN that the TCK uses is:
CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US
However, in RFC 2253 it's:
CN=CTS,OU=Java Software,O=Sun Microsystems Inc.,L=Burlington,ST=MA,C=US
GlassFish used the Sun specific X500Name before, which needed to be changed into the JDK X500Principal. X500Name uses RFC 1779 by default, while X500Principal uses RFC 2253:
/**
* Returns a string representation of the X.500 distinguished name using
* the format defined in RFC 2253.
*
* <p>This method is equivalent to calling
* {@code getName(X500Principal.RFC2253)}.
*
* @return the distinguished name of this {@code X500Principal}
*/
public String getName() {
return getName(X500Principal.RFC2253);
}
The test can be passed by updating the GlassFish specific role to principal mapping file "sun-web.xml" in the TCK:
<sun-web-app>
<context-root>clientcert_web</context-root>
<security-role-mapping>
<role-name>Administrator</role-name>
<principal-name>CN=CTS,OU=Java Software,O=Sun Microsystems Inc.,L=Burlington,ST=MA,C=US</principal-name>
</security-role-mapping>
</sun-web-app>
However, this is half the story.
The other half is that the test now checks for the name in RFC 1779 format:
// DN name for CTS certificate
private final String username = "CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US";
// compare getRemoteUser() obtained from server's response
// with the username stored in ts.jte
//
// Even though the output need not be identical (because
// of appserver realms) the output should have substring
// match for username stored in ts.jte.
//
String userNameToSearch = username;
if (output.indexOf(userNameToSearch) == -1) {
throw new Fault(testName + ": getRemoteUser(): " + "- did not find \""
+ userNameToSearch + "\" in log.");
}
The test comment recognised that the username to check for is server specific, but then the comment seems to be out of sync with the actual code, as the username is hardcoded here and not coming from ts.jte at all.
I'd therefor like to do a PR to the TCK to:
1. Change the GlassFish specific role/principal mapping as indicated
2. Update the test to get the username to check for from ts.jte, as seemed to have been the intent all along.
Thoughts?
Kind regards,
Arjan Tijms
