viernes, 20 de marzo de 2015

Como gestionar las máquinas virtuales de Java de forma centralizada

No creo que diga ninguna mentira si afirmo que uno de los mayores dolores de cabeza de los Admins son las aplicaciones y webs con módulos de Java. Las directivas de seguridad, la poca integración con las políticas de sistema, el constante cambio de versiones y de criterio convierte en una quimera conseguir que Java se comporte en toda la organización.

Un compañero me ha pasado para el blog el manual que ha creado el para poder gestionar la configuración de Java:

Lo primero que hay que hacer es tener instaladas las versiones de 32 o 64 bits de la Máquina Virtual de Java.

Una vez instaladas las dos versiones, hay que crear el directorio C:\WINDOWS\SUN\Java\Deployment .

Dentro de esta carpeta crear dos archivos Deployment.config y Deployment.properties con los siguientes parámetros:

Deployment.config
deployment.system.config=file\:C\:/Windows/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true

Deployment.properties
deployment.javaws.shortcut=never
deployment.security.level=MEDIUM
deployment.security.mixcode=DISABLE
deployment.javaws.autodownload=never
deployment.expiration.check.enabled=false
deployment.expiration.check.enabled.locked
deployment.expiration.decision.suppression=true
deployment.expiration.decision.suppression.locked
deployment.expiration.decision=NEVER
deployment.expiration.decision.locked
deployment.user.security.exception.sites=c\:/Windows/Sun/Java/Deployment/exception.sites
deployment.system.security.trusted.certs=C\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

exception.sites
<URL QUE QUEREMOS AÑADIR COMO EXCEPCION>

trusted.certs
< Este archivo contiene los certificados de cada URL que queremos añadir para confiar. Este se genera en la carpeta c:\Users\<usuario> \AppData\LocalLow\Sun\Java\Deployment\security al entrar en la web y aceptar el Applet Java. Hay que copiarlo en cada equipo. >

Una vez creado la lista de excepciones que permiten que los applets de java se ejecuten, nos encontramos con los molestos mensajes de advertencia al intentar abrirlos. Yo he contado 5 mensajes de advertencia al abrir la consola de gestión de una VNX de EMC, un infierno...


Para evitar que aparezcan mensajes de advertencia como el anterior tenemos que configurar un conjunto de reglas en las que añadiremos todas las URLs que queremos permitir ejecutar sin preguntar al usuario.

Para poder configurar el ruleset tenemos que crear un archivo ruleset.xml y firmarlo con un certificado para poder distribuirlo en todos los equipos.

ruleset.xml
<ruleset version="1.0+">
<rule>
<id location="http://*.lasendadeladmin.com" />
<action permission="run" />
</rule>
<rule>
<id location="https://*.aeat.es" />
<action permission="run" />
</rule>
<rule>
<id />
<action permission="default">
<message>Este applet ha sido bloqueado por Java. Por favor contacte con su departamento de informatica para recibir ayuda.</message>
</action>
</rule>
</ruleset>

El siguiente paso es copiar este ruleset.xml donde tengamos el SDK (pe. C:\Program Files\Java\jdk1.7.0_71\bin) para poder firmar el archivo y empaquetarlo en un .JAR .

Crear Keystore


Antes de continuar, hay que crear un keystore si no lo teníamos creado de antes. Los pasos para crearlo son los siguientes.

> keytool -genkey -keyalg RSA -alias Areasselfsigned -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -storepass 123456 -validity 9000 -keysize 2048

Donde 123456 es el password para desbloquear el keystore (no confundir con el password del certificado).

Exportamos el certificado con el comando:
> keytool -export -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks"
Y lo importamos como entidad certificadora (CA) :
> keytool -importcert -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -trustcacerts -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
El password por defecto es changeit  


Y podemos distribuir el cacerts del equipo que estamos trabajando en los del resto de servidores y equipos, machacando el que pueda existir en el equipo de destino. Hay que copiarlo en la siguiente ruta:
C:\Program Files (x86)\Java\jre7\lib\security (es necesario copiarlo en la de 32bits)

Ahora que tenemos el certificado y ya lo tenemos distribuido en los equipos de destino podemos proceder a crear el paquete de distribución y firmarlo:

Creamos el jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml

Y lo firmamos con nuestro certificado:
> jarsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned
En cada servidor y equipo de destino hay que copiar este DeploymentRuleSet.jar en la carpeta:

C:\Windows\Sun\Java\Deployment

Modificaciones en el ruleset.xml


Si más adelante es necesario modificar el ruleset.xml para añadir más url, hay que añadir las reglas al archivo y volver a crear, firmar y distribuir un nuevo DeploymentRuleSet.jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml
> arsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned





3 comentarios:

  1. Buen articulo!!!
    No sabras porque a un usuario en el mismo pc le va y a otro no, no? Es como si no leyese el Deployment... estoy por borrarle el perfil local.

    ResponderEliminar
  2. Muchas gracias! Ha mirado que tipo de perfil tiene ese usuario en el PC? Tal vez tiene configurado el perfil de tipo móvil.

    ResponderEliminar
  3. Yep Fernando!
    Nada, era lo que contaba, no leia el deploy(utilizaba la version de java mas nueva por defecto) y no le queria borrar el perfil local.
    Al final sobreescribiendo unas carpetas del usuario que funcionaba(un clon, mismo perfil de AD) al que no funcionaba, todo ok y sin borrar el perfil.
    Merci!

    ResponderEliminar