Is there a consistent documentation to setup search services and keystores ? Or source for 2.0.5 ?

[mikef38]

Maybe the keystores created by ssl-tool are bad ?

I simply used :

./run.sh  -keystorepass ks+xxxxxxx -truststorepass trs+xxxxxxx -encmetadatapass enc+xxxxxxx -encstorepass enc+xxxxxxx

and then copied respectively the keystore and trustore found in alfresco and solr to their location.

For solr, I have to put a copy of them under each core else in another location solr complains.

The content of the stores are :

keystore:
Type de fichier de clés : JCEKS
Fournisseur de fichier de clés : SunJCE

Votre fichier de clés d'accès contient 2 entrées

ssl.alfresco.ca, 10 févr. 2023, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 73:58:B4:16:64:C5:69:F6:5A:5C:35:FA:B1:49:66:06:10:43:9F:6D:50:B9:B0:DA:0B:EA:8F:21:30:BB:24:87
ssl.repo.client, 10 févr. 2023, PrivateKeyEntry, 
Empreinte du certificat (SHA-256) : 38:F6:BA:0C:0E:28:7F:B1:D3:A1:68:1C:46:37:56:54:CA:B0:35:87:2C:8E:54:62:DE:C3:E8:7D:45:59:B0:41

truststore:
Type de fichier de clés : JCEKS
Fournisseur de fichier de clés : SunJCE

Votre fichier de clés d'accès contient 3 entrées

alfresco.ca, 10 févr. 2023, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 73:58:B4:16:64:C5:69:F6:5A:5C:35:FA:B1:49:66:06:10:43:9F:6D:50:B9:B0:DA:0B:EA:8F:21:30:BB:24:87
ssl.repo, 10 févr. 2023, trustedCertEntry, 
Empreinte du certificat (SHA-256) : C0:3C:23:2F:36:45:02:AD:F4:B4:8F:12:63:44:6E:7F:04:B2:59:DA:C3:20:A0:40:AD:EE:7D:6D:55:2A:77:A1
ssl.repo.client, 10 févr. 2023, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 38:F6:BA:0C:0E:28:7F:B1:D3:A1:68:1C:46:37:56:54:CA:B0:35:87:2C:8E:54:62:DE:C3:E8:7D:45:59:B0:41

[mikef38]

Another part of the configuration that is involved, Tomcat connector for Solr requests:

    <Connector port="8454" protocol="HTTP/1.1"
     SSLEnabled="true" maxThreads="150" scheme="https"
     keystoreFile="/opt/Alfresco/alf_data_7/keystore/ssl.keystore"
     keystorePass="ks+xxxxxxxx" keystoreType="JCEKS"
     secure="true" connectionTimeout="240000"
     truststoreFile="/opt/Alfresco/alf_data_7/keystore/ssl.truststore"
     truststorePass="trs+xxxxxxxx" truststoreType="JCEKS"
     clientAuth="false" sslProtocol="TLS" />

Note that the port is 8454, firstly because on 8443/8444 there is older Tomcat running an old Alfresco 5.0, that works perfectly, secondly because the main SSL port (usually 8443, here 8453) is used for human access with an official domain certificate, so there is a 2nd connector on port 8454 for Solr and its certificates. I don't even understand why all the documentations insist on serving Solr on port 8443, how can it work in a real setup where this port is the standard Tomcat port to serve the user's browsers ?

[mikef38]

I still add information in the hope that someone knowng Alfresco 7 will figure what to do.

As said before, 2 SSL connectors are defined in server.xml, one referencing a keystore will an official certificate, and one with the certificate purposely created to interact with the search services.

They are on different ports and the search services are correctly configured to use the right port.

8453 = connection from a browser, official certificate in its own keystore

8454 = connection from the search services, certificates and keys in the keystore created by ssl-tool and shared with the search services.

This setup works perfectly with Alfresco 5.

If I remove the first connector and keep only the one on port 8454, there is no more the error 403 on the search services log and it seems that Alfresco answers correctly with the change lists.

What should I do to both give access to the search services, and let the users access Alfresco on port 8453 ?

[angelborroy]

Did you try setting expected port in solrcore.properties file?

https://github.com/Alfresco/SearchServices/blob/master/search-services/alfresco-search/src/main/reso...

alfresco.port.ssl=8454

[mikef38]

Hello

Yes, I did. Else it would not work at all when I remove the other connector (for browser access). BTW Solr creates this file in the core directory which helps settings keys, although in messy order, 1st thing I did is order alphabetically the properties file to find the keys in my text editor and avoid duplicates.

So it appears that I set

clientAuth="false"

in the Connector tag (see message with the Connector data) which is the culprit here. 

The advised value in one of your documentations was "want". I guess that among all tries and errors and various posts I put false at some time, my bad. It is very consistent with the fact that Tomcat didn't provide the certificate data to Alfresco.  However I found that if I set clientAuth="required" (as per Tomcat 9 documentation), it looks like it works too. Maybe.

Now Solr is indexing, I checked with the admin tool that it does and that I can find my documents from there.

However Alfresco doesn't find nothing, and the transform service doesn't work either (hence text indexing doesn't work) although I tried to follow the 20 pages tutorial you quoted but that's another story, I have first to investigate by myslelf.

Thank you for the help!

[angelborroy · Accepted solution]

You can always try Docker Compose for reference configuration:

https://github.com/alfresco/alfresco-docker-installer

https://github.com/aborroy/alfresco-installer

Despite you are not deploying in Docker and so on... just to read expected configuration from a running environment.

[mikef38]

Thank you for the advice, so I went there and browsed the project and found the installation script where they set up the solr SSL port and see how it's done. Yet another parameter that was set correctly in my configuration during the 1st pass and then messed when nothing was working...

Also I fixed the problem with transform services, which was a small mistake in alfresco-global.properties. I don't know if all transforms work, but at least I get thumbnails of PDF or Office files and full text search works.

Thank you very much for your help.

[angelborroy]

Great you have it working!

Thanks for completing the thread with the feedback.