Wildfly 22 SSL

SA

unread,

Feb 9, 2021, 11:03:50 PM2/9/21

to WildFly

I'm trying to install SSL/enable https on my domain names on Wildfly 22. I have tried several resources online but in the end I am left even more confused:

https://developer.jboss.org/people/fjuma/blog/2018/08/31/obtaining-certificates-from-lets-encrypt-using-the-wildfly-cli#jive_content_id_Prerequisite_configuration

https://dzone.com/articles/elytron-a-new-security-framework-in-wildflyjboss-e

https://medium.com/@hasnat.saeed/setup-ssl-https-on-jboss-wildfly-application-server-fde6288a0f40

None of these above have helped and ended up making my normal http://domain1.co and http://domain2.co stop working.

So, I am back to square one and I have a vanilla standalone.xml file, with a minor change for multiple domains:

standalone.xml

<buffer-cache name="default"/>

<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>

<https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

<http-invoker security-realm="ApplicationRealm"/>

</host>

</server>

< servlet-container name="default">

<jsp-config/>

</servlet-container>

</handlers>

</subsystem>

I manually get a Zero SSL cert/key, and generated a keystore using this command:

> sudo openssl pkcs12 -export -out wildfly-pkcs12.pfx -in cert.crt -inkey server-private.key -certfile ca.crt

What do I do next? Seriously, there is vague and little to no instruction and I've tried everything from changing the 'ApplicationRealm' keystore path; to creating a new 'SslReam' with the keystore path-- but this just makes my normal http not work as well as https never work.

Why is this so complicated for a simple SSL?

dvilkola

unread,

Feb 10, 2021, 5:07:22 AM2/10/21

to WildFly

Try to check WildFly 22 documentation, specifically: https://docs.wildfly.org/22/WildFly_Elytron_Security.html#configure-ssltls .

Farah Juma

unread,

Feb 10, 2021, 11:17:52 AM2/10/21

to WildFly

If you want to use different certificates for different virtual hosts, this blog post on SNI matching might also be useful:

https://wildfly-security.github.io/wildfly-elytron/blog/server-side-sni-matching-with-wildfly/

SA

unread,

Feb 26, 2021, 1:53:37 AM2/26/21

to WildFly

None of this is working. How do I manually install via Management Console?

SA

unread,

Feb 26, 2021, 1:55:17 AM2/26/21

to WildFly

I tried this way and got the https to work but it says the certificate is not trusted. It's 2021, why is an SSL so hard to install on a webserver?

On Wednesday, February 10, 2021 at 5:07:22 AM UTC-5 dvilkola wrote:

Farah Juma

unread,

Mar 1, 2021, 2:16:02 PM3/1/21

to WildFly

Which certificate authority issued the certificate? From your first message, it looks like you're using Zero SSL which should be trusted by most browsers. Have you inspected the certificate that's being presented by the server to make sure it's actually the correct one?

When a single domain name is being used, it is possible to easily enable one-way SSL for WildFly using the security enable-ssl-http-server --interactive command (the --lets-encrypt option can also be used to automatically obtain a certificate from Let's Encrypt).

For the case with multiple virtual hosts, additional configuration is needed. The complete steps are described in https://wildfly-security.github.io/wildfly-elytron/blog/server-side-sni-matching-with-wildfly/ but this example makes use of self-signed certificates. To modify the example to make use of signed certificates, you either need to import your manually obtained signed certificates into your server's keystore or you can use the key-store obtain-certificate operation to automatically obtain certificates from a certificate authority like Let's Encrypt (as described here).

Shawn Akhter

unread,

Mar 1, 2021, 4:01:13 PM3/1/21

to Farah Juma, WildFly

I gave up using Zero SSL after I found these instructions the other day: https://wildfly-security.github.io/wildfly-elytron/blog/auto-self-signed-certificate-generation/

I used this command to get SSL for both domains under 1 certificate:

/subsystem=elytron/key-store=serverKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

I followed these instructions and SSL still does not work. https://domain1.co and https://domain2.co still says the certificate is self-signed, even after removing the self-signed tag. I've rebooted the server

/subsystem=elytron/key-manager=applicationKM:undefine-attribute(name=generate-self-signed-certificate-host)

What am I doing wrong? I am on Wildfly 22.

--
You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/_VFb3n2NZMI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/da2e9eae-b709-4d12-91d2-1bfcc442c08fn%40googlegroups.com.

SA

unread,

Mar 1, 2021, 4:05:20 PM3/1/21

to WildFly

I just don't understand why the wildfly SSL instructions are so convoluted and confusing. I find many step by step guides that say completely different things with respect to SSL installation. Very frustrating.

Farah Juma

unread,

Mar 1, 2021, 5:07:41 PM3/1/21

to WildFly

On Monday, March 1, 2021 at 4:01:13 PM UTC-5 SA wrote:

I gave up using Zero SSL after I found these instructions the other day: https://wildfly-security.github.io/wildfly-elytron/blog/auto-self-signed-certificate-generation/
I used this command to get SSL for both domains under 1 certificate:
/subsystem=elytron/key-store=serverKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

Note that the above blog post had a typo and was referencing serverKS instead of applicationKS in the example for switching from the generated self-signed certificate to a certificate from Let's Encrypt.

Just to make sure, which key-store did you use to obtain your Let's Encrypt certificate? Since you are now using the default SSL context configuration, you'll want to make sure that the applicationKS key-store was used and that the applicationKM key manager was re-initialized after that as described in the blog post. It would also be good to verify that you've updated the Undertow subsystem configuration to make use of the default applicationSSC ssl-context.

We are working on simplifying SSL configuration for common use cases. If there are specific use cases which you would like to see simplified, feel free to add a comment here to let us know:

https://issues.redhat.com/browse/WFCORE-5279

SA

unread,

Mar 3, 2021, 12:04:33 PM3/3/21

to WildFly

I used the command listed in the blog post.

/subsystem=elytron/key-store=serverKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

are you saying it should be this instead? :

/subsystem=elytron/key-store=applicationKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

Farah Juma

unread,

Mar 3, 2021, 12:15:23 PM3/3/21

to WildFly

On Wednesday, March 3, 2021 at 12:04:33 PM UTC-5 SA wrote:

I used the command listed in the blog post.

/subsystem=elytron/key-store=serverKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

are you saying it should be this instead? :

/subsystem=elytron/key-store=applicationKS:obtain-certificate(alias=server,domain-names=[www.domain1.co, www.domain2.co],certificate-authority-account=myLetsEncryptAccount,agree-to-terms-of-service)

Yes, if you are attempting to use the default SSL context configuration and are switching to a signed certificate, this command should be used since the applicationKS is the keystore that is used by the default SSL context configuration.

jasi...@gmail.com

unread,

Mar 3, 2021, 3:45:42 PM3/3/21

to WildFly

If you're using self-signed certificates, you need to set up two keystores

applicationKS needs the both the key and certificate that you want to use
trustKS needs to have the certificate added as a trusted certificate

Next you need key-managers for both key-stores.

Then you need to create a trust manager (<trust-manager/> element under <trust-managers/>) and point it to your trust key manager

Your server-ssl-context context needs a trust-manger attribute to point to your trust manager

And last but not least, set the default-ssl-context attribute on the Elytron sub-system to point to your server-ssl-context.

I know, I know, we're not supposed to use self-signed certificates, but who wants to purchase certificates for development. WildFly needs to provide an example of this instead of just saying they use self-signed certificates internally but we shouldn't. I spent several frustrating days figuring this out.

Farah Juma

unread,

Mar 3, 2021, 4:19:27 PM3/3/21

to WildFly

Something to keep in mind is that WildFly does have a CLI command that can be used to walk you through the process of configuring either one-way or two-way SSL.

In particular, if you want to enable one-way or two-way SSL using a self-signed certificate that will be generated automatically for your server instance, the following command can be used:

security enable-ssl-http-server --interactive

If you want to enable one-way or two-way SSL using a certificate that will be automatically obtained from Let's Encrypt for your server instance, the following command can be used:

security enable-ssl-http-server --interactive --lets-encrypt

More details on the information that needs to be provided when prompted can be found in the WildFly documentation:

https://docs.wildfly.org/22/WildFly_Elytron_Security.html#configure-ssltls

Reply all

Reply to author

Forward