Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-1198

Requests of usercertificate;binary are not supported

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.0-M1
    • Component/s: None
    • Labels:
      None

      Description

      ApacheDS only supports the retrieval of certificates without the ;binary transfer suffix.

      RFC4523 states certificates must be transferred using the ;binary transfer option.

      In practice we have clients in the field that are making requests both with and without the option so we'd need support for both methods to be able to consider deploying ApacheDS.

        Issue Links

          Activity

          Chris Trobridge created issue -
          Emmanuel Lecharny made changes -
          Field Original Value New Value
          Assignee Emmanuel Lecharny [ elecharny ]
          Hide
          Emmanuel Lecharny added a comment -

          We have added some partial support of ';binary' option for attributes, it will be available in 1.5.2 (expected in march)

          Show
          Emmanuel Lecharny added a comment - We have added some partial support of ';binary' option for attributes, it will be available in 1.5.2 (expected in march)
          Emmanuel Lecharny made changes -
          Fix Version/s 1.5.2 [ 12310793 ]
          Hide
          Emmanuel Lecharny added a comment -

          Will be partially available in 1.5.2, but the definitive fix is due for the next version.

          Show
          Emmanuel Lecharny added a comment - Will be partially available in 1.5.2, but the definitive fix is due for the next version.
          Emmanuel Lecharny made changes -
          Fix Version/s 1.5.2 [ 12310793 ]
          Fix Version/s 1.5.3 [ 12312693 ]
          Hide
          Alex Karasulu added a comment -

          Did we fix this? I thought we had something in already. Can I get a status on this?

          Show
          Alex Karasulu added a comment - Did we fix this? I thought we had something in already. Can I get a status on this?
          Hide
          Chris Trobridge added a comment -

          My initial testing suggests that I can use Apache Directory Studio to import ldif files with attributes named with the ";binary" suffix but I haven't managed to retrieve the attributes correctly. The retrieved attributes aren't valid certificates.

          Browsing in studio looks it like they're corrupt, eg all my certificates start with repears of "30 ef bf bd" and there are way more "ef bf bd" sequences in the data than I'd expect. However, the data is the expected length.

          Show
          Chris Trobridge added a comment - My initial testing suggests that I can use Apache Directory Studio to import ldif files with attributes named with the ";binary" suffix but I haven't managed to retrieve the attributes correctly. The retrieved attributes aren't valid certificates. Browsing in studio looks it like they're corrupt, eg all my certificates start with repears of "30 ef bf bd" and there are way more "ef bf bd" sequences in the data than I'd expect. However, the data is the expected length.
          Hide
          Emmanuel Lecharny added a comment -

          Do you mean that if you store a valid certificate, and get it back, it has been modified ?

          Can you attach a valid certificate that we can test the procedure ?

          Another possibility s that Studio messes wit the certificate. We have to check that.

          I will check if we have a unit test for certificate storing, and if not, I will add one.

          Show
          Emmanuel Lecharny added a comment - Do you mean that if you store a valid certificate, and get it back, it has been modified ? Can you attach a valid certificate that we can test the procedure ? Another possibility s that Studio messes wit the certificate. We have to check that. I will check if we have a unit test for certificate storing, and if not, I will add one.
          Hide
          Emmanuel Lecharny added a comment -

          The following test demonstrates that the userCertificate;binary attribute is working on the server, and that the certificate is not modified.

          There may be a bug in Studio, however.

          public void testAddNewBinaryAttributeValue() throws NamingException
          {
          // Add a binary attribute
          byte[] newValue = new byte[]

          {0x00, 0x01, 0x02, 0x03}

          ;
          Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue );
          ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs );

          // Verify, that attribute value is added
          attrs = ctx.getAttributes( RDN_TORI_AMOS );
          Attribute attr = attrs.get( "userCertificate" );
          assertNotNull( attr );
          assertTrue( attr.contains( newValue ) );
          byte[] certificate = (byte[])attr.get();
          assertTrue( Arrays.equals( newValue, certificate ) );
          assertEquals( 1, attr.size() );
          }

          Show
          Emmanuel Lecharny added a comment - The following test demonstrates that the userCertificate;binary attribute is working on the server, and that the certificate is not modified. There may be a bug in Studio, however. public void testAddNewBinaryAttributeValue() throws NamingException { // Add a binary attribute byte[] newValue = new byte[] {0x00, 0x01, 0x02, 0x03} ; Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue ); ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs ); // Verify, that attribute value is added attrs = ctx.getAttributes( RDN_TORI_AMOS ); Attribute attr = attrs.get( "userCertificate" ); assertNotNull( attr ); assertTrue( attr.contains( newValue ) ); byte[] certificate = (byte[])attr.get(); assertTrue( Arrays.equals( newValue, certificate ) ); assertEquals( 1, attr.size() ); }
          Emmanuel Lecharny made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Emmanuel Lecharny made changes -
          Project Directory ApacheDS [ 12310260 ] Directory Studio [ 12310590 ]
          Fix Version/s 1.2.0 [ 12312851 ]
          Affects Version/s 1.5.1 [ 12310792 ]
          Affects Version/s 1.1.0 [ 12312701 ]
          Key DIRSERVER-1146 DIRSTUDIO-351
          Fix Version/s 1.5.3 [ 12312693 ]
          Component/s ldap [ 12310715 ]
          Hide
          Emmanuel Lecharny added a comment -

          Moved to Studio to check that it's not an issue with the way Studio handles ;binary values

          Show
          Emmanuel Lecharny added a comment - Moved to Studio to check that it's not an issue with the way Studio handles ;binary values
          Stefan Seelmann made changes -
          Project Directory Studio [ 12310590 ] Directory ApacheDS [ 12310260 ]
          Affects Version/s 1.1.0 [ 12312701 ]
          Fix Version/s 1.5.3 [ 12312693 ]
          Fix Version/s 1.2.0 [ 12312851 ]
          Key DIRSTUDIO-351 DIRSERVER-1198
          Hide
          Stefan Seelmann added a comment -

          Moved back to Server. I found two more bugs:

          1st)
          There is a problem when writing ;binary values greater than 0x80. The following test write four bytes 0x80, 0x81, 0x82, 0x83 when reading it from the server I get 12 bytes.

          /**

          • Add a new ;binary attribute with bytes greater than 0x80
          • to a person entry.
          • Test for DIRSERVER-1146
          • @throws NamingException
            */
            public void testAddNewBinaryAttributeValue0x80() throws NamingException
            {
            // Add a ;binary attribute with high-bytes
            byte[] newValue = new byte[] {(byte)0x80, (byte)0x81, (byte)0x82, (byte)0x83}

            ;
            Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue );
            ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs );

          // Verify, that attribute value is added
          attrs = ctx.getAttributes( RDN_TORI_AMOS );
          Attribute attr = attrs.get( "userCertificate" );
          assertNotNull( attr );
          assertTrue( attr.contains( newValue ) );
          byte[] certificate = (byte[])attr.get();
          assertTrue( Arrays.equals( newValue, certificate ) );
          assertEquals( 1, attr.size() );
          }

          2nd)
          Reading the entry and requesting userCertificate;binary (including the ;binary) doesn't work

          /**

          • Retrieve a ;binary attribute from a person entry.
          • Test for DIRSERVER-1146
          • @throws NamingException
            */
            public void testRetrieveEntryWithBinaryAttributeValue() throws NamingException
            {
            // Add a ;binary attribute
            byte[] newValue = new byte[] {0x00, 0x01, 0x02, 0x03}

            ;
            Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue );
            ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs );

          // Search entry an request ;binary attribute
          SearchControls sctls = new SearchControls();
          sctls.setSearchScope(SearchControls.OBJECT_SCOPE);
          sctls.setReturningAttributes( new String[]

          { "userCertificate;binary" }

          );
          String filter = "(objectClass=*)";
          String base = RDN_TORI_AMOS;

          // Test that ;binary attribute is present
          NamingEnumeration<SearchResult> enm = ctx.search( base, filter, sctls);
          assertTrue(enm.hasMore());
          while (enm.hasMore())

          { SearchResult sr = enm.next(); attrs = sr.getAttributes(); Attribute attr = attrs.get("userCertificate;binary"); assertNotNull(attr); assertTrue( attr.contains( newValue ) ); byte[] certificate = (byte[])attr.get(); assertTrue( Arrays.equals( newValue, certificate ) ); assertEquals( 1, attr.size() ); }

          }

          Show
          Stefan Seelmann added a comment - Moved back to Server. I found two more bugs: 1st) There is a problem when writing ;binary values greater than 0x80. The following test write four bytes 0x80, 0x81, 0x82, 0x83 when reading it from the server I get 12 bytes. /** Add a new ;binary attribute with bytes greater than 0x80 to a person entry. Test for DIRSERVER-1146 @throws NamingException */ public void testAddNewBinaryAttributeValue0x80() throws NamingException { // Add a ;binary attribute with high-bytes byte[] newValue = new byte[] {(byte)0x80, (byte)0x81, (byte)0x82, (byte)0x83} ; Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue ); ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs ); // Verify, that attribute value is added attrs = ctx.getAttributes( RDN_TORI_AMOS ); Attribute attr = attrs.get( "userCertificate" ); assertNotNull( attr ); assertTrue( attr.contains( newValue ) ); byte[] certificate = (byte[])attr.get(); assertTrue( Arrays.equals( newValue, certificate ) ); assertEquals( 1, attr.size() ); } 2nd) Reading the entry and requesting userCertificate;binary (including the ;binary) doesn't work /** Retrieve a ;binary attribute from a person entry. Test for DIRSERVER-1146 @throws NamingException */ public void testRetrieveEntryWithBinaryAttributeValue() throws NamingException { // Add a ;binary attribute byte[] newValue = new byte[] {0x00, 0x01, 0x02, 0x03} ; Attributes attrs = new AttributesImpl( "userCertificate;binary", newValue ); ctx.modifyAttributes( RDN_TORI_AMOS, DirContext.ADD_ATTRIBUTE, attrs ); // Search entry an request ;binary attribute SearchControls sctls = new SearchControls(); sctls.setSearchScope(SearchControls.OBJECT_SCOPE); sctls.setReturningAttributes( new String[] { "userCertificate;binary" } ); String filter = "(objectClass=*)"; String base = RDN_TORI_AMOS; // Test that ;binary attribute is present NamingEnumeration<SearchResult> enm = ctx.search( base, filter, sctls); assertTrue(enm.hasMore()); while (enm.hasMore()) { SearchResult sr = enm.next(); attrs = sr.getAttributes(); Attribute attr = attrs.get("userCertificate;binary"); assertNotNull(attr); assertTrue( attr.contains( newValue ) ); byte[] certificate = (byte[])attr.get(); assertTrue( Arrays.equals( newValue, certificate ) ); assertEquals( 1, attr.size() ); } }
          Stefan Seelmann made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Emmanuel Lecharny added a comment -

          I can make the first test working easily, but not the second.

          In fact, I can get the entry to be found, and returned, but the Attribute attr = attrs.get("userCertificate;binary") call won't work,
          as the entry come back with "userCertificate" without the ";binary" string into it.

          I don't see easy ay to fix it, unless we decide to support attribute options, which will be a huge modification.

          How urgent is this ?

          Show
          Emmanuel Lecharny added a comment - I can make the first test working easily, but not the second. In fact, I can get the entry to be found, and returned, but the Attribute attr = attrs.get("userCertificate;binary") call won't work, as the entry come back with "userCertificate" without the ";binary" string into it. I don't see easy ay to fix it, unless we decide to support attribute options, which will be a huge modification. How urgent is this ?
          Hide
          Emmanuel Lecharny added a comment -

          In order to correctly handle these cases, we have to support attributeType options, like binary.

          All what have done until now is to hack the code. Let' fix this in 1.5.4.

          Show
          Emmanuel Lecharny added a comment - In order to correctly handle these cases, we have to support attributeType options, like binary. All what have done until now is to hack the code. Let' fix this in 1.5.4.
          Hide
          Emmanuel Lecharny added a comment -

          Postponed to 1.5.4.

          A fix has been applied to allow certificates with bytes above 0x7F, so the initial problem (DIRSERVER-1197) should now be fixed

          Show
          Emmanuel Lecharny added a comment - Postponed to 1.5.4. A fix has been applied to allow certificates with bytes above 0x7F, so the initial problem ( DIRSERVER-1197 ) should now be fixed
          Emmanuel Lecharny made changes -
          Fix Version/s 1.5.4 [ 12313147 ]
          Fix Version/s 1.5.3 [ 12312693 ]
          Hide
          Alex Karasulu added a comment -

          Handle this in 1.5.7 where we confront issue of tags.

          Show
          Alex Karasulu added a comment - Handle this in 1.5.7 where we confront issue of tags.
          Alex Karasulu made changes -
          Fix Version/s 1.5.7 [ 12313384 ]
          Fix Version/s 1.5.4 [ 12313147 ]
          Hide
          Rihards Gailums added a comment -

          This issue seems to affect all versions of Mozilla Thunderbird like 2.0.0.21 till latest nightly build 3.0
          When trying to send S/MIME encrypted e-mail, it send usercertificate;binary request ,but get usercertificate=., as result fail to find certificate.
          I would say this is major and urgent problem to resolve.

          Show
          Rihards Gailums added a comment - This issue seems to affect all versions of Mozilla Thunderbird like 2.0.0.21 till latest nightly build 3.0 When trying to send S/MIME encrypted e-mail, it send usercertificate;binary request ,but get usercertificate=., as result fail to find certificate. I would say this is major and urgent problem to resolve.
          Hide
          Emmanuel Lecharny added a comment -

          Let's see if we can fix that before 1.5.5, as we have missed the opportunity to release last week.

          Show
          Emmanuel Lecharny added a comment - Let's see if we can fix that before 1.5.5, as we have missed the opportunity to release last week.
          Emmanuel Lecharny made changes -
          Fix Version/s 1.5.5 [ 12313148 ]
          Fix Version/s 1.5.7 [ 12313384 ]
          Emmanuel Lecharny made changes -
          Status Reopened [ 4 ] In Progress [ 3 ]
          Hide
          Emmanuel Lecharny added a comment -

          Almost impossible to fix without reviewing the whole Entry manipulation system. The first case can be fix (allowing values above 0x80), as it's a simple check in the decoder, but the second case impact the changeLog system, as we need to manipulate ClientEntry in the LDIF revertor. ClientEntry don't have any knowledge currently about options or AttributeType, so it's very difficult to fix it.

          We will have to postpone this to a later version, I'm afraid ...

          Show
          Emmanuel Lecharny added a comment - Almost impossible to fix without reviewing the whole Entry manipulation system. The first case can be fix (allowing values above 0x80), as it's a simple check in the decoder, but the second case impact the changeLog system, as we need to manipulate ClientEntry in the LDIF revertor. ClientEntry don't have any knowledge currently about options or AttributeType, so it's very difficult to fix it. We will have to postpone this to a later version, I'm afraid ...
          Hide
          Emmanuel Lecharny added a comment -

          Partial fix :
          http://svn.apache.org/viewvc?rev=774815&view=rev

          It solves the first case (values > 0x7F in the attribute)

          Show
          Emmanuel Lecharny added a comment - Partial fix : http://svn.apache.org/viewvc?rev=774815&view=rev It solves the first case (values > 0x7F in the attribute)
          Hide
          Emmanuel Lecharny added a comment -

          Postponed to 2.0.0-RC1

          Show
          Emmanuel Lecharny added a comment - Postponed to 2.0.0-RC1
          Emmanuel Lecharny made changes -
          Fix Version/s 2.0.0-RC1 [ 12313387 ]
          Fix Version/s 1.5.5 [ 12313148 ]
          Hide
          Emmanuel Lecharny added a comment -

          Both tests has been added and now work.

          However, I have modified the test in order to have it working : when checking for the userCertificate in the returned entry, I have removed the ';binary' postfix as JNDI isn't able to handle this option.

          This is not perfect, but at least, one can search for "userCertificate;binary" and get back the attribute value.

          Show
          Emmanuel Lecharny added a comment - Both tests has been added and now work. However, I have modified the test in order to have it working : when checking for the userCertificate in the returned entry, I have removed the ';binary' postfix as JNDI isn't able to handle this option. This is not perfect, but at least, one can search for "userCertificate;binary" and get back the attribute value.
          Emmanuel Lecharny made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Emmanuel Lecharny made changes -
          Fix Version/s 2.0-M1 [ 12316055 ]
          Fix Version/s 2.0.0-RC1 [ 12313387 ]
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Version 2.0.0-M1 has been release.
          Closing all related resolved issues.

          Show
          Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M1 has been release. Closing all related resolved issues.
          Pierre-Arnaud Marcelot made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          gunter zeilinger added a comment -

          attrs.get("userCertificate;binary") still (2.0.0-M3) returns null!

          Show
          gunter zeilinger added a comment - attrs.get("userCertificate;binary") still (2.0.0-M3) returns null!
          gunter zeilinger made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          gunter zeilinger made changes -
          Link This issue is related to DIRSERVER-1681 [ DIRSERVER-1681 ]
          Hide
          Emmanuel Lecharny added a comment -

          The fact that attrs.get( "userCertificate;binary" ) does not work is not a server issue : its a problem with JNDI.

          Show
          Emmanuel Lecharny added a comment - The fact that attrs.get( "userCertificate;binary" ) does not work is not a server issue : its a problem with JNDI.
          Emmanuel Lecharny made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Emmanuel Lecharny
              Reporter:
              Chris Trobridge
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development