Home » Java » Enterprise Java » Apache Payara: Let’s Encrypt

About Mihai Andronache

Mihai is an experienced Java and JavaEE developer. His main interests are: clean OOP, code maintainability and testing. He is the creator of http://comdor.co and http://charles.amihaiemil.com"

Apache Payara: Let’s Encrypt

Some time ago, I wrote a small tutorial on how you can generate Let’s Encrypt SSL certificates and install them on your Glassfish Java EE Platform. That trick worked wonders for me but having to manually renew and reinstall the certificates every three months became quite annoying.

I did a little research and, same as the first tutorial, this one is basically a summary of my findings. Before anything, I should mention Mr. Daschner who explained to me how HTTPS is usually handled in the Java EE world – many thanks!

Apache Payara

Long story short: Payara, Glassfish, JBoss and others all have some differences in the way they handle HTTPS so, Mr. Dachner said, the sane way to do it is to let them work via HTTP behind the scenes and let an Apache HTTP Server actually communicate with the users, acting as a Reverse Proxy, forwarding all requests to/from the hidden Java EE Platform.

First things first, download Payara or other server of your choice, install and run it with the default configuration. By default, it should listen on port 8080. No need to do anything further.

Then, install Apache as explained here and in the file /etc/apache2/sites-available/example.com.conf, specify the following (the file is example.com.conf as in the linked article):

<VirtualHost *:80>
    ProxyPass /
    ProxyPassReverse /

    ProxyPass /myapp
    ProxyPassReverse /myapp

After saving the changes, don’t forget to reload Apache, so it reads the new config:

sudo systemctl reload apache2

Now instruct your firewall to expose port 80 for incoming connections (this is probably already configured) and you have are half done. So far, you have a running Apache server which will forward all requests made to www.example.com and www.example.com/myapp to the internal Payara.

To enable SSL via Let’s Encrypt, just follow the steps described here and don’t forget to press 2 when the following message appears from certbot:

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Pressing 2 will instruct certbot to automatically configure Apache so it redirects all HTTP traffic to HTTPS. This is very convenient since http:// links are still widely spread so it only makes sense to redirect the user to the secure alternative.

This is it, now everything should work via HTTPS and you should always see the green lock in your browser when accessing your Java EE apps via www.example.com. The only thing that I do not like is the fact that, apparently, we have to specify each context root (i.e. /myapp) in Apache’s config file. This seems very inconvenient, so I asked StackOverflow how we can avoid having to do this – if you happen to know please, go ahead and post an answer!

Published on Java Code Geeks with permission by MIhai Andronache, partner at our JCG program. See the original article here: Apache. Payara. Let’s Encrypt.

Opinions expressed by Java Code Geeks contributors are their own.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Markus Karg
11 months ago

This pattern introduces a security leak which might be problematic wrt to GDPR: Private data passed through this chain can be read in clear text using Wireshark between the actual application server and the encryption wrapper. Hence it is a rather bad idea to not use HTTPS directly on the original application server already.