Configuring Wildfly for HTTPS in a post Poodle world

If you have ever run into “ssl_error_no_cypher_overlap” errors trying to configure Wildfly to use HTTP then you have probably cursed the lack of decent documentation for configuring Wildfly now that browsers have disabled a lot of insecure SSL cyphers. This is how I got around the problem.

First you need a self signed key. This can be created with the command:

keytool -genkey -alias mycert -keyalg RSA -sigalg SHA256withRSA -keystore my.jks -storepass secret  -keypass secret -validity 9999

Then you need to configure Wildfly to accept a list of known cyphers. Mozilla has a nice list of cypher codes for high security, compatibility etc at https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility.

The problem is that this list has the OpenSSL key names, and Wildfly needs the RFC names. So you need to map one to the other using the table at https://testssl.sh/openssl-rfc.mappping.html.

What I ended up with was this list, defined in a enabled-cipher-suites attribute. This list is the Modern Compatibility list. This is added to the <subsystem xmlns="urn:jboss:domain:undertow:2.0"> element.

<https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enabled-cipher-suites="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA" />

You then need to configure the self signed key with this. It goes under the <management><security-realms> element.

 <security-realm name="UndertowRealm"> <server-identities> <ssl> <keystore path="my.jks" relative-to="jboss.server.config.dir" keystore-password="secret" alias="mycert" key-password="secret"/> </ssl> </server-identities> </security-realm>

Comments

giaonhan247 said…
Thanks for sharing, nice post! Post really provice useful information!

An Thái Sơn với website anthaison.vn chuyên sản phẩm máy đưa võng hay máy đưa võng tự động tốt cho bé là địa chỉ bán máy đưa võng giá rẻ tại TP.HCM và giúp bạn tìm máy đưa võng loại nào tốt nhất hiện nay.
1:40 pm
Digital Marketing Course in Hyderabad said…
Thanks for this clear guide! In a post-POODLE world, making sure WildFly is properly configured for HTTPS is crucial to maintaining security. Your step-by-step instructions make it much easier to follow and avoid common pitfalls. It’s good to see a focus on disabling weak protocols like SSLv3 and ensuring the server supports stronger encryption. This article is a great resource for anyone looking to tighten their WildFly setup.
Digital Marketing Course In Hyderabad
5:22 pm
Post a Comment

Popular posts from this blog

MinHash for dummies

Duplicate document detection is becoming increasingly important for businesses that have huge collections of email, web pages and documents with multiple copies that may or may not be kept up to date. MinHash is a fairly simple algorithm that from all my Googling has been explained very poorly in blogs or in the kind of mathematical terms that I forgot long ago. So in this article I will attempt to explain how MinHash works at a practical code level. Before I start, please take a look at  http://infolab.stanford.edu/~ullman/mmds/ch3.pdf . That document goes into a lot of theory, and was ultimately where my understanding on MinHash came from. Unfortunately it approaches the algorithm from a theoretical standpoint, but if I gloss over some aspect of the MinHash algorithm here, you will almost certainly find a fuller explanation in the PDF. I'll also be using pseudo Java in these examples instead of traditional math. This means when I use terms like Set, I am referring to the gr...
Read more

Authenticating via Kerberos with Keycloak and Windows 2008 Active Directory

Image
The following instructions show you how to configure Keycloak with Windows AD in order to use Kerberos authentication. Assumptions The Kerberos realm is VIRTUAL.LOCAL The hostname used to access Keycloak is virtual.local. This just means we are running Keycloak on the domain controller. In production virtual.local will be replaced with something like keycloak.dev.virtual.local or something like that, giving you a SPN of  HTTP/keycloak.dev.virtual.local@VIRTUAL.LOCAL Configuration Create a windows domain account called Keycloak. Run the following command to assign a SPN to the user and generate a keytab file: ktpass -out keycloak.keytab -princ HTTP/virtual.local@VIRTUAL.LOCAL -mapUser Keycloak@VIRTUAL.LOCAL -pass password1! -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT Verify the SPN has been assigned to the user with the command: setspn -l Keycloak Configure the LDAP settings in Keycloak like this. Since we are running Keycloak on the domain controller, we...
Read more

Fixing OpenVPN "Authenticate/Decrypt packet error: cipher final failed"

When connecting to a VPN I was constant getting the error Mar  8 09:29:27 openvpn[1696]: Authenticate/Decrypt packet error: cipher final failed I had imported the supplied ovpn file and had followed all the other configuration steps, so this was quite frustrating. Then I saw this in the logs: Mar  8 09:31:07 openvpn[1790]: WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-256-CBC' Changing my client to use "cipher AES-256-CBC" instead of the default (which apparently was cipher BF-CBC) fixed the issue.
Read more