Agregando a un Keystore de Java un certificado X.509 junto con su clave privada

La tarea en cuestión no es trivial. Dado que en la mayoría de los casos podremos obtener sin problemas la clave privada del servidor y el certificado en el formato X.509, podemos convertir dichos datos a un certificado conjunto PKCS12 para, de ahí, migrarlo a un Keystore.

La tarea consiste en dos pasos:

  1. Convertir el certificado X.509 y su clave privada en un fichero PKCS12
    openssl pkcs12 -export -in [fichero CRT] -inkey [fichero KEY] \
                   -out [fichero PKCS12] -name [alias] \
                   -CAfile [fichero CA] -caname root
    
    
  2. Convertir el fichero PKCS12 a un Java Keystore
    keytool -importkeystore \
            -deststorepass [contraseña keystore] -destkeypass [contraseña KEY] -destkeystore [fichero keystore] \
            -srckeystore [fichero PKCS12] -srcstoretype PKCS12 -srcstorepass [contraseña PKCS12] \
            -alias [alias]

 

NTP service: cap_set_proc() failed to drop root privileges

On certain kernel configurations, happening specially if you are working on virtual environments, you may find problems while trying to start the NTP service. Specifically, the syslog may display the error…

cap_set_proc() failed to drop root privileges: Operation not permitted

This happens when the NTP service, started as root, cannot downgrade its status to NTP user. This is due to a wrong configuration of the Linux Capabilities library (libcap) and the only real solution would be to:

a. Recompile the kernel and configure properly the related flag.
b. Try to load the capabilities module, if available (modprobe capabilities)

In the worst case there is a workaround, which is to modify the NTP init.d script and completely remove the *-u* option, so that the NTP service runs as root. Is not the best approach, but it may save you if you are in a hurry.

A worthwhile WordPress setup guide

It’s the same story over and over. I keep working in multiple projects, each and everyone with it’s own nature, technological stack, language and whatever variable attribute that you may imagine. So it’s hard for me to keep track of good practices that I should follow on certain situations.

Specifically I am thinking right now on WordPress projects: which are the best practices that I should follow? Which are some worthy plugins? Anything that I should manually add to my configuration to improve the performance? Of course this also may apply to other kind of projects but…

That’s the reason why I decided to create this post, not only to share and improve it (from your comments and my new experiences) but also to use it as a manual for me. Too many things on mind 🙂

 

Keep the WordPress core and the plugins (specially) updated
Starting from WordPress 3.7, the core includes a feature that can automatically update the installation for you. Although not the best option for complex and/or highly customized deployments, it may worth a try in case you want to forget about doing it manually. This automatic updates may only apply in case of minor releases. It also may apply to plugins. In any case the automatic behavior may be altered. Take a look to the WordPress Codex for more information.

In case you want to do it manually (my preferred way) please follow WordPress and plugin releases (RSS, mail subscriptions, mirror signals, …) and make sure to apply them reguarly. This process will also help you to avoid having to make big updates after a while (with the associated headaches).

Just one more thing: test always in a development environment first before updating. This is important in case of complex deployments, involving multiple plugins.

Monitor the blog availability
(sorry, this needs to be developed a bit more)

Disable post revisions and remove the existing ones
(sorry, this needs to be developed a bit more)
define(‘WP_POST_REVISIONS’, false);

Disable trash can
(sorry, this needs to be developed a bit more)
define(‘EMPYY_TRASH_DAYS’, 14);

Enable data compression on requests (GZIP)
(sorry, this needs to be developed a bit more)
/wp-admin/options.php
gzipcompression = 1

Test the performance of you page
(sorry, this needs to be developed a bit more)
Web Page Test
For plugins: P3

Remove admin user and alter admin access
(sorry, this needs to be developed a bit more)

Block or control access to certain resources
I’m talking about resources like xmlrpc.php DoD attack
(sorry, this needs to be developed a bit more)

 

Montando un entorno para ejecutar aplicaciones web Java, bajo Tomcat 7 en una plataforma Ubuntu

*Instalación de Java SDK

Como primer paso, debemos tener instalado Java en nuestro servidor. Podríamos optar por uno de los diferentes “sabores” que nos ofrece nuestra distribución Ubuntu por defecto (como OpenJDK), pero por requerimientos optaremos por la versión oficial de Oracle.

Afortunadamente la gente de “WebUpd8” nos lo pone fácil, ofreciéndonos un repositorio de paquetes con el que instalar las diferentes versiones del productos en las diferentes versiones del sistema operativo.

Añadiremos el respositorio a nuestra máquina, así como la clave pública del respositorio:

sudo bash
su
echo “deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main” > /etc/apt/sources.list.d/webupd8team-java.list
echo “deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main” > /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv –keyserver keyserver.ubuntu.com –recv-keys EEA14886

Finalmente, procedemos con la instalación. En la misma línea de comandos:

apt-get update
apt-get install oracle-java7-installer

Comprobamos que se ha instalado correctamente, ejecutando:

java -version
java version “1.7.0_80”
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

*Instalación de Apache Tomcat 7
Aunque no es requerido, se recomienda la creación de un usuario de servicio dedicado a la ejecución del servidor Tomcat, en lugar de su ejecución con un usuario con privilegios. Esto además nos implicará que el puerto del Tomcat no podrá ser uno de los reservados (el 80, por ejemplo), pero en nuestro caso ya nos va bien.

Nótese además que el usuario será únicamente usado para la ejecución del servicio y no podrá ser usado para autenticarse en el servidor.

En la línea de comando anterior:
adduser –system –shell /bin/bash –gecos ‘Tomcat Java Servlet and JSP engine’ –group –disabled-password –home /home/tomcat tomcat

Ahora y podemos proceder a descargarnos el servidor Apache Tomcat e instalarlo en las rutas recomendadas:

cd /tmp
wget http://ftp.cixug.es/apache/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz

Probamos y revistamos los ficheros que se incluyen en el paquete descargado:
tar tvfz apache-tomcat-7.0.61.tar.gz

Descomprimimos el paquete e instalamos en una ruta estándar:
tar xvfz apache-tomcat-7.0.61.tar.gz
mkdir /usr/share/tomcat-repo
mv apache-tomcat-7.0.61.tar.gz /usr/share/tomcat-repo

De cara a tener múltiples versiones del servidor sin necesidad de modificar rutas en los ficheros de configuración, procederemos a crear un enlace simbólico hacia la última (y única de momento) versión del servidor:
ln -s /usr/share/tomcat-repo /usr/share/tomcat

Finalmente estableceremos el usuario tomcat como propietarios de los ficheros del servidor:
chown -R tomcat:tomcat /usr/share/tomcat-repo
chmod +x /usr/share/tomcat/bin/*.sh

Limpiamos:
rm /tmp/apache-tomcat-7.0.61.tar.gz

Cerramos la línea de comandos con la que hemos estado trabajando desde el inicio de este artículo.

*Arrancando por primera vez
Comenzamos arrancando el servidor, que por defecto se ejecutará en el puerto 8080:
sudo /bin/su – tomcat -c /usr/share/tomcat/bin/startup.sh

Comprobamos que funcione y lo paramos:
sudo /bin/su – tomcat -c /usr/share/tomcat/bin/shutdown.sh

*Modificando configuraciones

**Cambio de la localización de los logs
Procedemos a mover los logs a /var/log/tomcat:
sudo mkdir -p /var/log/tomcat
sudo chown -R tomcat:tomcat /var/log/tomcat

Editamos el fichero conf/logging.properties, agregando en todas las propiedades que indiquen localización de los ficheros (*.directory) el valor “/var/log/tomcat”.

Eliminaremos la salida de consola de los handlers del fichero, pasando de…

.handlers = 1catalina.org.apache.juli.FileHandler java.util.logging.ConsoleHandler

…a…
.handlers = 1catalina.org.apache.juli.FileHandler

Esto desactiva que se vuelque todo el contenido de consola al fichero “catalina.out”, que irá aumentando de tamaño, sin rotar ni reiniciarse. De esta forma, dichos datos sólo quedarán añadidos en los ficheros de logs marcados con fecha.

Por otra parte, tendremos que configurar nuestra instancia de servidor local, en el fichero “conf/server.xml”, indicando que el fichero de logs asociado…

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”logs”
prefix=”localhost_access_log.” suffix=”.txt”
pattern=”%h %l %u %t &quot;%r&quot; %s %b” />

…está en una nueva ruta…

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”/var/log/tomcat”
prefix=”localhost_access_log.” suffix=”.txt”
pattern=”%h %l %u %t &quot;%r&quot; %s %b” />

Finalmente, movemos todo el contenido del directorio de logs a la nueva ruta /var/log/tomcat.

* Configurar un servicio para Tomcat
Aunque ya hemos visto los comandos para iniciar y parar el servidor, lo ideal sería poder usar las herramientas que habitualmente pone a nuestra disposición el sistema (upstart).

Usaremos el siguiente script, como base:
https://gist.github.com/okiwan/f9253b11b30d09ed0180

Naturalmente debemos adaptar las variables iniciales a nuestra configuración, pero una vez hecho podremos lanzar y parar la instancia con el script.

A partir de ese momento, sólo nos quedará agregarlo para que arranque al inicio:
update-rc.d tomcat defaults 97 03

Los números indicados, el número de secuencia y el nivel de kernel son estándar y quizás deban ser reconfigurados para el sistema. Más información en:

http://manpages.ubuntu.com/manpages/hardy/man8/update-rc.d.8.html

* Habilitar un usuario para la gestión de aplicaciones (vía web)
Para habilitar un usuario que nos permita agregar nuevas aplicaciones, debemos actualizar el fichero “tomcat-users.xml”. Podemos agregar una nueva entrada copiando de los ejemplos incluidos en los comentarios inciales.

Sólo tener en cuenta que:

– El usuario tenga una contraseña asignada segura
– El usuario tenga, además del rol tomcat, el rol manager-gui

*Notas
Idealmente el directorio de configuración (conf) debería moverse al directorio de sistema /etc.