These instructions were written for Ubuntu 16, but they should translate quite easily to other flavours of *nix, relatively easily for macOS, and with only small tweaks for Windows. Probably.

Apache

Renewing the Apache portion of the certificate is fairly easy – Let’s Encrypt’s certbot can handle that for you. In my case, I’d not renewed since the certbot was brought in, so a bit of installation was required.

Installing certbot

I have some locale settings issues on my box. I’m not certain if that’s because I mucked something up or there’s some weird defaults, but I need to manually set the locale before a lot of things. Yes, I should really stick it into a startup script, but I tend to forget about it the moment I’m done with it. Perhaps after this article.

In any case, to set some locale settings so that install will work, enter

To install the certbot from scratch, I followed the instructions here. I’ll repeat the easy parts below, and include parts on renewal, but you should read through that article for a more in-depth treatment and your initial certificate generation. Note that some of these commands require sudo access, so it might be easier to paste them in one at a time – at least for the first one, so that you can type in your password. I didn’t do that, and it was relatively exciting afterwards.

Not bad, just relatively exciting. Anyways, to install certbot:

Now that certbot is (hopefully) installed, we need to ask it to renew our certificate. If you’re setting up an initial certificate, see this link again. To renew the certificate, just issue a command like

Many many status messages will scroll down, finishing with something like (for an Apache setup)

With YOURDOMAIN  replaced with your actual domain, obviously.

WildFly

Next up, we need to get the public and private keys into Wildfly. Apache was setup with the public and private keys pointed to separately, but Wildfly (well, Java) works off of a keystore. What we’re going to do is generate a new keystore that contains your new private and public keys, as read off of the  /etc/letsencrypt/live/YOURDOMAIN/fullchain.pem file that certbot generated earlier.

Converting the PEM file

To do this, we need to convert the PEM file into a P12 file that is readable by the keytool. This is accomplished by issuing the OpenSSL command, after making suitable replacements.

The YOURDOMAIN replacement is the folder corresponding to the domain that you’re generating the key for, and was present in the listed output from the previous step. The KEYSTORENAME will become part of the generated file name, and will be used in the WildFly configuration, as will the KEYSTOREALIAS. These can be anything of your choice. Once you’ve pressed enter, you’ll be prompted (and verified) for a new password. This new password will be used in a moment when we generate the keystore.

You may not need the sudo part of the command, but you more likely will as people shouldn’t generally have read permissions to the various keys.

Generating the keystore

Once the certificate has been converted, we need to produce the keystore. This again is a one-liner with some substitutions:

There are a couple of substitutions here – new ones are a password for the keystore, a password for the key within the keystore, and the name of the resulting keystore. The other substitutions are either from the previous step, or from the password created as part of the previous step.

This will result in a keystore with your chosen name being generated in your current folder. You can copy this to your WildFly’s configuration folder, e.g.

WildFly configuration

Finally, we need to add the keystore to WildFly. There are many posts detailing how to set up SSL for WildFly, and this is really more focused on renewing certificates, so we’ll check just that. Find the <security-realms> section, and specifically the one you’re setting up – Undertow in my case.

Update your <ssl> tag as

Reboot WildFly with

And you’re all done. For a coupla months.