[
https://issues.apache.org/jira/browse/DIRSTUDIO-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521456#comment-15521456
]
Stefan Seelmann commented on DIRSTUDIO-1108:
--------------------------------------------
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.
> Getting Invalid Certificate for userCertificate;binary entry when connecting
> with LDAPS, LDAP works fine
> --------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-1108
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1108
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 2.0.0-M10 (2.0.0.v20151221-M10)
> Environment: Apache Directory Studio running on:
> - Windows7/Java8,
> - CentOS7/Java8,
> - CentOS6/Java7.
> Reporter: Ingo Bahn
> Priority: Minor
> Attachments: 2016_07_29_001_DIRSTUDIO-1108_Activites.txt,
> 2016_07_29_ApacheDirectoryStudio_GettingInvalidCertificateWithLDAPS.pdf,
> winmail.dat
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
