Pour un même site web, plusieurs serveurs sont souvent nécessaires, afin de répartir la charge, de garantir une disponibilité constante, de spécialiser certains serveurs sur certaines applications.  Et pour un même site web, souvent il est préférable d’avoir un seul nom de domaine et par là même un seul certificat SSL. Un domaine, plusieurs serveurs, un seul certificat … ça ne sent pas bon, non !
En fait, ce n’est pas si compliqué, Apache sait très bien gérer cela, mais dans un environnement ADF, quelles sont les implications ?

Prenons un domaine abc.mydomain.com. Actuellement : il faut générer une clé privée, puis un csr (certificat signing request) et l’envoyer à une autorité de certification reconnue. En retour, nous recevrons un fichier crt (certificat). Ce fichier crt, avec sa clé seront configurés dans un frontal Web, en général de type Apache.
Et c’est apache qui répartira ensuite les différentes sessions sur les différents clusters.
Mais est il réellement utile de passer par le Mod_weblogic pour accéder aux applications ADF en mode sécurisé ? Ce passage est en effet couteux car l’échange se décompose de la façon suivante :

1. réception du paquet ssl sur le frontal et déchiffrement par apache
2. chiffrement avec le certificat de Weblogic
3. envoi vers weblogic
4. réception du paquet ssl sur Weblogic
5. déchiffrement par weblogic
6. traitement de la requête
7. chiffrement de la réponse
8. envoi de la réponse vers apache
9. déchiffrement par apache
10. chiffrement de la réponse pour le client par apache

Beaucoup de temps CPU consommé, mais pas forcément inutilement : les éléments de chiffrement intermédiaires peuvent être utiles si on ne maitrise pas la sécurité du réseau entre le frontal et le serveur d’application.
ADF par défaut propose de mettre le transport en mode HTTPS quand l’option ADF-security est activée. Ce n’est qu’un mode par défaut.
Dans le fichier web.xml il faut passer la variable

<user-data-constraint>
 <transport-guarantee>CONFIDENTIAL</transport-guarantee>
 </user-data-constraint>

à

<user-data-constraint>
 <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>

de cette façon le cheminement devient :

1. réception du paquet ssl sur le frontal et déchiffrement par apache
2. envoi vers weblogic
3. réception du paquet sur Weblogic
4. traitement de la requête
5. envoi de la réponse vers apache
6. chiffrement de la réponse pour le client par apache

cela économise 2 étapes de chiffrement / déchiffrement, et on diminue les échanges réseaux.
Attention à ne pas utiliser cette méthode en direct sur Internet !