Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] [glassfish-dev] [jakartaee-platform-dev] Help please -- Servlet TCK test issue

Funnily enough, the TCK test in question actually contains more errors. Only in this case the error works to our advantage.

The output generated by the test servlet is this:

getRemoteUser(): CN=CTS,OU=Java Software,O=Sun Microsystems Inc.,L=Burlington,ST=MA,C=US<BR>
isUserInRole("ADM"): !true!<BR>
Caller principal Name = CN=CTS,OU=Java Software,O=Sun Microsystems Inc.,L=Burlington,ST=MA,C=US
clientCertTest: cipher-suite : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
clientCertTest: key-size : 256
clientCertTest: certificate [0]=[
[
  Version: V3
  Subject: CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  params: null
  modulus: 24460105159495683492479219036286112749899854013500201309232120825123331060682329826163915830251897432595746713185596288522960790747408731775058546008104864519848489118361000700960956192511733961528243032372562571285863153870347040697051544628937678450380798213161047385654009510331310879509706993818924558058241541436686925218504703743974586296114509605422003065618409897263700779222128675817568715275150994218434579165698867790691632043901394964526449428390754635763515883418569290094463550082321137739585784480450110054008617899423014100371287884979085344751261803723149160277946971097431777068322972064736592397767
  public exponent: 65537
  Validity: [From: Mon Dec 23 07:21:39 CET 2019,
               To: Sat Aug 13 08:21:39 CEST 2044]
  Issuer: CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US
  SerialNumber: [    68deca39]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D6 86 B4 6D AB 78 A9 0E   CB 85 F9 AD F6 AC 79 9D  ...m.x........y.
0010: 30 C7 67 61                                        0.ga
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 5D 33 FA E7 78 A8 62 8B   9B D9 1F 34 BE 31 66 22  ]3..x.b....4.1f"
0010: 94 C4 63 D9 A7 8B E7 D6   C4 7B D5 EB 3E 60 AB 6F  ..c.........>`.o
0020: A3 A0 70 A0 7F 0A 16 F6   5A 47 2A 0A 8C A2 19 F0  ..p.....ZG*.....
0030: 9F D0 5B 4A B6 D1 C0 6D   08 7D 29 28 F8 E6 86 F8  ..[J...m..)(....
0040: CA A3 33 C7 3F 35 23 11   B0 91 41 77 EF A9 8A 7A  ..3.?5#...Aw...z
0050: AE 80 72 CF 15 E7 06 D2   D6 4D BB E7 27 9D 7F D6  ..r......M..'...
0060: DC 3A F3 73 5B 16 50 D7   D7 75 D5 E7 72 FF 63 4A  .:.s[.P..u..r.cJ
0070: 7F 3C 26 B4 2D D8 37 A4   B3 80 1B 4A 20 36 57 6E  .<&.-.7....J 6Wn
0080: B8 2A EE F1 4F FF 65 58   FF A3 F4 3A 51 3F 02 0F  .*..O.eX...:Q?..
0090: 66 4F 83 B4 9A 8A 79 7E   0A 0E D0 40 64 08 0E 0B  fO....y....@d...
00A0: F5 B7 9C 30 7F F1 25 F2   A5 93 9B 18 13 58 D2 FC  ...0..%......X..
00B0: 86 03 E0 04 42 A3 FC 4B   E0 31 2C 41 DA 7F B6 8A  ....B..K.1,A....
00C0: F7 A1 42 71 F8 B6 BC AF   EF B3 ED 66 3B DF 27 23  ..Bq.......f;.'#
00D0: C4 E0 D0 3C E0 B1 B2 6B   4B FD E4 8F B4 01 FD 8E  ...<...kK.......
00E0: 4A 8D 25 45 A8 A6 CD DD   37 FD C4 6D BF BB A9 98  J.%E....7..m....
00F0: F7 B5 BC 6E 91 83 0C 80   4A E0 F0 C3 70 10 10 B8  ...n....J...p...

]
clientCertTest: PASSED


The test checks for "CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US", which it intends to find in "getRemoteUser(): CN=CTS,OU=Java Software,O=Sun Microsystems Inc.,L=Burlington,ST=MA,C=US", which would fail.

However, the test forgets that it also prints the certificate, which contains exactly that string as well. Hence, the test is testing nothing there and its effectively a NOOP concerning testing for the user name. This explains why the test has always passed for other servers, even though they were never consistent in their DN formatting.

Even though it's wrong, we can leave in the faulty NOOP code, and then do:

  1. Change the GlassFish specific role/principal mapping as indicated 
  2. Set the test to use the superior TLSv1.2, but do so conditionally via a setting in ts.jte

Kind regards,
Arjan Tijms






On Fri, Mar 5, 2021 at 12:36 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Thu, Mar 4, 2021 at 4:24 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
 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









 

Back to the top