Le serveur Java EE GlassFish

Apache / GlassFish et HTTP/SSL

Date de publication : 22/02/2012.

Par Jérôme Lafosse

 

Cet article est un extrait gratuit de l'ouvrage  fr Développements n-tiers avec Java EE, Chapitre 2 : le serveur Java EE GlassFish.
1 commentaire Donner une note à l'article (5)

Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites      



0-A. Supprimer le serveur GlassFish
0-B. Suivre les fichiers journaux
1. Coupler GlassFish et le serveur Web Apache
1-A. Utilisation d'un serveur Web
1-B. Un connecteur pour l'intégration du serveur Web
1-B-1. Fonctionnement
1-B-2. Installation du module mod_jk
1-B-3. Configurer le module mod_jk pour Apache
1-B-4. Créer le fichier de configuration du travailleur
1-B-5. Configurer le module mod_jk pour GlassFish
1-B-6. Créer un hôte virtuel GlassFish
1-B-7. Optimisation du déploiement des applications
2. Apache / GlassFish et HTTPS/SSL
2-A. Activer le protocole HTTPS dans GlassFish
2-B. Activer le protocole HTTPS pour le couple Apache/GlassFish


0-A. Supprimer le serveur GlassFish

GlassFish est livré avec un script de désinstallation très simple à utiliser. Pour réaliser une désinstallation complète, il est nécessaire de stopper le serveur, tous les domaines associés et de réaliser les étapes suivantes :

  • Sous Linux, Unix et Mac OS X : se rendre dans le répertoire glassfishv3 et lancer le script uninstall.sh.
  • Sous Windows l'exécutable glassfishv3\uninstall.exe permet de réaliser la même opération.

0-B. Suivre les fichiers journaux

Il est souvent très utile de suivre les traces lors d'un démarrage ou un arrêt du serveur. De même, les fichiers journaux permettent de renseigner les administrateurs sur les problèmes de connexion au SGBD, les exceptions, les traces de programmation ou autres. Les fichiers journaux de GlassFIsh sont relatifs à chaque domaine et stockés dans le répertoire : /usr/local/glassfishv3/glassfish/domains/domain1/logs.

Par défaut, deux fichiers sont utilisés pour les logs :

  • Le fichier de traces du serveur : server.log.
  • Le fichier de traces de la machine virtuelle Java : jvm.log.
Une bonne habitude consiste à ouvrir en permanence, avec la commande suivante, une console qui trace en temps réel le fichier de logs du serveur : 

		$ tail -f /usr/local/glassfishv3/glassfish/domains/domain1/logs/server.log&
GlassFish permet également d'afficher en temps réel les traces du serveur dans la console de lancement en utilisant le mode verbeux : 

		  $ asadmin start-domain --verbose
Lancement du serveur GlassFish en mode verbeux

1. Coupler GlassFish et le serveur Web Apache


1-A. Utilisation d'un serveur Web

Si nous ne souhaitons pas installer un serveur en production, cette partie est alors facultative. En effet, elle ne permet pas d'améliorer l'environnement de développement mais elle est recommandée pour un déploiement sur un serveur en production. Dans une architecture en production, il est recommandé d'utiliser un serveur Web en frontal d'un serveur d'applications. Ces recommandations sont également appliquées dans le cas de l'utilisation d'un serveur Java EE comme GlassFish.

L'utilisation d'un serveur Web en frontal est nécessaire pour des raisons de performance, de sécurité et de configurabilité.

  • Performance : le serveur Web permet de délivrer les contenus statiques comme les pages HTML, le code JavaScript, les images du site, les feuilles de style ou autres. GlassFish sera utilisé alors pour servir uniquement les contenus dynamiques en Java et le serveur Web proposera son système de cache statique évolué.
  • Sécurité : le serveur Web est utilisé en frontal et isole le serveur Java EE d'Internet. Le conteneur est alors au plus près des données et il est moins sollicité pour des services simples.
  • Configurabilité : un serveur Web comme Apache dispose d'une plus grande palette de services du point de vue HTTP que GlassFish (.htaccess, gestion des droits, urlrewriting).
Grizzly est le nom de l'écouteur HTTP écrit sous la forme d'entrées/sorties multiplexées, aux performances semblables à Apache httpd. Grizzly permet de gérer Comet pour les connexions HTTP longue durée utilisées avec le langage Ajax.

Coupler le serveur Web Apache et le serveur Java EE GlassFish
Pour mettre en oeuvre ce mécanisme de dialogue optimisé entre le serveur Web Apache et le serveur Java EE GlassFish, nous allons déployer l'archive gdawj.war contenant le site officiel consacré à mes ouvrages. Pour cela, nous allons déployer dans un premier temps notre application gdawj.war en ligne de commande ou à l'aide de l'interface Web d'administration, en supposant que l'archive est présente à cette adresse /home/lafosse/gdawj.war : 
$ asadmin deploy /home/lafosse/gdawj.war
L'application est alors disponible à cette adresse : http://localhost:8080/gdawj :

Déploiement de l'application gdawj
L'application est fonctionnelle et correctement déployée, mais nous souhaitons déployer ce projet pour le domaine et l'hôte virtuel http://www.jwadg.com afin de bénéficier d'un déploiement optimisé et professionnel.


1-B. Un connecteur pour l'intégration du serveur Web

L'intégration d'un serveur GlassFish avec un serveur Web se fait au travers d'un connecteur, configuré au sein de GlassFish, et d'une extension ajoutée au serveur Web. Un connecteur GlassFish est une classe Java supportant un protocole réseau spécifique et propriétaire. La librairie d'extension du serveur Web est chargée dynamiquement par celui-ci lors de son démarrage et permet un dialogue entre les deux serveurs.

Le connecteur actuel de référence est nommé JK et utilise le protocole AJP (Apache Jserv Protocol) dans sa version 1.3 (AJP13). Ce connecteur est plus performant mais il offre également le support de plusieurs systèmes d'exploitation, de plusieurs serveurs Web (Apache, IIS, Lotus Domini) et du protocole HTTPS. Ce connecteur est aujourd'hui la référence pour le couplage d'un serveur d'applications Java EE avec un serveur Web.


1-B-1. Fonctionnement

Le connecteur JK utilise donc le protocole AJP13 et nécessite l'installation du module mod_jk pour fonctionner avec Apache. Le connecteur JK permet ainsi d'utiliser le serveur Web en frontal et de déléguer certaines tâches au serveur GlassFish. Les requêtes des clients sont envoyées au serveur Web Apache qui retourne alors directement les contenus statiques comme : les images, le JavaScript, les pages HTML ou autres. Pour les requêtes au contenu dynamique, le module mod_jk du serveur Web est alors sollicité et délègue certaines tâches au serveur d'applications GlassFish.

La configuration de GlassFish avec un serveur Web utilise la notion de worker ou travailleur. Un travailleur est lié à une instance de serveur GlassFish. Un travailleur est caractérisé par un nom d'hôte ou une adresse IP et un numéro de port (comme une socket/prise). Le travailleur AJP13 représente une instance de GlassFish. Le module mod_jk agit alors comme un routeur de requêtes vers le serveur GlassFish.


1-B-2. Installation du module mod_jk

L'extension d'Apache supportant le connecteur JK est le module mod_jk. Ce module est livré sous forme de binaires (ou code source).

info Pour activer le mod_jk avec la version v3 il faut une release au moins supérieure à b53. En effet, l'attribut jk-enabled doit être activé et n'est supporté qu'à partir de cette version.
Les étapes suivantes sont utilisées pour l'installation du module mod_jk :

  • Installation du serveur Web Apache 2 au besoin : 
$ apt-get install apache2
  • Installation du module ainsi que ses dépendances : 
apt-get install libapache2-mod-jk
Une fois l'installation réalisée, ce module est présent dans le répertoire /etc/apache2/mods-available/jk.load.

  • Activation du module mod_jk en utilisant la commande suivante : 
$ a2enmod jk

1-B-3. Configurer le module mod_jk pour Apache

Il nous reste à configurer le fichier de gestion d'Apache pour que ce dernier charge dynamiquement, lors de son démarrage, le module mod_jk. Pour cela, il est nécessaire d'éditer selon la version d'Apache le fichier apache2.conf et d'ajouter les lignes suivantes en fin de fichier : 
#configuration du couplage Apache GlassFish
#définition du worker ou travailleur
JkWorkersFile /etc/apache2/workers.properties
#définition du fichier de log pour le module
JkLogFile /var/log/apache2/mod_jk.log
#définition du fichier de mémoire partagée pour le module
JkShmFile /var/log/apache2/mod_jk.shm
#mise en place du niveau de log
JkLogLevel info
#expression du format des logs
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
#options du module pour SSL et la clé
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
#précision du format des requêtes pour les traces du module
JkRequestLogFormat "%w %V %T"
La directive JkWorkersFile permet de spécifier l'emplacement du fichier de configuration du module. La directive JkLogFile précise l'emplacement d'un fichier journal réservé au module et la directive JkLogLevel indique le type des messages enregistrés dans ce fichier.

Une fois la configuration terminée, nous pouvons relancer le serveur Web Apache avec la commande suivante : 
$ /etc/init.d/apache2 restart
Redémarrage du serveur Web après configuration du module mod_jk
Nous pouvons remarquer que le serveur ne veut pas redémarrer, ce qui est tout à fait normal car le module mod_jk est correctement installé et paramétré, mais le worker ou travailleur n'est pas encore configuré.


1-B-4. Créer le fichier de configuration du travailleur

Une fois le fichier de configuration d'Apache modifié, il faut ensuite créer le fichier de configuration du travailleur indiqué par la directive JkWorkersFile dans le fichier d'Apache (apache2.conf). Ce fichier permet de gérer la communication entre le serveur Web et le serveur GlassFish. Le fichier utilisé nommé workers.properties porte l'extension .properties, format très utilisé avec les technologies Java. Ces fichiers sont composés d'un ensemble de paires clé/valeur. La syntaxe pour le fichier workers.properties est la suivante :

worker.<nom_du_travailleur>.<directive>=<valeur> 
Code : /etc/apache2/worker.properties
#liste des travailleurs (il serait possible de placer
#plusieurs travailleurs séparés par des virgules)
worker.list=worker1
#protocole de worker1
worker.worker1.type=ajp13
#nom d'hôte pour worker1
worker.worker1.host=localhost
#port du connecteur JK pour worker1
worker.worker1.port=8009
#le facteur de charge
worker.worker1.lbfactor=50
#nombre de connexions AJP maintenues dans le cache
worker.worker1.cachesize=10
#temps pendant lequel la connexion est maintenue dans le cache
worker.worker1.cache_timeout=600
#ne pas couper les connexions inactives
worker.worker1.socket_keepalive=1
#temps d'expiration lors de la communication entre Apache et GlassFish
worker.worker1.socket_timeout=30
Ce fichier est créé dans le répertoire local d'Apache à savoir : /etc/apache/workers.properties conformément à la directive JkWorkersFile. Les paramètres de configuration du fichier workers.properties sont, entre autres :

  • worker.list : spécifie une liste de travailleurs séparés par des virgules.
  • type : spécifie le type de travailleur.
  • host : précise le nom d'hôte ou l'adresse IP du serveur GlassFish à contacter pour le travail.
  • port : indique le numéro de port du connecteur JK.
  • retries : positionne le nombre de tentatives de connexion vers GlassFish en cas de non-réponse de ce dernier (3 par défaut).
  • lbfactor : gère le facteur de charge d'un travailleur dans le cas où la répartition de la charge est mise en oeuvre par mod_jk. Cette valeur permet de préciser quel pourcentage de requêtes l'instance GlassFish sera amenée à traiter (défaut 1).
  • cachesize : précise le nombre de connexions AJP maintenues en cache.
  • cache_timeout : spécifie combien de temps une connexion doit être maintenue dans le cache avant d'être fermée par mod_jk, afin de réduire le nombre de processeurs de requêtes actifs sur le serveur GlassFish (défaut 0).
  • socket_keepalive : évite que le firewall coupe les connexions inactives (défaut 0).
  • recycle_timeout : indique le nombre de secondes au-delà duquel le serveur coupe une connexion AJP en cas d'inactivité (défaut 0, bonne moyenne 300).
  • socket_timeout : indique le temps d'expiration de la communication entre Apache et GlassFish. Si le serveur GlassFish ne répond pas dans le délai indiqué, mod_jk génère une erreur et recommence.
La configuration du module mod_jk permettant le dialogue entre le serveur Web Apache et le serveur Java EE GlassFish est maintenant terminée. Il ne reste désormais plus qu'à ajouter un nouvel hôte virtuel correspondant au nouveau site à héberger sur notre machine. Pour ajouter un nouvel hôte virtuel pour Apache, nous allons créer un nouveau fichier nommé jwadg (l'inverse de gdawj pour l'exemple) et ajouter le code suivant, permettant de définir l'URL www.jwadg.com et les fichiers à gérer dans ce cas : 
<VirtualHost *:80>
ServerName www.jwadg.com
ServerAlias jwadg.com
ServerAdmin info@gdawj.com
DocumentRoot /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/
CustomLog /var/log/apache2/jwadg-access_log combined
Alias /css /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/css
JkUnMount /css/* worker1
Alias /images /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/images
JkUnMount /images/* worker1
<Location "/*">
JkMount worker1
</Location>
</VirtualHost>
La configuration de l'hôte virtuel permet de gérer le nom de domaine www.jwadg.com et de fournir, pour cela, l'application précisée par la directive DocumentRoot. Les logs Apache pour cette application sont précisés par la directive CustomLog. La directive Alias permet de réaliser un alias de nom sur les répertoires statiques que sont /css et /images. La directive JkUnMount permet de préciser que le travailleur worker1 n'est pas utilisé pour les alias /css et /images et qu'Apache est suffisant pour renvoyer tous ces contenus statiques.

Enfin, la directive JkMount, présente dans la balise <Location/>, permet de préciser que pour toutes les autres demandes (hors JkUnMount), le travailleur worker1 devra pouvoir les satisfaire, c'est-à-dire pour les fichiers JavaServer Pages, Servlets ou encore JavaServer Faces.

La directive JkMount est très importante car c'est elle qui permet au serveur Apache d'accéder aux applications GlassFish. Elle permet en effet de spécifier un travailleur pour l'accès au contexte. Il y aura donc une redirection de requêtes utilisateur à destination du travailleur.

La directive JkUnMount permet de réaliser l'inverse et donc de ne pas rediriger les requêtes utilisateur à destination de ressources particulières. 
JkUnMount
/usr/local/glassfishv3/glassfish/domains/domain1/application/monapplication/
mescss/*.css
D'autres directives d'Apache sont utilisables avec le mod_jk. La directive JkAutoAlias permet de réaliser un alias du répertoire de GlassFish sur le répertoire de données Apache, JkLogStampFormat permet de gérer le format de la date dans le fichier journal du module, JkExtractSSL permet de transmettre les informations SSL vers le serveur GlassFish (état on par défaut).

La configuration de l'hôte virtuel étant terminée nous pouvons l'activer et recharger le serveur Web Apache : 
$ a2ensite jwadg
$ /etc/init.d/apache2 reload
Le connecteur Apache GlassFish est activé, l'hôte virtuel également, il ne reste plus qu'à créer le faux nom de domaine www.jwadg.com pour simuler un domaine acheté. Pour cela, sous Windows, il est possible d'éditer le fichier C:\WINDOWS\system32\drivers\etc\hosts et d'ajouter le nom de l'hôte virtuel. 
127.0.0.1 www.jwadg.com
127.0.0.1 jwadg.com
Sous Linux, nous pouvons réaliser la même opération en éditant le fichier /etc/hosts : 
127.0.0.1 www.jwadg.com
127.0.0.1 jwadg.com
Désormais, lorsqu'une des URL suivantes : http://www.jwadg.com ou http://jwadg.com sera appelée dans un navigateur, c'est la machine locale (127.0.0.1) qui répondra aux requêtes du client. Cela évite d'acheter les deux noms de domaine pour nos tests. Nous pouvons désormais tester la configuration du connecteur Apache GlassFish en ouvrant un navigateur Web et en saisissant l'URL de notre hôte http://www.jwadg.com.

Erreur de la configuration Apache GlassFish
Comme nous pouvons le voir dans la figure précédente, la configuration Apache est correcte mais le serveur GlassFish est incapable de répondre à la demande. En effet, il manque une dernière étape, la configuration du module mod_jk pour GlassFish.


1-B-5. Configurer le module mod_jk pour GlassFish

La configuration du module mod_jk pour GlassFish passe par la mise en place d'un écouteur sur le port 8009 et l'activation du module mod_jk pour ce port. En effet, comme précisé précédemment, le dialogue entre le serveur Apache et le serveur GlassFish est réalisé sur le port 8009.

Pour cela, nous pouvons utiliser l'interface d'administration du serveur et le menu Network Config - New... et ajouter un nouveau listener en plus de celui par défaut pour les sites (http-listener-1 port 8080), de celui de l'interface d'administration (admin-listener port 4848) et de celui pour SSL (http-listener-2 port 8181).

Sinon, nous pouvons utiliser la configuration en ligne de commande avec les deux lignes ci-dessous. Cette première ligne permet de créer un écouteur sur le port 8009 (listenerport) pour toutes les interfaces (listeneraddress) en correspondance avec l'hôte virtuel par défaut (server) et de le nommer jk-connector : 
$ asadmin create-http-listener --listenerport 8009 --listeneraddress 0.0.0.0 --defaultvs server jk-connector
Cet écouteur HTTP est correctement configuré, nous devons maintenant activer le connecteur jk pour qu'il puisse dialoguer avec Apache en précisant son nom et l'activation du module (jk-enabled) : 
$ asadmin set configs.config.server-config.network-config.networklisteners.network-listener.jk-connector.jk-enabled=true
Nous pouvons vérifier la création du connecteur en utilisant l'interface Web et en éditant l'écouteur nommé jk-connector. Nous pouvons observer que la case JK Listener est activée.

Configuration du module mod_jk sous GlassFish
La configuration du module mod_jk est terminée pour GlassFish, la dernière étape consiste à créer un hôte virtuel pour GlassFish en association de l'hôte virtuel Apache.

info En cas de problème lors du test du connecteur, les fichiers journaux d'Apache et de mod_jk peuvent nous aider en indiquant les raisons des dysfonctionnements.

1-B-6. Créer un hôte virtuel GlassFish

La mise en place d'un hébergement professionnel nécessite la création d'un hôte virtuel avec Apache et selon le même principe qu'avec GlassFish. La création d'hôte virtuel est réalisable avec l'interface Web par le menu Configuration - Virtual Servers - New...

Nous pouvons commencer par afficher la liste des serveurs virtuels disponibles sur la machine serveur GlassFish : 
$ asadmin list-virtual-servers
Il existe par défaut deux serveurs, server et __asadmin. Nous allons créer, par l'intermédiaire de l'interface en ligne de commande, un nouveau serveur virtuel pour notre projet jwadg : 
$ ./asadmin create-virtual-server --hosts www.jwadg.com,jwadg.com –-httplisteners jk-connector --defaultwebmodule gdawj jwadg
La ligne de commande ci-dessus permet de créer un hôte virtuel nommé jwadg pour les noms de domaine www.jwadg.com et jwadg.com avec pour connecteur ou écouteur associé jk-connector et comme application Java EE associée, gdawj.

La syntaxe de création d'un hôte virtuel en ligne de commande est la suivante : 
create-virtual-server
--hosts hosts
--httplisteners httplisteners
--defaultwebmodule web_module
virtual_server_id
Nous pouvons utiliser l'interface d'administration Internet pour vérifier que l'hôte virtuel est correctement configuré.

Configuration du serveur virtuel jwadg
L'application (ou module) gdawj est maintenant associée à l'hôte virtuel jwadg utilisant le connecteur jk sur le port 8009. Nous pouvons d'ailleurs remarquer que le lanceur d'applications présent dans le menu Applications - gdawj indique désormais l'adresse http://localhost:8009/gdawj pour accéder à l'application à la place de http://localhost:8080/gdawj.

La suppression du serveur virtuel peut être réalisée avec la commande suivante : 
$ ./asadmin delete-virtual-server jdawg
La configuration est maintenant terminée, nous pouvons redémarrer le serveur GlassFish pour activer le serveur virtuel et tester la configuration.

Déploiement de l'application gdawj pour le domaine www.jwadg.com
Le déploiement du projet gdawj pour le domaine www.jwadg.com et son alias jwadg.com est désormais totalement opérationnel. L'application est déployée dans un contexte professionnel, avec le serveur Web Apache en frontal et le serveur GlassFish pour les services Java EE.


1-B-7. Optimisation du déploiement des applications

Les explications sur la configuration d'un hôte virtuel sont correctes mais l'application doit alors être déployée AVANT la configuration de l'hôte et, en cas de suppression de l'application, l'hôte ne sera plus relié avec une application spécifique. Pour nous en convaincre, nous pouvons supprimer l'application précédemment déployée et la déployer à nouveau : 
$ asadmin undeploy gdawj
$ asadmin deploy /home/lafosse/gdawj.war
Lors du déploiement nous ne précisons pas d'hôte virtuel associé, l'application sera donc accessible avec l'URL http://localhost:8080/gdawj mais nous serons gratifiés d'une erreur 404 si nous accédons à l'URL http://www.jwadg.com. Pour éviter ce problème, GlassFish permet de déployer une application et de préciser directement en ligne de commande un hôte virtuel associé : 
$ asadmin deploy –-virtualservers jwadg --enabled=true /home/lafosse/gdawj.war
Le serveur GlassFish offre également la possibilité de précompiler les pages JSP pour faciliter la mise en ligne et vérifier la syntaxe de l'ensemble de l'archive : 
$ asadmin deploy -–virtualservers jwadg --precompilejsp=true --verify=true --enabled=true /home/lafosse/gdawj.war
info Toutes les étapes en relation avec des actions sur les serveurs virtuels nécessitent des redémarrages du serveur. Les actions sur les applications, quant à elles, ne nécessitent aucun redémarrage et sont directement actives.

2. Apache / GlassFish et HTTPS/SSL

Le serveur GlassFish propose dans sa configuration par défaut un connecteur HTTPS préconfiguré.

En effet, l'écouteur défini sous le nom http-listener-2 dans le menu Configuration - Network Config - Network Listeners permet d'écouter de façon sécurisée, en utilisant le protocole HTTPS, sur le port 8181.

Configuration de l'écouteur HTTPS GlassFish
Cette configuration est proposée en standard et nous pouvons donc accéder à nos applications déployées de façon sécurisée en utilisant le protocole HTTPS sur le port 8181 à la place de 8080 en acceptant le certificat SSL proposé par GlassFish.

Certificat SSL proposé par GlassFish
Configuration de l'hôte virtuel server
Lorsqu'une application est déployée avec GlassFish, elle utilise comme hôte par défaut server.

Cet hôte possède deux écouteurs ou listeners, nous pouvons le vérifier avec l'interface d'administration et le menu Configuration - Virtual Servers - server.

Comme nous pouvons le remarquer, cet hôte virtuel est associé à deux écouteurs, http-listener-1 sur le port 8080 et http-listener-2 sur le port 8181. Notre application sera donc accessible à cette adresse pour le protocole HTTP non sécurisé : http://localhost:8080/gdawj et à cette adresse pour le protocole HTTPS sécurisé : https://localhost:8181/gdawj.

info Les ports 8080 pour la connexion HTTP et 8181 pour HTTPS sont utilisés par défaut avec GlassFish, mais ils peuvent être différents lors d'une installation avec NetBeans. Il est donc nécessaire de vérifier les ports utilisés par le serveur Java EE.

2-A. Activer le protocole HTTPS dans GlassFish

Cette configuration par défaut est tout à fait utilisable dans la plupart des cas lors des développements.

Maintenant, si nous utilisons un déploiement utilisant un autre écouteur (listener) que celui proposé par défaut (server), nous pouvons tout de même activer la connexion SSL. Il suffit pour cela de se rendre dans la configuration de l'écouteur à l'aide du menu Configuration - Network Config - Network Listeners , de choisir l'écouteur souhaité (ex : jk-connector) et d'activer la case à cocher Security pour bénéficier du protocole HTTPS.

Activation du mode SSL pour un écouteur GlassFish

2-B. Activer le protocole HTTPS pour le couple Apache/GlassFish

Comme pour l'utilisation d'un serveur GlassFish HTTP en production, la configuration idéale en termes de performances et de fiabilité est l'utilisation du moteur HTTPS d'un serveur Web à la place de celui de GlassFish. Pour cela, nous utiliserons, sur un serveur de production Linux, le serveur ApacheSSL. La configuration d'ApacheSSL est semblable à celle d'Apache. Il est cependant nécessaire d'utiliser des clés correctes et une configuration adaptée. Voici ci-dessous un exemple de configuration sur un serveur Linux.

Les étapes suivantes sont utilisées pour l'installation d'Apache et de GlassFish en mode HTTPS :

Activation du mod SSL pour Apache : 
$ a2enmod ssl
Génération d'un certificat SSL : 
$ openssl req -x509 -nodes -days 365 -newkey rsa:1024 -out /etc/apache2/server.crt -keyout /etc/apache2/server.key
Le paramètre -x509 -nodes donne le type de certificat voulu.

Le paramètre -days 365 indique la durée de validité (en jours) de notre certificat.

Le paramètre -newkey rsa:1024 demande une clé RSA de 1024 bits.

Le paramètre -out /etc/apache2/server.crt est le chemin de votre certificat.

Le paramètre -keyout /etc/apache2/server.key est le chemin de la clé privée.



               Version PDF (Miroir)   Version hors-ligne (Miroir)

Valid XHTML 1.0 TransitionalValid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © Jérôme Lafosse. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Cette page est déposée.

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum Dév. Web Java

Blogs

Hébergement

 
Partenaires

Hébergement Web