|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
The nature of the LDAP service's certificate is a separate issue. Actually two separate issues. Self-signed cert.s are reasonable in some circumstances and should be permitted, but they should be permitted by installing the cert. in the servlet container's trust store so that it is accepted naturally, rather than bypassing trust checks. This is a container configuration issue which requires no support from DSpace.
OTOH an expired cert. is a problem that the LDAP service's maintainers should fix ASAP, and I don't think we should work to cater for others' sloppy practice if they don't. So here as well I see no reason to bypass trust checks.
If the SSL handshake failed, we should assume that it did so because the admin.s wanted it to, since they can (and should) easily fix the problem without touching DSpace.