Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-14570

OAuth mTLS DN comparison fails when DER-encoding is different

    Details

    • Needs backport:
      No
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      The comparison between the registered subject DN and the DN from a certificate for mTLS may fail due to differences in the ASN.1 DER-encoding of the values when a custom OID is used for one of the components. In particular, the X500Principal constructed from a String will encode the custom OID value with the tag 0x13 (PrintableString), while the value in the certificate will often be encoded with tag 0x0c (UTF8String). While the values are otherwise identical, this tag difference is enough to cause the comparison to fail.

      How to reproduce the issue

      1. Generate a CA certificate and keypair (see mTLS documentation)
      2. Generate a client certificate signed by the CA with the subject DN "2.5.4.97=#0c1350534447422d4643412d6b742d343834333437,cn=test,o=test,c=gb"
      3. Register the client with the Subject DN field set to "OID.2.5.4.97=PSDGB-FCA-kt-484347,cn=test,o=test,c=gb"
      4. Attempt to authenticate to AM using the certificate from step 2.
      Expected behaviour

      The certificate should be accepted as the DN is identical apart from the encoding.

      Current behaviour

      The certificate is rejected.

      Work around

      Register clients using the RFC 2253 Canonical DN representation.

      Code analysis

      We currently compare the DNs in OpenAMClientRegistration#verifyTlsClientCertificateAuthentication using X500Principal.equals():

                      X500Principal subjectDn = getClientCertificateSubjectDn();
                      X500Principal certDn = certChain.get(0).getSubjectX500Principal();                
                      if (!subjectDn.equals(certDn)) {
                          logger.debug("Subject DN does not match expected: provided = '{}', expected = '{}'", certDn,
                                  subjectDn);
                          return Optional.empty();
                      }

      This will compare the RFC 2253 Canonical representation, which for unknown OIDs will compare the literal bytes of the ASN.1 syntax. We could instead compare using `subjectDn.getName(X500Principal.RFC1779).equals(certDn.getName(X500Principal.RFC1779))`, which is not sensitive to these differences, but is an obsolete spec. RFC 2253 has also been obsoleted by RFC 4514, which has rules in https://tools.ietf.org/html/rfc4514#section-2 which I think would also work.

      The OAuth mTLS spec itself only refers to the RFC 4517 distinguishedNameMatch (https://tools.ietf.org/html/rfc4517#section-4.2.15) which is a bit vague on what to do if the OID is unrecognised.

      Another option is that we explicitly try and support OID 2.5.4.97 (organisation identifier) by passing in an OID map to X500Principal.getName(format, map).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                neil.madden Neil Madden
                Reporter:
                neil.madden Neil Madden
              • Votes:
                1 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: