MyFacebookSpace

Tomcat 6 avec l'apache portable runtime

david — Fri, 02 May 2008 21:21:00 +0200

Installer Tomcat 6 est couvert dans de nombreux tutoriaux.

Dans ce post, je vais couvrir l'installation de tomcat 6 avec l'Apache Portable Runtime, ce qui permet au serveur tomcat d'utiliser des librairies natives pour gérer le SSL ou pour servir des fichiers statiques par exemple.

Une installation de ce type est très intéressante pour installer un serveur d'authentification CAS (un futur post dessus va voir le jour prochainement sur mon blog :p), car CAS ne sert que des pages dynamiques en SSL (donc le gain en performance est très significatif si CAS tourne avec l'APR)

Pré-requis : installation du jdk 1.6 (et positionnement de la fameuse variable d'environement JAVA_HOME), des outils de compilation unix (gcc, g++),des building tools unix classiques (autoconf, automake, etc..) et il faut aussi avoir les headers de la librairie OpenSSL pour pouvoir compiler une application utilisant openssl (package libssl-dev sous ubuntu 8.04)

Les étapes :

- il va falloir compiler l'APR afin d'être sur du bon fonctionnement final de tomcat 6 avec jsvc (les packages tout fait sont souvent compilés avec de mauvaises options et provoquent un démarrage du serveur tomcat 6 anormalement long, comme nous le verrons plus loin).

- Générer des certificats pour le bon fonctionnement de tomcat en mode ssl

- Configurer tomcat

- Créer un utilisateur sous lequel le processus s'exécutera ainsi que des scripts de démarrage automatiques.

Le nécessaire :

- tomcat 6.0.16 (ou supérieur)

- apr sources 1.2.12

1) Compilation de l'APR pour Tomcat 6 :

Nous allons installer toutes les librairies et placer tous les header nécessaires à la compilation d'autres outils utilisants ces librairies dans /opt/apr-tomcat-6.

Il faut tout d'abord décompresser l'archive

tar xvzf apr-1.2.12.tar.gz

- Créer le répertoire qui va contenir les librairies que nous allons compiler

sudo mkdir /opt/apr-tomcat-6

- Se placer dans le répertoire contenant ce que nous avons décompresser et lancer la configuration suivante :

./configure --prefix=/opt/apr-tomcat-6/ --with-devrandom=/dev/urandom

puis

sudo make

et enfin

sudo make instal

l'option --with-devrandom est très importante : par défaut apr utilise /dev/random, et c'est ce qui provoque un démarrage lent du serveur lorsqu'il utilise SSL : le système met du temps a générer de l'entropie avec /dev/random.

C'est pour cette raison que nous n'avons pas pu utiliser le package libapr de la distribution, mais ce n'est pas génant car la vocation de l'APR c'est d'être compilé spécialement pour l'outil dans lequel il doit être embarqué, comme expliqué sur le site officiel du projet :

As of this writing, APR is not quite ready to be installed as a system-wide shared library; it currently works best when tied directly to the application using it.

2) Installation de tomcat

Se placer dans le répertoire /opt et détarrer l'archive de tomcat 6.0.16

sudo tar xvzf apache-tomcat-6.0.16.tar.gz

- Vous devriez avoir un répertoire /opt/apache-tomcat-6.0.16

- Pour des soucis de maintenabilité de scripts pour démarrer / stopper tomcat, nous allons créer un lien symbolique /opt/tomcat qui pointera vers /opt/apache-tomcat-6.0.16

ln -s /opt/apache-tomcat-6.0.16 /opt/tomcat

- Se rendre dans le répertoire /opt/tomcat/bin

- Nous allons compiler les wrappers JNI pour tomcat utilisants la librairie APR spécialement compilée pour le serveur à l'étape précédente :

sudo tar xvzf tomcat-native.tar.gz
cd tomcat-native-1.1.12-src/jni/native

sudo ./configure --with-apr=/opt/apr-tomcat-6 --with-java-home=/usr/lib/jvm/java-6-sun --with-ssl=yes

puis

sudo make

sudo make install

Maintenant nous allons installer l'outil jsvc (aussi inclus dans la distribution de tomcat 6).

Cet outil permet de démarrer tomcat 6 en tant que démon et de pouvoir par exemple démarrer tomcat sur le port 80 et de switcher d'utilisateur une fois le processus démarré.

- Nous allons nous replacer dans /opt/tomcat/bin et executer :

sudo tar xvzf jsvc.tar.gz
cd jsvc-src/
sudo chmod u+x configure
sudo ./configure --with-java=/usr/lib/jvm/java-6-sun
sudo make

L'outil est compilé et disponible dans /opt/tomcat/bin/jsvc-src/.

Si votre tomcat est destiné à un environnement de production, vous pouvez aussi modifier le fichier /opt/tomcat/conf/web.xml pour ajouter :

        <init-param>
            <param-name>development</param-name>
            <param-value>false</param-value>
        </init-param>
       <init-param>
            <param-name>genStringAsCharArray</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>trimSpaces</param-name>
            <param-value>true</param-value>
        </init-param>

A la liste des init-param de la servlet Jasper (org.apache.jasper.servlet.JspServlet).

Il faudra dans ce cas déployer des webapps ayant précompilées les JSPs.

Mais pas de panique si tout ceci ne vous semble pas très clair car c'est détaillé ici.

3) Les certificats pour le mode SSL de tomcat :

Pour fonctionner en mode SSL, tomcat va avoir besoin de certificats.

Pour ce faire nous allons générer des certificats auto-signés par des certificats émulant ceux d'une autorité certificatrice (comme expliqué dans un précédent post sur openssl)

- Tous les certificats que nous allons créer pour tomcat vont se trouver dans un répertoire /opt/tomcat-certificats

mkdir /opt/tomcat-certificats

cd /opt/tomcat-certificats

- Générer la clée

sudo openssl genrsa -out tomcat-key.pem 1024

- il faut ensuite créer une requete de signature :

sudo openssl req -new -out tomcat-req.csr -key tomcat-key.pem

- Et signer cette requête à l'aide de nos certificats racine :

sudo openssl ca -policy policy_anything -out tomcat-cert.pem -infiles tomcat-req.csr

- Vérification du certificat :

sudo openssl verify -CAfile /opt/root-certificats/cacert.pem -purpose sslserver tomcat-cert.pem

-Mise a jour des droits sur le répertoire contenant les certificats pour l'utilisateur tomcat :

sudo chown -R tomcat:tomcat /opt/tomcat-certificats

4) Configuration du serveur tomcat :

- Editer le fichier /opt/tomcat/conf/server.xml et remplacer le connecteur par défaut sur le port 8080 par celui-ci

Et ajouter juste après le connecteur pour la connection en HTTPS :

4) Scripts de démarrages et tweaking avancé du serveur

Pour que votre serveur tomcat puisse supporter une très grande charge (300 requêtes / secondes) , vous serez sûrement amenés à augmenter le nombre maximum de "file descriptor" pouvant etre ouverts simultanément.

Pour ce faire éditez le fichier /etc/security/limits.conf pour y ajouter à la fin les 2 lignes suivantes :

tomcat soft nofile 4096

tomcat hard nofile 4096

sauvez et rebootez la machine.

Par la suite dans tout script de votre création avant de démarrer tomcat vous ajouterez

su tomcat -c "ulimit -n 4096"

Et vous ne devriez pas être embêté avec des erreurs du type "too many open file".

Mettre dans /opt/tomcat/bin un script nommé Tomcat6.sh contenant :

#Debut fichier Tomcat6.sh

# Adapt the following lines to your configuration
LD_LIBRARY_PATH=/usr/local/apr/lib
JAVA_HOME=/usr/lib/jvm/java-6-sun
CATALINA_HOME=/opt/tomcat
DAEMON_HOME=$CATALINA_HOME/bin
TOMCAT_USER=tomcat
ENDORSED_DIR=$CATALINA_HOME/common/endorsed
# for multi instances adapt those lines.
TMP_DIR=/var/tmp
PID_FILE=/var/run/jsvc.pid
CATALINA_BASE=$CATALINA_HOME

CATALINA_OPTS="-Djava.library.path=/opt/tomcat/bin/tomcat-native-1.1.12-src/jni/native/.libs/"
CLASSPATH=\
$JAVA_HOME/lib/tools.jar:\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/bootstrap.jar

#to avoid the "too many open files" error when tomcat needs more than 1024 opened file descriptors at the same time

su tomcat -c "ulimit -n 4096"

case "$1" in
start)
    #
    # Start Tomcat
    #
    $DAEMON_HOME/jsvc-src/jsvc \
    -user $TOMCAT_USER \
    -home $JAVA_HOME \
    -Dcatalina.home=$CATALINA_HOME \
    -Dcatalina.base=$CATALINA_BASE \
    -Djava.io.tmpdir=$TMP_DIR \
    -Djava.endorsed.dirs=$CATALINA_HOME/common/endorsed \
    -wait 10 \
    -pidfile $PID_FILE \
    -outfile $CATALINA_HOME/logs/catalina.out \
    -errfile '&1' \
    $CATALINA_OPTS \
    -cp $CLASSPATH \
    org.apache.catalina.startup.Bootstrap
    #
    # To get a verbose JVM
    #-verbose \
    # To get a debug of jsvc.
    #-debug \
    exit $?
    ;;

stop)
    #
    # Stop Tomcat
    #
    $DAEMON_HOME/jsvc-src/jsvc \
    -stop \
    -pidfile $PID_FILE \
    org.apache.catalina.startup.Bootstrap
    exit $?
    ;;

*)
    echo "Usage tomcat.sh start/stop"
    exit 1;;
esac

#Fin fichier Tomcat6.sh

Le rendre executable :

chmod a+x /opt/tomcat/bin/Tomcat6.sh

et enfin on donne bien à l'utilisateur tomcat les droits sur tout ce qui est contenu dans le répertoire de tomcat

sudo chown -R tomcat:tomcat /opt/tomcat

5) Bugfixe : désactiver le support d'IPV6

Normalement après l'étape 4, tout est censé fonctionner et vous devriez pouvoir démmarrer votre serveur tomcat en lançant /opt/tomcat/bin/tomcat6.sh start

Néanmoins l'activation du support d'IPV6 entraine souvent une BindException au démarrage de tomcat avec APR.

Il faut donc désactiver le support de l'IPV6 (une techno inutile depuis l'invention de la NAT ;p)

- Editer /etc/modprobe.d/aliases

remplacer

alias net-pf-10 ipv6

par

alias net-pf-10 off

Un reboot du serveur (pour la prise en compte des modifications sur le support de l'ipv6), and That's it !

votre tomcat avec APR devrait pouvoir démarrer sur les ports 80 et 443, en tant qu'utilisateur tomcat une fois lancé avec un

sudo /opt/tomcat/bin/Tomcat6.sh start

Prochaine étape : Faire tourner dessus un serveur CAS, pour disposer d'une solution efficace et performante de Single Sign On ;)

Open SSL : Générer ses certificats

david — Wed, 23 Apr 2008 23:54:00 +0200

Vouloir établir une connexion sécurisée entre un internaute et un site web lors d'un formulaire demandant par exemple des coordonnées banquaires ou un login / mdp est un besoin fréquent.

Pour ce faire, il faut chiffrer les données transmises entre le navigateur du client et le serveur web.

Afin de crypter les données, il faut procéder à un échange de certificats entre le navigateur et le serveur web. Le mécanisme est le suivant : Le serveur dispose d'un fichier appelé certificat contenant une clée privée et une clée publique. Il envoie au navigateur un certificat contenant des informations sur le nom de la société qui met en oeuvre le site, son pays de résidence et surtout une clée publique. La clée privée est gardée jalousement a l'abris sur le serveur. Le navigateur va donc présenter ce certificat à l'internaute des réception de celui-ci (et vous avez souvent une petite fenêtre qui vous demande d'accepter ou refuser ce certificat).

Si le certificat est accepté, le navigateur va crypter les informations à envoyer avec la clée publique, et cela garantira que seul le détenteur de la clée privée correspondante pourra décrypter les données. Ce mécanisme est néanmoins incomplet : si vos données sont en effet protégées entre le navigateur et le serveur, vous n'êtes pas sur de l'identité du serveur. Pour cela il existe des organismes comme Vérisign qui vous garantissent que le serveur avec lequel vous dialoguez est bien celui qu'il prétend être.

Pour ce faire ces organismes disposent de certificats servant à signer un certificat émis par la société du site web.

Les navigateurs intègrent automatiquement les certificats de ces grandes compagnies (appelées "autorités de certification") et peuvent vérifier si le certificat qui lui est envoyé par un site est approuvé par une de ces autorités de certification.

Voici la définition officielle disponible sur le site de Vérisign :

"Chaque certificat SSL est créé pour un serveur particulier dans un domaine spécifique pour une entité professionnelle vérifiée. Comme un passeport ou un permis de conduire, un certificat SSL est émis par une autorité de confiance, l’autorité de certification (Certification Authority, CA en abrégé). Lors de la transaction SSL, le navigateur demande l’authentification du serveur. Le client voit apparaître le nom de la société lorsqu’il clique sur certaines marques de confiance SSL (telles que le sceau VeriSign Secured™ Seal) ou utilise un navigateur prenant en charge la norme Extended Validation (Validation renforcée). Si l’information ne correspond pas ou si le certificat est périmé, le navigateur affiche un message d’erreur ou un avertissement"

Un certificat approuvé par une autorité de certification est appelé un certificat signé.

D'ailleurs quand le navigateur reçoit un certificat signé, l'internaute n'a pas à donner son approbation pour accepter / refuser le certificat : le navigateur lui fait confiance automatiquement.

La signature d'un certificat par une autorité de certification étant payante, il est nécessaire pour un développeur de pouvoir émuler la signature de certificat.

Pour ce faire il faut commencer par créer des certificats allant servir à signer les autres.

C'est parti :

- Je suppose que vous avez déjà installé openssl sur votre environnement unix.

- Je me base sur la distribution ubuntu 8.04.

La première chose à faire est de modifier un fichier de configuration pour indiquer que les certificats que nous allons créer vont être des certificats d'autorité certificatrice.

- Editer le fichier /etc/ssl/openssl.cnf.

Modifier dir pour pointer vers un dossier allant contenir tous vos futurs certificats CA. Par exemple :

dir = /opt/root-certificats/

- Toujours dans le même fichier, remplacer tous les

basicConstraints=CA:FALSE

par

basicConstraints=CA:TRUE

(3 occurences dans le fichier par défaut normalement).

Cet attribut sera présent dans les certificats générés et indique au navigateur qu'il sagit bien d'un certificat émanant d'une CA.

- Modifier le fichier /usr/lib/ssl/misc/CA.sh(ce fichier est un script shell vous permettant de gagner un temps précieux pour créer vos certificats CA, il lance a votre place bon nombre de commandes du jeu d'outils openssl).

CATOP=/opt/root-certificats

- Fermer le fichier ci-dessus et lancer la ldc :
/usr/lib/ssl/misc/CA.sh -newca

- Répondre aux questions en notant bien la passphrase demandée.

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Paris
Locality Name (eg, city) []:Paris
Organization Name (eg, company) [Internet Widgits Pty Ltd]:David ROBIN Certification corp
Organizational Unit Name (eg, section) []:certification dpt
Common Name (eg, YOUR name) []:CATOPID
Email Address []:votreemail@mail.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:yourpassword

- Pour certaines opérations par la suite il faut convertir le fichier .pem du certificat en .der avec la ldc suivante :

openssl x509 -in /opt/root-certificats/cacert.pem -inform PEM -out /opt/root-certificats/cacert.der -outform DER

- Ré-editer le fichier /etc/ssl/openssl.cnf

Remplacer tous les basicConstraints=CA:TRUE ou basicConstraints=CA:true par basicConstraints=CA:FALSE (4 occurences cette fois car une des entrées du fichier d'origine était déjà a true)

Ainsi tous les certificats créés par la suite n'auront pas l'attribut indiquant qu'il sagit d'un certificat émanant d'une authorité certificatrice.

That's all : vos certificats CA sont créés.

Il reste une dernière petite étape : importer votre certificats dans Firefox (ou IE).

Par défaut firefox inclus un certains de certificats émanants de véritables autorités de certification.

Il faut enrichir cette liste avec notre autorité de certification nouvellement créée.

Aller dans Préférences > Avancé > Chiffrement et cliquer sur le bouton "Afficher les certificats".

Cliquer sur l'onglet "Autorités" de la nouvelle fenêtre.

Ici il faut importer le fichier /opt/root-certificats/cacert.der (ce fichier doit être distribué sur tout vos postes clients).

Vous devriez voir votre autorité parmis celle déjà présente, comme sur le screenshot ci-dessous :

Par la suite, nous utiliserons ces certificats racines afin de signer d'autres certificats, comme dans mon post suivant sur tomcat en mode APR.