Secure traffic between Repository and Solr (2) - Alfresco Content Services - 23.4 - 23.4 - Ready - Alfresco - external

Alfresco Content Services

Platform
Alfresco
Product
Alfresco Content Services
Release
23.4
License

The Repository and Solr are separate web applications. Regardless of whether or not these webapps are running in the same Tomcat server, different Tomcat servers, or even different machines, they use HTTP to communicate with each other.

Note: the communication between Solr and the Repository is NOT encrypted by default. See Docker Compose and Helm configurations. The reason for this is that providing SSL encryption out-of-the-box is always tricky. For example, providing default certificates make no sense, and generated self signed certs my not fit your policy if you have your own PKI. What we provide in terms of helm charts are building blocks for you to build upon, it’s not a production ready configuration.

When secure communication is turned on between Solr and the Repository the Solr web application uses certificate-based client authentication (i.e. so the Repository knows that it is really Solr talking to it). But, by default, the certificate Solr uses for both encryption and authentication is the one that Alfresco generates and ships with the product. This means that, by default, if someone can get to your Solr port (8983, by default) they can search your entire content repository because the public has easy access to that Alfresco-generated, default client certificate.

To fix this turn on secure communcation between Solr and the Repository and re-generate the certificate.

See the Search Services security documentation for information on how to set this up on Windows or Linux.

See also Manage Alfresco keystores for introduction and configuration of the different keystores.