http - ssl wildfly 12

Wildfly 9 http a https (2)

Quiero redirigir la solicitud de HTTP a HTTPS. Estoy usando wildfly 9. Después de una búsqueda en Google, encontré lo siguiente, pero no está funcionando. Espero que alguien

Primero, estoy basando esto en WildFly 9.0.1.Final y asumo que simplemente está intentando habilitar SSL a través de HTTPS y no me preocupa la autenticación. Acabo de pasar un día pensando en todo esto. Trabajar fuera de esta documentación:

https://docs.jboss.org/author/display/WFLY9/Admin+Guide

Lo primero que desea hacer es crear su almacén de claves tal como se describe en la documentación.

https://docs.jboss.org/author/display/WFLY9/Admin+Guide#AdminGuide-EnableSSL
La pregunta realmente importante para responder correctamente es la que solicita su nombre y apellido. Allí, debe colocar el nombre de host del servidor de aplicaciones (por ejemplo, localhost). Abra una ventana de terminal en la carpeta {jboss.home} / standalone / configuration e ingrese el siguiente comando:

keytool -genkey -alias MY_ALIAS -keyalg RSA -keystore MY_KEYSTORE_FILENAME -validity 365`

NOTA: MY_ALIAS, MY_KEYSTORE_FILENAME y MY_PASSWORD son arbitrarios y puede configurarlos como desee.

El siguiente paso es modificar el archivo standalone-XXX.xml en el mismo directorio {jboss.home} / standalone / configuration. Estoy usando el archivo standalone-full.xml , sin embargo, creo que esto también funcionará para los demás.

El siguiente paso en la documentación que vinculé anteriormente nos dice que pongamos la referencia del almacén de claves SSL en ManagementRealm. Esto puede llevar a una gran confusión. Para los propósitos de esta respuesta, estoy tratando de que WildFly habilite SSL sobre el puerto 8443 para acceder a mis aplicaciones. Aunque también habilité SSL para la consola de administración (a través del puerto 9993), eso es para más adelante.

Sugiero poner la información del almacén de claves en ApplicationRealm de la siguiente manera:

<security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="MY_KEYSTORE_FILENAME" relative-to="jboss.server.config.dir" keystore-password="MY_PASSWORD" alias="MY_ALIAS" key-password="MY_PASSWORD"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm>

NOTA: los únicos cambios en el archivo predeterminado en esta sección deben ser la etiqueta de identidades del servidor. La etiqueta de autenticación debe dejarse sola a menos que tenga otras razones para modificarla.

NOTA: MY_KEYSTORE_FILENAME, MY_ALIAS y MY_PASSWORD deben coincidir con los valores que proporcionó al crear la clave.

Ahora, la documentación se vuelve un poco complicada. Ahora debe desplazarse un poco hacia abajo para realizar el siguiente paso, aunque desafortunadamente no le dice que lo haga. Ahora que tiene el almacén de claves instalado en Wildfly y configurado dentro del reino de seguridad adecuado, debe instalar el agente de escucha HTTPS y vincularlo al almacén de claves.

https://docs.jboss.org/author/display/WFLY9/Admin+Guide#AdminGuide-HTTPSlistener
Oyente HTTPS
El oyente Https proporciona acceso seguro al servidor. La opción de configuración más importante es el reino de seguridad que define el contexto seguro SSL.

Desafortunadamente, la documentación no es coherente con el atributo security-realm (anteriormente se instaló el almacén de claves en ManagementRealm y aquí se hace referencia en ssl-realm). Desde que puse el almacén de claves en ApplicationRealm, necesitamos hacer referencia a él como tal.

Además, solo para aclarar, debe colocar esto dentro del subsistema de resaca . Aquí está lo que inserté, justo debajo de la etiqueta http-listener:

<https-listener name="httpsServer" socket-binding="https" security-realm="ApplicationRealm"/>

A continuación se muestra el cuerpo completo del subsistema de resaca .

Y también, la etiqueta socket-binding-group que define los propios puertos:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="http" port="${jboss.http.port:8080}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="iiop" interface="unsecure" port="3528"/> <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group>

NOTA: notará que en el servicio de escucha HTTPS nos referimos a name = "httpsServer" (este valor ''httpServer'' es arbitrario y se puede configurar a lo que desee), socket-binding = "https" (este valor ''https'' debe coincidir el socket https que se encuentra en el grupo de enlace de sockets) y security-realm = "ApplicationRealm" (este valor ''ApplicationRealm'' debe ser el dominio de seguridad en el que haya instalado el almacén de claves).

Con esta configuración, debería encontrar que los puertos 8443 (seguro) y 8080 (no seguro) funcionan para acceder al servicio de aplicación de WildFly. El puerto 9990 (no seguro) todavía funciona para acceder a la IU de administración web, sin embargo 9993 (IU de administración segura) no lo hace.

CONSOLA DE ADMINISTRACIÓN SEGURA

Encontré estas instrucciones y funcionaron perfectamente.

http://www.mastertheboss.com/jboss-server/jboss-security/securing-access-to-jboss-wildfly-management-console

El primer paso es crear la clave SSL:

keytool -genkeypair -alias serverkey -keyalg RSA -keysize 2048 -validity 7360 -keystore server.keystore -keypass mypassword -storepass mypassword

NOTA : Recuerde, el nombre de su servidor debe usarse cuando se le pide el nombre / apellido.

A continuación, configure ManagementRealm en el archivo XXX.xml independiente para incluir el almacén de claves. Agregue la siguiente etiqueta de identidades de servidor:

<server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="mypassword" alias="serverkey" key-password="mypassword"/> </ssl> </server-identities>

A continuación se muestra el aspecto de ManagementRealm completo:

<security-realm name="ManagementRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="mypassword" alias="serverkey" key-password="mypassword"/> </ssl> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm>

A continuación, la sección de interfaces de administración del archivo standalone-XXX.xml utiliza un enlace de socket HTTP y queremos vincularlo al socket HTTPS (específicamente, el socket management-https).

<management-interfaces> <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true"> <socket-binding https="management-https"/> </http-interface> </management-interfaces>

NOTA: vea cómo la interfaz hace referencia a ManagementRealm security-realm. Lo intenté solo haciendo referencia a ApplicationRealm, sin crear un almacén de claves separado y todavía funcionó de alguna manera. Probablemente es una buena práctica no reutilizar ese código para ambos propósitos.

NOTA: a continuación se muestra la definición de socket de administración https en la interfaz de administración.

<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>

NOTA: para cualquiera de las definiciones de socket, puede (si es necesario) cambiar el número de puerto.

REDIRECTE HTTP a HTTPS

En su archivo web.xml, inserte la siguiente porción de código dentro de la etiqueta de la aplicación web.

<security-constraint> <web-resource-collection> <web-resource-name>WEB_APPLICATION_NAME</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

NOTA: debe poner el nombre de su aplicación donde dice WEB_APPLICATION_NAME. No puedo estar seguro de lo que sería en todos los escenarios, pero para mí, si el archivo war que se está implementando es MyApp.war, entonces pongo MyApp allí.

Puede utilizar CONFIDENCIAL, INTEGRAL o NINGUNO para la garantía de transporte. Tenga en cuenta la siguiente URL: https://docs.oracle.com/cd/E19798-01/821-1841/bncbk/index.html que describirá las diferencias, sin embargo, también establece que CONFIDENTIAL e INTEGRAL son efectivamente las mismas.

Una vez que el código está instalado, ya está. Continúe y pruébelo utilizando https a través del puerto 8443 y luego utilizando http a través del puerto 8080. Notará que cuando usa http / 8080, responde y su navegador cambia a https / 8443. Si eres como yo y no confías en él, puedes rizarlo.

curl -vv -k -L -X GET http://localhost:8080/MyApp/rest/endpoint

Verá una salida similar a la siguiente, que demuestra que la redirección está funcionando:

El nombre de host NO se encontró en el caché de DNS
Tratando 127.0.0.1 ...
Conectado al puerto 8080 (# 0) de localhost (127.0.0.1)
GET / MyApp / rest / endpoint HTTP / 1.1
User-Agent: curl / 7.35.0
Anfitrión: localhost: 8080
Aceptar: /
HTTP / 1.1 302 encontrados
Conexión: mantener vivo
X-Powered-By: Undertow / 1
El servidor WildFly / 9 no está en la lista negra
Servidor: WildFly / 9
Ubicación: https://localhost:8443/MyApp/rest/endpoint
Contenido-Longitud: 0
Fecha: viernes, 04 de septiembre de 2015 18:42:08 GMT
Conexión # 0 para alojar localhost dejado intacto
Emita otra solicitud a esta URL: '' https://localhost:8443/MyApp/rest/endpoint ''
Paquete encontrado para host localhost: 0x8d68f0
El nombre de host NO se encontró en el caché de DNS
Tratando 127.0.0.1 ...
Conectado al puerto localhost (127.0.0.1) 8443 (# 1)
Establecer correctamente las ubicaciones de verificación de certificado:
Archivo: ninguno
CApath: / etc / ssl / certs
SSLv3, protocolo de enlace TLS, cliente hola (1):
SSLv3, protocolo de enlace TLS, servidor hello (2):
SSLv3, protocolo de enlace TLS, CERT (11):
SSLv3, protocolo de enlace TLS, intercambio de claves de servidor (12):
SSLv3, protocolo de enlace TLS, servidor terminado (14):
SSLv3, protocolo de enlace TLS, intercambio de claves de cliente (16):
SSLv3, cifrado de cambio TLS, cliente hola (1):
SSLv3, protocolo de enlace TLS, terminado (20):
SSLv3, cifrado de cambio TLS, cliente hola (1):
SSLv3, protocolo de enlace TLS, terminado (20):
Conexión SSL utilizando ECDHE-RSA-DES-CBC3-SHA
Certificado de servidor:
tema: C = US; ST = Desconocido; L = Desconocido; O = Org; OU = Desconocido; CN = localhost
fecha de inicio: 2015-09-04 15:23:06 GMT
fecha de caducidad: 2016-09-03 15:23:06 GMT
emisor: C = US; ST = Desconocido; L = Desconocido; O = Org; OU = Desconocido; CN = localhost
Resultado de verificación del certificado SSL: certificado autofirmado (18), continuando de todos modos.
GET / MyApp / rest / endpoint HTTP / 1.1
User-Agent: curl / 7.35.0
Anfitrión: localhost: 8443
Aceptar: /
HTTP / 1.1 200 Prohibido
Conexión: mantener vivo
X-Powered-By: Undertow / 1
El servidor WildFly / 9 no está en la lista negra
Servidor: WildFly / 9
Tipo de contenido: aplicación / json
Contenido-Longitud: 42
Fecha: viernes, 04 de septiembre de 2015 18:42:08 GMT
Conexión # 1 para alojar localhost dejado intacto

ACTUALIZACIÓN PARA Wildfly 10

En Wildlfy 10 es aún más fácil asegurar la interfaz de administración. Los dos primeros pasos son los mismos:

1) Prepare una clave, por ejemplo con keytool (o también puede usar openSSL)

keytool -genkeypair -alias serverkey -keyalg RSA -keysize 2048 -validity 7360 -keystore server.keystore -keypass mypassword -storepass mypasswor

2) Agregue SSL en su ManagementRealm. P.ej:

<security-realm name="ManagementRealm"> <server-identities> <ssl> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="mypassword" alias="serverkey" key-password="mypassword"/> </ssl> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> ...

LA DIFERENCIA IMPORTANTE ES LO SIGUIENTE:

En http-interface , en lugar de socket-binding socket solo tiene socket .

Por defecto podría verse, por ejemplo, como el siguiente:

<http-interface security-realm="ManagementRealm" http-upgrade-enabled="true"> <socket interface="management" port="${jboss.management.http.port:9990}"/> </http-interface>

Simplemente cambie de puerto a puerto seguro y el trabajo está hecho.

<http-interface security-realm="ManagementRealm" http-upgrade-enabled="true"> <socket interface="management" secure-port="${jboss.management.http.port:9990}"/> </http-interface>