Replacing self-signed certificates with Zentyal-generated certificates

[dfliddle]

In order to provide our staff with a consistent experience with each of the servers we run, I'm replacing self-signed certificates with those issued by our Zentyal server, which is acting as the CA. I haven't found entries in either this forum or Zentyal's that deal with this particular topic thoroughly. What I have done so far is to work (unsuccessfully) through the instructions in the following locations, which seem to be similar:

• /opt/alfresco-4.2.c/alf_data/keystore/CreateSSLKeystores.txt
• http://docs.alfresco.com/4.2/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Ftasks%2Fgenerate-repo-...
• https://wiki.alfresco.com/wiki/Alfresco_And_SOLR#Manually_Generating_New_SSL_Keys_Signed_by_a_Certif...

My first question is this: Am I even starting in the right place with the right instructions?

With respect to these instructions, I noticed that there are a few aliases used for the certificates in the keystores, e.g. ssl.repo, ssl.alfresco.ca, and alfresco.ca. These aliases are referred to in each of the *-passwords.properties files.

My second question is: Does it matter how these aliases are named? That is, are there any important references to them apart from the link between each keystore and its corresponding password properties file?

When the Zentyal Certification Authority is activated and configured, it creates these files:

• ca-cert.pem
• ca-public-key.pem

And when it creates a new certificate, it generates these files:

• Alfresco-cert.pem
• Alfresco.p12
• Alfresco-private-key.pem
• Alfresco-public-key.pem

When working through the instructions above, I have tried to do so both with and without the existing keystores. After failures, I have run the generate_keystores.sh script. Nothing seems broken, and I see no errors in the logs after restarting the server.

My third question is: If I should be using the above instructions, should I create new keystores and then simply replace the old ones?

In the instruction at the Alfresco Wiki link above, I noticed the following:

Note
    if using Tomcat, the values for the above prompts must match those defined in the tomcat-users.xml file for the following entry:
<user username="CN=Alfresco Repository, OU=Unknown, O=Alfresco Software Ltd., L=Maidenhead, ST=UK, C=GB" roles="repository" password="null"/>

My fourth question is: If I am following the instruction correctly, do I understand rightly that I need to modify this line to fit the values in the Zentyal-issued certificate?

Before I report the errors I experience, I would like to know the answers to these questions. It probably doesn't help to copy in error codes if I'm on the wrong track anyway.

My thanks to each of you who take the time to read this, and many more to those who respond.

[heiko_robert]

Hi David,

I would recommend not to go this way. Instead you should configure an apache in front of tomcat. This is best practice for all our installations and much, much more easy to handle. As a side effect you can harden Alfresco, create redirects and open just the URLs and requests using apache config. Tomcat should be configured to talk only to apache and SOLR.
Anyway you should create new certificates to prevent that everyone can read your content with the default certs who has access to tomcat. For this Alfresco allready provides scripts not to make any mistakes.
Of course you can use commercial certs for the tomcat ssl connector but as long you don't understand the complexity in alfresco/SOLR communication and if you're not very familiar with openssl and keystore mechanisms you shouldn't touch this. Otherwise it is very likely that at least your SOLR search will not work any more. So don't go the trappy way if there is an easy and robust one.

[dfliddle]

Thank you for the reply, Heiko. I have seen many such recommendations for the Apache reverse proxy server, and using this technique could help simplify other services that we run. Do you know if it can handle the Alfresco IMAP component also? I have read of others attempting IMAP funneling with that and Nginx, but it's not always easy to tell how successful or satisfied they were.