Integrated TLS Certificate Management is the first feature added to Payara Server Enterprise (coming soon!) since the Payara Platform was split into Payara Community and Payara Enterprise Editions.
Generating Self-Signed Certificates
The intent behind this command is to give you a quick way to generate a new self-signed certificate for use with any of your instances or specific HTTP / IIOP listeners. In its first showing, the command allows you to specify a distinguished name, any additional subject alternative names, and an alias. You don’t need to provide the path to the key or trust store yourself – the command takes the target instance name (defaulting to the DAS if unspecified) and determines from its config where the key and trust store locations are. In addition to an instance name, you can also provide a listener name if you have HTTP or IIOP listeners configured to use a custom key or trust store.
If targeting an instance that isn’t the DAS, we first check to see if you’re using the default key and trust stores before generating a new self-signed certificate for the instance. The reason for this is because any changes made to these default stores will be overwritten with the current state of the DAS’ stores upon next instance synchronisation. In these cases, the command simply warns you of this, and performs a synchronisation (under the assumption that you’ve already generated a self-signed certificate for the DAS).
asadmin generate-self-signed-certificate --dn “CN=test.payara.fish” --alternativenames “DNS=test1.payara.fish,IP=127.0.0.1;DNS=test2.payara.fish” test_cert
asadmin generate-self-signed-certificate --dn “CN=test3.payara.fish” --alternativenames “test4.payara.fish” --listener http-listener-2 test_cert2
asadmin generate-self-signed-certificate --dn “CN=test4.payara.fish” --target Insty1 --listener http-listener-2 test_cert3
Generating a Certificate Signing Request
For if you wish to get your self-signed certificate signed by a Certificate Authority, we’ve added a command to generate a CSR. Similar to the command above, you provide an instance name, listener name, and an alias name, and Payara Server will generate the CSR from the key entry in that instance’s key store. The resultant CSR file will be output to payara5/glassfish/tls, and will mirror the alias name (e.g. payara5/glassfish/tls/test_cert3.csr).
asadmin generate-csr test_cert
asadmin generate-csr --listener http-listener-2 test_cert2
asadmin generate-csr --target Insty1 --listener http-listener-2 test_cert3
Your chosen CA should be providing you instructions on how to use their services, but generally they will ask you to upload this CSR and will then return to you a signed certificate.
Add or Removing Certificates
This set of commands are to add or remove certificates (.cert) and certificate bundles (.p12 or .jks) from the key and trust stores. Once again, the commands request that you provide a target instance and/or listener name and will determine the key or trust store for you, syncing with the DAS and warning you if targeting an instance with default stores.
For these commands, we elected to split up adding and removing from the key and trust stores into separate commands to give you more control.
asadmin add-to-keystore --file /path/to/mycert.p12 test_cert
asadmin add-to-truststore --file /path/to/file.cert test_cert2
asadmin add-to-keystore --file /path/to/mycert.jks --target Insty1 test_cert3
asadmin add-to-truststore --file /path/to/mycert.jks --target Insty1 --listener http-listener-2 test_cert3
Removing Expired Certificates
While we make efforts to ensure that there are no expired certificates in the Payara key and trust stores before shipping a release, this doesn’t stop them from expiring once in your own hands. This command is a convenience method to simply remove all expired certificates from the key and trust stores to stop the server log being filled with expired cert warnings.
Just as with the other commands, this command accepts an instance and listener name as the target, and will instead attempt to sync with the DAS if either are the key or trust stores are configured to their default values.
asadmin remove-expired-certificates
asadmin remove-expired-certificates --target --listener http-listener-2
Final Words
We hope you can see where we’re going with this – providing the tools to more easily manage your certificates in a fully-integrated way with Payara Server, rather than asking you to rely on keytool or other utilities.
This feature is bundled by default in with Payara Enterprise (request your trial download here), so should be good to go straight out of the box. Payara Community Edition users will need to build and drop it in themselves.
We’re going to look at continuing to provide additional functionality to this feature set in the upcoming releases, and as always, we welcome any feedback you have.
{{cta(’34d3a46c-2d44-4544-aa7f-1d0cc48d2cb3′)}}
3 minutes
