# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Encriptar y firmar documentos PDF directamente desde Alfresco

El AMP (Alfresco Module Package) Alfresco PDF Toolkit nos permite añadir una serie de funcionalidades extra al gestor documental Alfresco que nos permiten manipular y trabajar con documentos PDF. En nuestro caso las funciones que más nos han interesado han sido la de encriptar y firmar digitalmente documentos a golpe de click o regla/workflow.

Alfresco PDF Toolkit es un proyecto que se aloja en Google Code y permite ya su integración con la interfaz “Share” además de “Alfresco” a partir de la versión 1.0 del plugin y Alfresco 4.x.

Esta nueva versión incorpora las siguientes funcionalidades sobre documentos PDF:

  • Unir documentos
  • Dividir documentos
  • Dividir documentos indicando páginas específicas
  • Añadir un PDF dentro de otro en una página específica
  • Marcas de agua
  • Encriptación
  • Firma digital
  • Transformar documentos TIFF a PDF
  • Metadatos extendidos para capturar información de encriptación o firmas
  • Buscar documentos encriptados o firmados a partir de metadatos de firma

La forma de instalación es la misma que con cualquier AMP, revisad el siguiente artículo para más detalle: Instalar AMPs en Alfresco. Una vez instalado aparecerán todas las nuevas acciones en las acciones de los documentos PDF:

alfresco-pdf-toolkit

Para probar la firma digital podemos crear un certificado self-signed y almacenarlo en un keystore. Ese keystore se puede probar subiéndolo a la home del usuario que lo va a utilizar. En el caso de entornos productivos se pueden generar procedimientos automáticos para evitar que el keystore esté almacenado en la misma máquina que Alfresco. En entornos de pruebas podéis generar un certificado del siguiente modo:

# keytool -genkey -keyalg RSA -alias "Alejandro G" -keypass PASSWORD -keystore keystore.ks -dname "cn=Alejandro G, c=ES"

Ese keystore.ks lo podéis usar para la firma digital. Veréis que os la pide a la hora de firmar junto con otros valores como la pass del keystore, la pass del certificado, el Alias, etc.

No dudés en ver este vídeo presentación de todas las posibilidades que ofrece Alfresco PDF Toolkit y su funcionamiento en el Front-End Share:

Redirigir tráfico http a https en Sun Java System Web Server

Vamos a ver como forzar la redirección de tráfico HTTP a HTTPS para una instancia web de Sun Java System Web Server o si fuera necesario únicamente para una sección concreta del website. Por seguridad es muy probable que queramos evitar que a un sitio web o partes del mismo se pueda acceder sin protocolo seguro (ssl-https).

En el fichero de configuración obj.conf ó foo-obj.conf de la instancia podemos establecer estas configuraciones de redirección. Para ello utilizaremos la etiqueta Client dentro del objeto Default.

En el siguiente ejemplo forzamos el uso de https para la url (urlhost) test.rm-rf.es y para todo el website (from=”/” y from=”/*”. Lo que nos indica que el origen del tráfico tiene que ser siempre http es el atributo security=”false”, es decir, todo el tráfico que no sea https y que cumpla lo que indican los NameTrans ejecutará la redirección:

<Object name="default">
<Client match="all" security="false" urlhost="test.rm-rf.es">
NameTrans fn="redirect" from="/" url-prefix="https://test.rm-rf.es/"
NameTrans fn="redirect" from="/*" url-prefix="https://test.rm-rf.es/"
</Client>
....
....
....
</Object>

Si quisiéramos redirigir únicamente una ruta concreta en lugar de especificar ” podemos indicar la ruta:

<Object name="default">
<Client match="all" security="false" urlhost="test.rm-rf.es">
NameTrans fn="redirect" from="/prueba/" url-prefix="https://test.rm-rf.es/"
</Client>
....
....
....
</Object>

Una vez realizados los cambios reiniciamos la instancia para hacerlos efectivos:

# ./stopserv; ./startserv

En la documentación oficial encontraréis más información sobre cada una de las directivas y atributos (NameTrans, fn, urlhost, security…)

Generar un certificado SSL con genkey (Red Hat Keypair Generation)

Hoy vamos a ver una alternativa a la generación de certificados SSL con OpenSSL. Genkey (Red Hat Keypair Generation) es un comando disponible como parte del paquete crypto-utils:

# yum whatprovides */genkey
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
....
....

crypto-utils-2.4.1-24.2.el6.i686 : SSL certificate and key management utilities
Repo        : base
Matched from:
Filename    : /usr/bin/genkey

Aprovechamos entonces para instalarlo:

# yum install crypto-utils

Echando un vistazo a la ayuda podemos ver las opciones del comando:

# genkey 
Usage: genkey [options] servername
    --test   Test mode, faster seeding, overwrite existing key
    --genreq Generate a Certificate Signing Request (CSR)
    --makeca Generate a self-signed certificate for a CA
    --days   Days until expiry of self-signed certificate (default 30)
    --renew  CSR is for cert renewal, reusing existing key pair, openssl certs only
    --cacert Renewal is for a CA certificate, needed for openssl certs only
    --nss    Use the nss database for keys and certificates
    --gdb    For package maintainers, to trace into the nss utilities

¡Qué motivo podríamos tener para utilizar genkey en lugar de openssl? Corregidme si hay algún otro más, pero en principio lo que yo veo es que no tenemos que acordarnos de los comandos de openssl ya que genkey es un asistente en modo text/gráfico desde línea de comandos que nos guía con todos los pasos.

Si quisieramos generar un certificado self-signed para ssl.rm-rf.es seguiríamos estos pasos:

# genkey ssl.rm-rf.es

Comienza el asistente, que ya nos indica donde van a guardarse los ficheros resultantes (llaves privadas, certificados, certificate requests, CA requests, etc.)

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 1

Indicamos el tamaño de la llave, a mayor tamaño en bits, mayor seguridad, también costará más tiempo generarla:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 2

Esperamos a la generación de los bits aleatorios:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 3

Y la generación de datos aleatorios. Se recomienda mover el ratón o escribir en la consola del servidor/máquina para acelerar el proceso:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 4

Si quisiéramos enviar una petición de CSR a una entidad certificadora autoritativa (CA) este sería el momento:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 5

Para mayor seguridad podemos encriptar la llave privada del certificado. La frase de paso (passphrase) que indiquemos tendrá que ser introducida cada vez que arranquemos el servicio web seguro.

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 6

Por último introducimos los datos de nuestro certificado:

Generar un certificado SSL con genkey (Red Hat Keypair Generation) 7

Una vez aceptado podremos ver en la línea de comandos la ejecución del proceso por genkey:

/usr/bin/keyutil -c makecert -g 1024 -s "CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES" -v 1 -a -z /etc/pki/tls/.rand.2492 -o /etc/pki/tls/certs/ssl.rm-rf.es.crt -k /etc/pki/tls/private/ssl.rm-rf.es.key
cmdstr: makecert

cmd_CreateNewCert
command:  makecert
keysize = 1024 bits
subject = CN=ssl.rm-rf.es, OU=IT, O=Rm-RF, L=Zaragoza, ST=Zaragoza, C=ES
valid for 1 months
random seed from /etc/pki/tls/.rand.2492
output will be written to /etc/pki/tls/certs/ssl.rm-rf.es.crt
output key written to /etc/pki/tls/private/ssl.rm-rf.es.key

Generating key. This may take a few moments...

Made a key
Opened tmprequest for writing
(null) Copying the cert pointer
Created a certificate
Wrote 882 bytes of encoded data to /etc/pki/tls/private/ssl.rm-rf.es.key 
Wrote the key to:
/etc/pki/tls/private/ssl.rm-rf.es.key

Y nuestra private key y certificado ya están disponibles para su uso.

Alfresco: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed

Recientemente (el 16 de agosto de 2012) caducó el certificado SSL que Alfresco Enterprise 4.x y Alfresco Community 4.0.x utiliza para la intercomunicación con Solr. Esto provoca el fallo en ciertas funcionalidades y la visualización continua en el log de Tomcat (catalina.out) del siguiente error:

Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed
    at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:289)
    at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:263)
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:173)
    at sun.security.validator.Validator.validate(Validator.java:218)
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)

Para generar un nuevo certificado podemos hacerlo de forma sencilla descargando el script generate_keystores.sh (Unix) desde el repositorio SVN de Alfresco. Una vez descargado, hay que asegurarse de modificar la variable que indica la ruta de instalación de alfresco:

ALFRESCO_HOME=/opt/alfresco-4.1

Una vez modificada la variable ejecutamos el script, esperamos un rato y se habrá generado un nuevo certificado con validez de un año:

# /root/generate_keystores.sh
Using CATALINA_BASE:   /web/alfresco/tomcat
Using CATALINA_HOME:   /web/alfresco/tomcat
Using CATALINA_TMPDIR: /web/alfresco/tomcat/temp
Using JRE_HOME:        /web/alfresco/java
Using CLASSPATH:       /web/alfresco/tomcat/bin/bootstrap.jar

/web/alfresco/tomcat/scripts/ctl.sh : tomcat stopped
/web/alfresco/postgresql/scripts/ctl.sh : postgresql stopped
Certificate stored in file 
Certificate stored in file 
Certificate was added to keystore
Certificate was added to keystore
Certificate was added to keystore

Certificate update complete
Please ensure that you set dir.keystore=/web/alfresco/alf_data/keystore in alfresco-global.properties

Finalmente revisamos que la variable “dir.keystore” está bien declarada en alfresco-global.properties y reiniciamos Alfresco. Automáticamente haremos uso del nuevo certificado:

Alfresco SSL Certificate

Consultar y exportar certificados SSL en Sun Web Server (certutil y pkcs12)

Sun Web Server (en este artículo trabajamos sobre la versión 6.1) almacena los certificados y llaves privadas en ficheros .db (cert8.db y key3.db). Vamos a hacer uso de los comandos certutil y pkcs12 para poder hacer operaciones de listado y exportación de certificados (con o sin private key).

Para listar los certificados que tiene instalados el servidor web debemos usar el comando certutil, que se encuentra en la ruta /bin/https/admin/bin/. Los ficheros .db que comentaba antes se encuentran en la carpeta “alias” por defecto. Podéis copiarlos a una ruta temporal para trabajar con ellos en lugar de directamente en la ruta de producción. Una vez realizado, nos colocamos en esa carpeta y ejecutamos el siguiente comando:

$ certutil -L -d .

    CERTIFICADO-WEB                                                CTu,u,u

Como podéis comprobar, en este servidor web tenemos instalado el certificado CERTIFICADO-WEB. Si queremos exportarlo en formato ASCII sin su private key podemos usar el mismo comando pero especificado el certificado y el parámetro -a (ASCII). En formato binario usamos el parámetro -d (DER):

$ certutil -L -d . -n "CERTIFICADO-WEB" -a
    -----BEGIN CERTIFICATE-----
    MIICTjCCAbAxasdhljkads8akjasdolasdYjEfMB0GA1UEChMWU3Vu
    ...
    ...
    asd3asd23sadasdadsasdasd
    -----END CERTIFICATE-----
$ certutil -L -d . -n "CERTIFICADO-WEB" -d

Finalmente, si lo queremos exportar en formato legible:

$ certutil -L -d . -n "CERTIFICADO-WEB"
     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number: ...
             Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
             Issuer:
...
...

En caso de necesitar exportar también la private key del certificado, hacemos uso del comando pkcs12. En este caso necesitaremos la password del “NSS Certificate DB” para poder acceder a los certificados del servidor así como especificar una nueva para el fichero resultante PKCS12. Seguimos ubicados en la carpeta donde están los ficheros *.db. Especificamos el fichero de salida (certificado.p12, y el nombre del certificado.

$ pk12util -o certificado.p12 -n 'CERTIFICADO-WEB' -d .
Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
Re-enter password:
pk12util: PKCS12 EXPORT SUCCESSFUL

SSLCertificateFile: file certificado.crt does not exist or empty

En caso de recibir este error tras realizar una instalación de un certificado SSL en un servidor web Apache debemos revisar (en RHEL, CentOS, Scientific Linux, Fedora…) el estado de SElinux. Si está activado, probablemente sea el origen del problema:

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

En el log de auditoría veremos los siguientes errores:

# tail -200 /var/log/audit/audit.log  | grep crt
type=AVC msg=audit(1330769968.611:22): avc:  denied  { getattr } for  pid=1657 comm="httpd" path="/etc/ssl/cert.crt" dev=dm-0 ino=22027 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1330770107.699:23): avc:  denied  { getattr } for  pid=1676 comm="httpd" path="/etc/ssl/cert.crt" dev=dm-0 ino=22034 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1330770206.289:24): avc:  denied  { getattr } for  pid=1697 comm="httpd" path="/etc/ssl/cert.crt" dev=dm-0 ino=22034 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

Se presupone además que hemos revisado que el path al certificado es correcto y no está vacío. Para solucionar el problema debemos aplicar (etiquetar) los atributos de SElinux correctos a los ficheros del certificado (certificado, private key, CA). Una forma sencilla es “copiar” estos atributos de un fichero de configuración Apache, que ya los tendrá asignados:

# chcon --reference=/etc/httpd/conf.d/ssl.conf cert.*

O aplicándolo especificando todos los atributos:

# chcon -u system_u -r object_r -t httpd_config_t cert.*

Si listamos ya tenemos etiquetados los ficheros y podemos reiniciar Apache sin recibir el error:

# ls -Z
-rw-r--r--. apache apache system_u:object_r:httpd_config_t:s0 cert.crt
-rw-r--r--. apache apache system_u:object_r:httpd_config_t:s0 cert.csr
-rw-r--r--. apache apache system_u:object_r:httpd_config_t:s0 cert.key

ReverseProxy en Apache con SSL

Hoy vamos a ver los pasos para activar soporte SSL en un proxy reverse de Apache. Algunos de los pasos ya los he comentado en otros artículos así que los citaré directamente.

Lo primero es Configurar Apache como Reverse Proxy (Proxy Inverso), pinchad en el enlace antes de seguir leyendo. Una vez realizado tenemos que tener un certificado SSL, podemos contratarlo en una entidad certificadora o generarlo nosotros mismos. Para ello revisar este enlace: generar un certificado SSL propio con openssl.

Ahora que tenemos Apache listo para ser usado como reverse proxy sólo nos queda realizar los pasos finales. Lo primero es habilitar soporte para mod_ssl instalando el módulo de Apache. Podemos hacer vía yum o apt, si Apache ha sido compilado a mano habrá que recompilar.

# yum install mod_ssl

Tenemos que modificar la configuración de mod_proxy para permitir el acceso vía SSL, para ello buscamos la configuración del módulo en el fichero de configuración de Apache httpd.conf. Podríamos configurar estas directivas únicamente en el Virtualhost que queramos si no se desea hacer para todo el servidor. Básicamente activamos SSLProxyEngine (lo hacemos en el virtualhost) y restringimos el acceso al proxy a la red 10.0.0.0/24 a nivel general.

<IfModule mod_proxy.c>
...
...
<Proxy *>
Order deny,allow
Deny from all
Allow from 10.0.0.0/24
</Proxy>
....
....
</IfModule>

Y el Virtualhost, veréis que activamos los Engine de SSL y de SSLProxy, especificamos las rutas al certificado SSL y su PrivateKey y que finalmente especificamos las directivas de proxy, en este caso al acceder a https://proxy.com/google nos llevará a https://google.com. He omitido configuraciones de log y demás en el vhost para hacerlo más sencillo:

<VirtualHost 0.0.0.0:443>
    ServerName proxy.com
    SSLEngine on
    SSLProxyEngine on
    SSLCertificateFile /etc/ssl/cert.crt
    SSLCertificateKeyFile /etc/ssl/cert.key
    ProxyPass /google/ https://google.es
    ProxyPassReverse /google/ https://google.es
</VirtualHost>

Habilitar certificados de cliente para un website en IIS 6.0

Habilitar los certificados de cliente a nivel de website permite que aquel que conecte al sitio web necesite la utilización de un certificado seguro para poder acceder. De este modo podremos proteger los accesos al sitio web y sus recursos frente a accesos no deseados y permitir especificamente a un grupo concreto el acceso.

En este caso los vamos a activar a nivel de website, de modo que accederemos a la consola de gestión de IIS (Internet Information Services Manager) y desplegaremos el servidor local, después Web Sites y pincharemos con el botón derecho en el website a configurar seleccionando Properties. Una vez dentro accederemos a la pestaña “Directory Security” y pincharemos en “Edit” dentro de la sección de comunicaciones seguras (Secure Communications).

IIS certificados cliente

Una vez dentro encontraremos las siguientes opciones. Lo primero que debemos activar es el requerimiento de un canal seguro SSL (Require Secure Channel SSL). De este modo forzamos al usuario a conectar vía HTTPS. Posteriormente podemos configurar si habilitamos los certificados de cliente o si obligamos a usarlo. La última opción forzará al usuario a utilizarlo mientras que la segunda lo permitirá. Finalmente podemos habilitar una lista de certificados de confianza (Enable Certificate Trust List) a la cual podremos añadir los certificados a utilizar para la comunicación con el cliente, certificados CA intermedios, etc.

IIS certificados cliente

Finalmente reiniciamos el website y ya debería estar habilitada la funcionalidad de certificados de cliente.

Ver el perfil de Alejandro García García en LinkedIn