Uploaded image for project: 'Directory Studio'
  1. Directory Studio
  2. DIRSTUDIO-1108

Getting Invalid Certificate for userCertificate;binary entry when connecting with LDAPS, LDAP works fine

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M10 (2.0.0.v20151221-M10)
    • Fix Version/s: 2.0.0-M11, 2.0.0-M12
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      Apache Directory Studio running on:
      - Windows7/Java8,
      - CentOS7/Java8,
      - CentOS6/Java7.

      Description

      Hello Apache Directory Studio development team.

      we are using Apache Directory Studio here in Version: 2.0.0.v20151221-M10.

      When I connect with it to an LDAP directory server with LDAP unencrypted (TCP389) the userCertificate;binary entry can be obtained just fine including its loading into the build-in Certificate Editor.

      But connecting to the same LDAP directory encrypted (TCP636), that same userCertificate;binary entry can't be read and Directory Studio is returning "Invalid Certificate" and then "Can't parse certificate".

      This is reproducable with Apache Directory Studio on the following environments I have available here to test:

      • Windows7/Java8,
      • CentOS7/Java8,
      • CentOS6/Java7.

      As well with the relevant command line tools like ldapsearch, ldapmodify etc. I am able to obtain or manipulate that entry on LDAP and LDAPS sockets and even with the "ancient" freeware LDAP-Browser 2.8.2 by Jarek Gawor, Copyright (c) 1998 University of Chicago I still have this is possible.

      The directory server used here is running on OpenLDAP. But also when obtaining this with LDAPS from a directory server with the same structure running on OpenDJ, the "Invalid Certificate" is thrown.

      That said I think this could be a possible bug - also considering that in my understanding obtaining an (attribute) entry or rather (reading and parsing) its content from a directory server, should be independant at all on how I connect to that directory server (LDAP vs. LDAPS) - isn't it?

      In case additional details would be needed I will gladly try to provide them. Please let me know.

      I also could provide you a PDF-file containing additional screenshots for the above description.

      Thank you in advance for your help and looking into it.

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        Which format were you using for your certificate ? The two error messages you've got was related to the fact that the value is not seen as binary (Invalid Certificate) and that the certificate is not a valid X.509 certificate (Can't parse certificate).

        Show
        elecharny Emmanuel Lecharny added a comment - Which format were you using for your certificate ? The two error messages you've got was related to the fact that the value is not seen as binary ( Invalid Certificate ) and that the certificate is not a valid X.509 certificate ( Can't parse certificate ).
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Side note : you can desactivate the certificate editor in order to see your certificate as a default String, in preference -> Apache Directory Studio -> LDAP Browsers -> Value Editors, then edit the Value Editors by Syntax and change the Certificate value editor from Certificate Editor to Hex Editor

        Show
        elecharny Emmanuel Lecharny added a comment - Side note : you can desactivate the certificate editor in order to see your certificate as a default String, in preference -> Apache Directory Studio -> LDAP Browsers -> Value Editors, then edit the Value Editors by Syntax and change the Certificate value editor from Certificate Editor to Hex Editor
        Hide
        inb Ingo Bahn added a comment -

        Hello Mr. Lecharny,

        thank you for the quick reply and as well pointing out where to change the setting for the Certificate Editor. That was new to me at all.

        But it didn't help however. I am still getting the same. The below screenshots hopefully help additionally to explain what is the case here.

        The actual certificate was loaded in the first place by a bulk transfer from the command line and having the Certificate in DER / "binary" format.

        I however loaded / replaced today the Certificate in PEM format, as logged in the attached TXT file [1].

        But even after that in Apache Directory Studio one still gets here "Invalid Certificate" for UserCertificate (OID: 1.3.6.1.4.1.1466.115.121.1.8) displayed when connecting to the LDAP server through a TLS/SSL socket (LDAPS), Pic2.

        Connecting to it by "plain" LDAP (no TLS/SSL socket) all is displayed as expected, Pic1. That is the "weired" part to me.

        And As can be seen at the end of [1] however, even if I import the certificate as PEM, it is still stored in DER / binary format in the LDAP directory; because openssl (...-inform pem) throws me an error if I try to read the UserCertificate in PEM format directly from the LDAP directory.

        I hope this helps further.

        With best regards and have a good weekend ahead.

        Ingo Bahn

        Attachment:
        "2016_07_29_001_DIRSTUDIO-1108_Activites.txt"

        Pic1 - Obtaining attribute userCertificate;binary on unencrypted socket (LDAP, TCP389) from directory server

        Pic2 - Obtaining attribute userCertificate;binary (from Pic1) on encrypted socket (LDAPS, TCP636) from directory server

        -------- -------- -------- --------
        Ingo Bahn (ISO 27001 certified)
        gematik / test and certification

        phone: +49 (30) 400 41-458
        e-mail: ingo.bahn@gematik.de<ingo.bahn@gematik.de>
        www.gematik.de<http://www.gematik.de/>

        gematik
        Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
        Friedrichstrasse 136
        10117 Berlin
        Germany
        Local district court Berlin-Charlottenburg, register of companies ID: HRB 96351 B
        Executive director: Alexander Beyer

        "Knowledge not shared is useless."
        .

        [ https://issues.apache.org/jira/browse/DIRSTUDIO-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398794#comment-15398794 ]

        Emmanuel Lecharny commented on DIRSTUDIO-1108:
        ----------------------------------------------

        Side note : you can desactivate the certificate editor in order to see your certificate as a default String, in preference -> Apache Directory Studio -> LDAP Browsers -> Value Editors, then edit the Value Editors by Syntax and change the Certificate value editor from Certificate Editor to Hex Editor


        This message was sent by Atlassian JIRA
        (v6.3.4#6332)

        Show
        inb Ingo Bahn added a comment - Hello Mr. Lecharny, thank you for the quick reply and as well pointing out where to change the setting for the Certificate Editor. That was new to me at all. But it didn't help however. I am still getting the same. The below screenshots hopefully help additionally to explain what is the case here. The actual certificate was loaded in the first place by a bulk transfer from the command line and having the Certificate in DER / "binary" format. I however loaded / replaced today the Certificate in PEM format, as logged in the attached TXT file [1] . But even after that in Apache Directory Studio one still gets here "Invalid Certificate" for UserCertificate (OID: 1.3.6.1.4.1.1466.115.121.1.8) displayed when connecting to the LDAP server through a TLS/SSL socket (LDAPS), Pic2. Connecting to it by "plain" LDAP (no TLS/SSL socket) all is displayed as expected, Pic1. That is the "weired" part to me. And As can be seen at the end of [1] however, even if I import the certificate as PEM, it is still stored in DER / binary format in the LDAP directory; because openssl (...-inform pem) throws me an error if I try to read the UserCertificate in PEM format directly from the LDAP directory. I hope this helps further. With best regards and have a good weekend ahead. Ingo Bahn Attachment: "2016_07_29_001_ DIRSTUDIO-1108 _Activites.txt" Pic1 - Obtaining attribute userCertificate;binary on unencrypted socket (LDAP, TCP389) from directory server Pic2 - Obtaining attribute userCertificate;binary (from Pic1) on encrypted socket (LDAPS, TCP636) from directory server -------- -------- -------- -------- Ingo Bahn (ISO 27001 certified) gematik / test and certification phone: +49 (30) 400 41-458 e-mail: ingo.bahn@gematik.de< ingo.bahn@gematik.de > www.gematik.de< http://www.gematik.de/ > gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH Friedrichstrasse 136 10117 Berlin Germany Local district court Berlin-Charlottenburg, register of companies ID: HRB 96351 B Executive director: Alexander Beyer "Knowledge not shared is useless." . [ https://issues.apache.org/jira/browse/DIRSTUDIO-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398794#comment-15398794 ] Emmanuel Lecharny commented on DIRSTUDIO-1108 : ---------------------------------------------- Side note : you can desactivate the certificate editor in order to see your certificate as a default String, in preference -> Apache Directory Studio -> LDAP Browsers -> Value Editors, then edit the Value Editors by Syntax and change the Certificate value editor from Certificate Editor to Hex Editor – This message was sent by Atlassian JIRA (v6.3.4#6332)
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Hi,
        sorry, but I can't open the attachement (winmail.dat). Can you attache each screenshot separately ? Thanks !

        Otherwise, AFAIU, you can see teh certificate when not using LDAPS, right ? Can you do a quick test : in the connection property, change the Provider and select JNDI, to see if it's any batter.

        Thanks !

        Show
        elecharny Emmanuel Lecharny added a comment - Hi, sorry, but I can't open the attachement ( winmail.dat ). Can you attache each screenshot separately ? Thanks ! Otherwise, AFAIU, you can see teh certificate when not using LDAPS, right ? Can you do a quick test : in the connection property, change the Provider and select JNDI, to see if it's any batter. Thanks !
        Hide
        inb Ingo Bahn added a comment -

        Thank you again.

        Yes that's correct. And I also figured out how to attach files and such to Jira directly, which I just did. (My bad, first time I am working with the Jira ticketing system.)

        And changing the JNDI in the connection properties did not help either.

        With best regards

        Ingo

        -------- -------- -------- --------
        Ingo Bahn
        gematik / test and certification

        phone: +49 (30) 400 41-458
        e-mail: ingo.bahn@gematik.de

        "Knowledge not shared is useless."
        .

        Show
        inb Ingo Bahn added a comment - Thank you again. Yes that's correct. And I also figured out how to attach files and such to Jira directly, which I just did. (My bad, first time I am working with the Jira ticketing system.) And changing the JNDI in the connection properties did not help either. With best regards Ingo -------- -------- -------- -------- Ingo Bahn gematik / test and certification phone: +49 (30) 400 41-458 e-mail: ingo.bahn@gematik.de "Knowledge not shared is useless." .
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Ok, this is clearly a bug, when it works with LDAP but not with LDAPS. We will have to test that with the element you provided. It may take a bit of time.

        In any case, many thanks for this clear report, thsi is very helpful !

        Show
        elecharny Emmanuel Lecharny added a comment - Ok, this is clearly a bug, when it works with LDAP but not with LDAPS. We will have to test that with the element you provided. It may take a bit of time. In any case, many thanks for this clear report, thsi is very helpful !
        Hide
        seelmann Stefan Seelmann added a comment -

        I tried to reproduce the issue today, of course not being able to reproduce it, and already gave up. Then I looked again at the screenshots and had the eureka moment

        On Pic2 I recognized that all the attributes are in italic font, and in the Browser view all icons are the default folder icon instead of the person icon. That means that the schema was not loaded, in that case (unfortunately) the attribute is treated as string instead of binary. This is most likely caused by a bug DIRMINA-1023 in Mina 2.0.10.

        In the end I was able to reproduce the issue:

        • Use Studio 2.0.0-M10
        • Create a LDAPS connection to OpenLDAP
        • Opening the connection hangs forever, caused by bug DIRMINA-1023
        • Kill Studio and start it again
        • Open the connection again, now the connection can be opened, the schema is not loaded again, but same issue with userCertificat;binary occurs.

        The issue is solved in trunk and in upcoming Studio 2.0.0-M11. You can either test a snapshot version from https://builds.apache.org/view/A-D/view/Directory/job/dir-studio/. Or, if you want to stay with M10 you can change the connection temporaryly non-encrypted connection, reload the schema (connection properties -> schema -> reload button) and switch back to encrypted connection afterwards as the schema is cached.

        Show
        seelmann Stefan Seelmann added a comment - I tried to reproduce the issue today, of course not being able to reproduce it, and already gave up. Then I looked again at the screenshots and had the eureka moment On Pic2 I recognized that all the attributes are in italic font, and in the Browser view all icons are the default folder icon instead of the person icon. That means that the schema was not loaded, in that case (unfortunately) the attribute is treated as string instead of binary. This is most likely caused by a bug DIRMINA-1023 in Mina 2.0.10. In the end I was able to reproduce the issue: Use Studio 2.0.0-M10 Create a LDAPS connection to OpenLDAP Opening the connection hangs forever, caused by bug DIRMINA-1023 Kill Studio and start it again Open the connection again, now the connection can be opened, the schema is not loaded again, but same issue with userCertificat;binary occurs. The issue is solved in trunk and in upcoming Studio 2.0.0-M11. You can either test a snapshot version from https://builds.apache.org/view/A-D/view/Directory/job/dir-studio/ . Or, if you want to stay with M10 you can change the connection temporaryly non-encrypted connection, reload the schema (connection properties -> schema -> reload button) and switch back to encrypted connection afterwards as the schema is cached.
        Hide
        inb Ingo Bahn added a comment -

        Dear madam or sir,

        thank you for your message.

        I am currently out of the office with no access to my emails and will be back in the office on Tu, 04-Oct-2016.

        Your message won't be forwarded.

        With best regards and have a nice day.

        Ingo Bahn

        -------- -------- -------- --------
        Ingo Bahn (ISO27001 certified)
        gematik / test and certification

        phone: +49 (30) 400 41-458
        e-Mail: ingo.bahn at gematik.de
        www.gematik.de<http://www.gematik.de/>

        gematik
        Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
        Friedrichstrasse 136
        10117 Berlin
        Germany
        Local district court Berlin-Charlottenburg, register of companies ID: HRB 96351
        Managing director: Alexander Beyer
        .

        Show
        inb Ingo Bahn added a comment - Dear madam or sir, thank you for your message. I am currently out of the office with no access to my emails and will be back in the office on Tu, 04-Oct-2016. Your message won't be forwarded. With best regards and have a nice day. Ingo Bahn -------- -------- -------- -------- Ingo Bahn (ISO27001 certified) gematik / test and certification phone: +49 (30) 400 41-458 e-Mail: ingo.bahn at gematik.de www.gematik.de< http://www.gematik.de/ > gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH Friedrichstrasse 136 10117 Berlin Germany Local district court Berlin-Charlottenburg, register of companies ID: HRB 96351 Managing director: Alexander Beyer .
        Hide
        inb Ingo Bahn added a comment -

        Hello Mr. Seelmann and Apache team,

        first my apologies it took a while to come back to you on that ticket.

        Thank you for your replies since not ot mention the little insights given.

        After installing the M12 release on all three environments I reported that issue on earlier this year, I confirm this being resolved. Also on a LDAPS-socket the "user certificate" attribute is displayed now as it is on a LDAP-socket.

        Hence from my point of view the ticket can be closed.

        Thank you very much for your help and best wishes for the holidays.

        With best regards

        Ingo Bahn

        .

        Show
        inb Ingo Bahn added a comment - Hello Mr. Seelmann and Apache team, first my apologies it took a while to come back to you on that ticket. Thank you for your replies since not ot mention the little insights given. After installing the M12 release on all three environments I reported that issue on earlier this year, I confirm this being resolved. Also on a LDAPS-socket the "user certificate" attribute is displayed now as it is on a LDAP-socket. Hence from my point of view the ticket can be closed. Thank you very much for your help and best wishes for the holidays. With best regards Ingo Bahn .
        Hide
        inb Ingo Bahn added a comment -

        Works fine now as should. More details refer also today's (12/22/2016) ticket comment.

        Thank you again.

        Ingo Bahn

        Show
        inb Ingo Bahn added a comment - Works fine now as should. More details refer also today's (12/22/2016) ticket comment. Thank you again. Ingo Bahn

          People

          • Assignee:
            Unassigned
            Reporter:
            inb Ingo Bahn
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development