Hi,
Looking into this again today, I found that the initial error I reported was a silly setup mistake.
The cert from the client says this:
[...]
Certificate[1]:
Owner: CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US
Issuer: CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US
[...]
Where the cert request from the server says:
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=localhost-instance, OU=GlassFish, O=Eclipse.org Foundation Inc, L=Ottawa, ST=Ontario, C=CA, CN=localhost, OU=GlassFish, O=Eclipse.org Foundation Inc, L=Ottawa, ST=Ontario, C=CA]
}
It's not the algorithms failing to match, but the Issuer not matching with the authorities. If the JDK SSL code had emitted a better error this would have been clear in a second, but alas.
In my test setup I had to import the client cert ("cts_cert") into the trust store of GlassFish. 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.
Kind regards,
Arjan