SSL/HttpClient/SolrJ Classloader-Leak with invalid/damaged certificate in trust store
Closed this issue · 6 comments
Just a suggestion: I think I have found another classloader leak.
You can find the description of the Problem on Stackoverflow: http://stackoverflow.com/q/39741147/4864870
A demonstration project with a working preventor can be found here: https://github.com/CptS/solrj-classloader-leak
(This preventor is not yet implemented as "classloader-leak-prevention-Plugin", it's just a simple ServletContextListener and there is potential for improvement but maybe it could be interesting for you)
Hi @CPTS and thanks for the report!
I intended to dig into this issue, but I'm not able to reach 172.21.16.29:8984. Do you know of any publically accessible URL that demonstrates this behaviour?
From what I've seen so far I don't think the problem is with Solr and probably not HttpClient, so if you could just provide or instruct me how to create a certificate with an unparseable extension that'd probably be of help.
Hi, thanks for your answer.
I've added some information about the solr server (172.21.16.29:8984 was an internal solr server). You can just download and run a clean and plain solr instance. You don't have to configure anything in solr it's just needed for the network connection. Please have a look at https://github.com/CptS/solrj-classloader-leak#environment.
I don't know exactly where the certificate with the unparseable extension came from. I haven't installed any additional certificate in the keystore. The cacerts Keystore used in my tests is attached now in my GitHub repo. This should contain the invalid certificate.
I hope this helps.
It seems the leak can be triggered by first setting the system property javax.net.ssl.trustStore to the path of your keystore and then call javax.net.ssl.SSLContext.getDefault() (or javax.net.ssl.SSLSocketFactory.getDefault() which calls the former).
The certificate in the store with an unparseable extension is the one aliased debian:spi-cacert-2008.pem i.e. EMAILADDRESS=hostmaster@spi-inc.org, CN=Certificate Authority, OU=hostmaster, O=Software in the Public Interest, L=Indianapolis, ST=Indiana, C=US.
I have also posted a bug report to Oracle, and will get back once it is publicly available.
The Oracle bug report is here. The workaround provided by the ClassLoader Leak Prevention library is included in the just released version 2.1.0.
Great. Thank you! :)