Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Futur Membre du Club
    Problème t3s entre nodemanager et console d'administration après passage en https
    Bonjour,

    Dans un cluster weblogic j'ai paramétré ma console d'administration pour qu'elle ne soit accessible qu'en https. Pour cela pas de problème, ma console s’allume correctement et je peux y accéder uniquement en https comme prévu.

    Le problème vient lorsque j'essaie de me connecter à la console via l'utilitaire wlst.sh

    j'explique le contexte:

    Pour que tout soit automatique, un script ksh appelle des librairies python sur wlst.sh.

    La fonction permettant de déterminer l’état de la console d'administration se connecte tout d'abord au nodemanager grâce à la fonction nmConnect().

    Ensuite, on se connecte à la console d’administration grâce à connect(user,password,'t3://address:port') (t3s remplace t3 dans ma fonction si la console est en https)
    Avant le passage en https, aucune erreur

    Après ca:
    javax.net.ssl.SSLException: Received fatal alert: unexpected_message; No available router to destination
    En debugant je découvre que lors du démarrage de la console d'administration cette option est activée: -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.0, si je l'enlève ou que je la remplace par -Dweblogic.security.SSL.ProtocolVersion=ALL l'erreur ne survient plus

    En cherchant sur internet je tombe sur cette page du support oracle:
    https://support.oracle.com/epmos/fac...e=11mxluug1m_4

    Voici ce qui y est écrit si le lien est mort:
    Cause

    Weblogic client lib tries to start handshake with sslv2 to Weblogic server and was rejected.
    Solution

    Configure Weblogic client not to use SSL as follows:

    1. On the desktop running Java Client, go to Control Panel -> Java -> Java tab -> View...

    2. Find the JRE used to run Java Client. In Runtime Parameters, add: -Dweblogic.security.SSL.protocolVersion=TLS1. Click OK, OK.

    Note: If you have both 32-bit and 64-bit of the same JRE version installed, the Java Control Panel may only show the 64-bit. However, it's the32-bit that is being used. In this case, uninstall the 32-bit edition.

    J'ai donc remplacé ma ligne qui causait le problème par celle donnée ci-dessus -Dweblogic.security.SSL.protocolVersion=TLS1

    Le problème n'a pas été reglé.

    Ma question est donc:

    y a t-il a moyen de communiquer en t3s sans autoriser tous les protocoles ? et sinon est-ce que si je mets cet argument -Dweblogic.security.SSL.ProtocolVersion=ALL (ou aucun car cela revient au même) la sécurité est réduite ou est-ce que cela n'aura pas d'impact concret ?



    Pour info, voici les paramètres de démarrage de ma console (sauf la ligne que j’évoque précédemment) en question):

    -server
    -Xms256m
    -Xmx512m
    -XX:CompileThreshold=8000
    -XXermSize=128m
    -XX:MaxPermSize=256m
    -Dweblogic.Name=myserver
    -Djava.security.policy=/logiciels/bea/weblogic_12.1.3/wlserver/server/lib/weblogic.policy
    -Dweblogic.system.BootIdentityFile=chemin/boot.properties
    -Dweblogic.nodemanager.ServiceEnabled=true
    -Dweblogic.nmservice.RotationEnabled=true
    -Xverify:none
    -Djava.endorsed.dirs=/opt/java/jdk1.8.0_192_Linux_64bits//jre/lib/endorsed:/logiciels/weblogic_12.1/oracle_common/modules/endorsed
    -da
    -Dwls.home=/logiciels/bea/weblogic_12.1.3/wlserver/server
    -Dweblogic.home=/logiciels/bea/weblogic_12.1.3/wlserver/server
    -Dweblogic.utils.cmm.lowertier.ServiceDisabled=true
    -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
    -Dweblogic.ssl.SSLv2HelloEnabled=false

  2. #2
    Membre habitué
    y a t-il a moyen de communiquer en t3s sans autoriser tous les protocoles ? et sinon est-ce que si je mets cet argument -Dweblogic.security.SSL.ProtocolVersion=ALL (ou aucun car cela revient au même) la sécurité est réduite ou est-ce que cela n'aura pas d'impact concret ?
    Le moyen le plus plus facile pour bloquer certain protocoles est d’utiliser le filtre de connections (Using Network Connection Filters : https://docs.oracle.com/cd/E23943_01...r.htm#SCPRG388)
    Par exemple la règle "0.0.0.0/0 * * deny http t3", bloque les protocole http et t3.

    weblogic.security.SSL.ProtocolVersion et weblogic.security.SSL.minimumProtocolVersion n'est la même chose mais complémentaire (https://docs.oracle.com/middleware/1...n.htm#SECMG635)

    Si avec minimumProtocolVersion=TLSv1.0 wlst donne une erreur, c'est que la version de java utilisé par wlst ne supporte pas TLS, que le port t3s n'est pas le bon ou que le certificat serveur n'est pas trusté par le client wlst.
    Noter que la version TLS à utiliser en 2020 est TLSv1.2 minimum, sauf si votre client ne le supporte pas.

    Pour le debug de la connexion, il faut ajouter -Djavax.net.debug=all en argument de la commande java utilisé par wlst. (https://docs.oracle.com/javase/7/doc...ReadDebug.html)

  3. #3
    Futur Membre du Club
    J'ai trouvé !!
    Bonjour,

    Merci de ta réponse jdevbe !

    J'ai trouvé le problème.

    Il venait du fait que le script wlst.sh (dans mon cas voici le chemin /logiciels/bea/weblogic_12.1.3/oracle_common/common/bin/wlst.sh)

    En effet en utilisant cet outil, lors de mes connexions en t3s il utilisait SSLv2Hello ce qui était donc bloqué par cette option au démarrage de ma console -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.0

    En ajoutant cette ligne au début du fichier:

    CONFIG_JVM_ARGS="$CONFIG_JVM_ARGS -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.0 -Dweblogic.security.SSL.protocolVersion=TLS1 -Djdk.tls.client.protocols=TLSv1.2 -Dhttps.protocols=TLSv1.2 -Dweblogic.ssl.SSLv2HelloEnabled=false"
    wlst.sh utilise maintenant TLSV1.2 avec t3s, ce qui n'est donc plus bloqué

###raw>template_hook.ano_emploi###