Alfresco quiere sentirse seguro con SSL (¡por fin!)

¡Está chupado!!, pásate por este enlace:

http://docs.alfresco.com/5.0/tasks/configure-ssl-prod.html

¿Ya estás aquí de nuevo?, ¿no te has enterado?… lo suponía 😉

Cuando hace ya dos años y medio implanté el gestor documental «Alfresco Community» en mi empresa lo hice con la intención de cubrir las necesidades de archivo y versionado de la ISO 27001 que acabábamos de implantar con éxito, de ese modo evitábamos pagar por un servicio de archivo en la nube. Digan lo que digan la nube sigue siendo excesivamente cara como medio de almacenamiento y un servidor físico es hoy día más competitivo para estas lides.

Muchos de los que podáis llegar aquí estaréis familiarizados con la sencillez que tiene Apache para utilizar el protocolo SSL donde la simple adquisición o autoemisión de certificados SSL (mediante OpenSSL o PKI de dominio por ejemplo) permite en pocos minutos traspasar a «https» las comunicaciones entre servidor y cliente. Sin embargo, en Alfresco cuando intenté localizar la manera de hacerlo llegue a un infierno información inconexa, así que de forma muy resumida os daré los pasos para que lo tengáis chupado.

• Comenzamos solicitando el certificado correspondiente al dominio de nuestro servidor con el procedimiento habitual.
• Dado que la plataforma Alfresco tiene una contraseña por defecto generada en varios ficheros, os recomiendo que establezcáis esa misma contraseña para la llave privada (revisad el fichero server.xml).
• Si deseas cambiar esa contraseña deberás editar los ficheros *password.properties para también modificarlo en los diferentes submódulos de la suite Alfresco.
• El certificado deberá utilizar el formato PKCS12 con nombre alfresco.p12 (así aprovecharemos los .bat incluidos para incorporar a los «keystore» las diferentes claves). Deberá incluir la CA correspondiente de ser necesario.

¿No sabes hacerlo y tienes OpenSSL?, pues toma nota porque te doy los parámetros para que lo exportes desde tu PKI de dominio con el nombre «alfresco.pfx» si vas a utilizar un servidor en la red local, recuerda que deberás tener una plantilla de servidor en la que la clave privada sea exportable:

openssl pkcs12 -in alfresco.pfx -clcerts -out ssl.crt
openssl pkcs12 -in alfresco.pfx -nocerts -out ssl.key
@rem openssl pkcs12 -export -in ssl.crt -certfile midominio.crt -inkey ssl.key -out alfresco.p12 -name ssl.repo
@rem Descomentar lo de arriba y comentar lo de abajo si queremos integrar en la clave privada la pública del CA
openssl pkcs12 -export -in ssl.crt -inkey ssl.key -out alfresco.p12 -name ssl.repo
ren ssl.crt alfresco.cer
del ssl.key

En el caso de una PKI de dominio no es necesario incluir el certificado público pues el servidor estará integrado y ya confiará en esa CA, tampoco debería ser necesario en una CA pública de confianza, pero usando un certificado autofirmado (nada recomendable) deberemos crear un certificado de CA e incluirlo en el «alfresco.p12».

Os estoy ahorrando bastante trabajo de investigación con este pequeño .bat  ^_^

Copiaros el fichero alfresco.cer (formato x509) y alfresco.p12 generados por OpenSSL al servidor Alfresco que, no lo olvidéis, os recomiendo que uséis la contraseña que tengáis por defecto en vuestra instancia de Alfresco a la hora de fijar la de la clave privada. También necesitareis el certificado público de vuestro dominio o CA correspondiente.

Y aquí llega lo gordo, os dejo la adaptación del generate_keystores_domain.bat

Adaptar este fichero .bat a vuestros parámetros (ruta origen de certificados, nombre de vuestro certificado de CA…) y, naturalmente, entiendo que ya habéis configurado vuestro servidor Alfresco y se han desplegado los ficheros «war» de Alfresco y Share en sus respectivas ubicaciones y todo funciona perfectamente en el puerto 8080.

Si todo va bien no veréis error alguno y los ficheros estarán en sus lugares correspondientes. Estoy presuponiendo que tenéis unos conocimientos mínimos acerca de que es el «Common Name» de un certificado, de cómo se solicitan, gestionan las plantillas en un PKI, cómo funciona un DNS, etc.

¿Creías que ya podías arrancar Alfresco con SSL sin más?, ¡¡alto insensato!!, no actives el servicio/demonio de Apache Tomcat todavía o vivirás la experiencia de ver un terrible «log» repleto de errores.

Te falta reconfigurar los ficheros solcore.properties ;  alfresco-global.properties ; server.xml y tomcat-users.xml

En el caso del server.xml deberás revisar el SSLEnlable (a true) y configurar en todos los sitios tu puerto de preferencia, en mi caso utilicé el estándar por tener un servidor virtualizado dedicado expresamente a este servicio.

Prestad atención a estas líneas:

<Connector port=»8080″ URIEncoding=»UTF-8″ protocol=»HTTP/1.1″
connectionTimeout=»20000″
redirectPort=»8443» maxHttpHeaderSize=»32768″ />

Para que el servidor redirija las peticiones al puerto seguro, en mi caso el 443.
Y os tocará descomentar las líneas adecuadas.

En el caso del fichero «tomcat-users.xml» es el que me hizo tener dolores de cabeza cuando puse en marcha SSL pues por ningún lado vi referencia al fichero de marras. Finalmente, no recuerdo bien donde demonios localicé estas líneas salvadoras, pero las encontré: «# Note : if you change the following variables, they will also need to be changed in the repo/solr configuration : # REPO_DN and REPO_CLIENT_DN are reflected in tomcat-users.xml.
# KEYSTORES_PASSWORD is reflected in keystores configuration (on both sides : repo and solr (for each core)).
# BROWSER_PASSWORD (password protecting the pkcs12 certificate) is not referenced in the configuration, so can be changed without further action.»

Pues eso, que si no queréis sufrir debéis agregar vuestro:  <user username=»CN=miservidor.midominio.local» roles=»repoclient» password=»null»/>

Me volví loco en mis primeros intentos al haber introducido OU y otros campos en el certificado, pero finalmente desistí porque no funcionaban por razones que desconozco, así que os recomiendo que solamente introduzcáis el CN en vuestro certificado con el FQDN de vuestro servidor Alfresco.

No borréis los «<user username=…>» incluidos pues como habéis visto anteriormente, el solr mantiene el certificado que viene integrado por defecto con la instalación y que caduca en 2113, creo que tenemos tiempo todavía 😉

Recientemente por la obsolescencia de los certificados con firma SHA1 he actualizado mi PKI a SHA256 y he actualizado el certificado de CA de dominio y de inmediato para que los Chrome dejarán de dar el molesto aviso actualicé todos mis servidores web a nuevos certificados con firma SHA256 y gracias a eso mirad que bonito color verde…