The site is up and working for 5.1.g. However, the catalina.out log is peppered with gigabytes of the following:
2017-02-02 16:17:30,049 ERROR [solr.tracker.AbstractTracker] [SolrTrackerScheduler_Worker-17] Tracking failed
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
This is weird because externally the website is fine, the certs are all accepted. Internally on the server, the other services besides SOLR aren't having an issue. I suspect that whatever this service is supposed to do it failing, but it's not apparent to using the system. I've checked and double checked that configurations are correct to the best of my knowledge.
Where else can I look?
Solved! Go to Solution.
You could try adding your cert to the keystore. Far better would be to create a new Connector that is listening on 443 and use that for external connections hitting the server, or even better would be to install an HTTP server with mod_ajp and use that to handle SSL, which is the best and most common practice.
If you are going to use your own cert for SOLR, you have to edit tomcat-users.xml and set the cert DN.
You should also look at this doc which talks about how SOLR security is set up: Solr 4 security | Alfresco Documentation
Alfresco ships with its own client cert that is used by the SOLR server to authenticate requests coming from Alfresco. The log messages you are seeing indicate that something is wrong with the client certificate that Alfresco and SOLR are using.
This setup depends on Tomcat config and a keystore that, by default, resides in the alf_data directory.
Did you install using the installer?
Is your keystore directory where Alfresco expects?
Did you make any changes to Tomcat's server.xml or other Tomcat config?
Did you re-generate the SOLR SSL Certificate? If so, did you change the certificate's DN? If so, did you make the same change in the Tomcat config?
Did you make any changes to the Solr cores or their configuration (they also point to the keystore)?
> Did you install using the installer?
Yes
> Is your keystore directory where Alfresco expects?
Yes
> Did you make any changes to Tomcat's server.xml or other Tomcat config?
Yes, I installed my own keystore with my own SSL certification issued by a provided we're required to use. Further, I set it up to use 8443 for connections which was also required by our organization's network team. I noticed that SOLR used 8443, but that was via localhost.
> Did you re-generate the SOLR SSL Certificate? If so, did you change the certificate's DN? If so, did you make the same change in the Tomcat config?
I did not.
> Did you make any changes to the Solr cores or their configuration (they also point to the keystore)?
No
Can I just take the existing Alfresco keystore and add my cert to that? I think this is the root of the problem.
You could try adding your cert to the keystore. Far better would be to create a new Connector that is listening on 443 and use that for external connections hitting the server, or even better would be to install an HTTP server with mod_ajp and use that to handle SSL, which is the best and most common practice.
If you are going to use your own cert for SOLR, you have to edit tomcat-users.xml and set the cert DN.
You should also look at this doc which talks about how SOLR security is set up: Solr 4 security | Alfresco Documentation
I ripped all certs out of Alfresco config and put Nginx in front of it. That was a lot smoother and cleaner.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.