Installing a certificate in Glassfish v4 without storing password in config files

I have a wildcard certificate I want to install in a Glassfish v4 server. After converting certificate format and importing it to java keystore (using commands already discussed in other topics) we have to configure file domain.xml to include a password for JKS. Something like:

<jvm-options>-Djavax.net.ssl.keyStore=/myappdir/keystore.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStorePassword=changeit</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=/myappdir/cacerts.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStorePassword=changeit</jvm-options>
<jvm-options>-Djavax.net.ssl.keyAlias=myapp-cert</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStoreAlias=myapp-cert</jvm-options>
<jvm-options>-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=myapp-cert</jvm-options>

The problem here is that a password for JKS must be inserted into file domain.xml (see -Djavax.net.ssl.trustStorePassword=changeit), which I think is not a good deal for security reasons.

Does anyone knows a better way of importing a certificate to glassfish v4 without storing the password into configuration files?

In general, you can avoid storing sensitive data in the domain.xml using an alias.

For example, assuming I have a DB password of "secretDBpassword" for a production database used for "myApp" I could do the following:

Create a password alias:

asadmin> create-password-alias myApp-production-db
Please enter the alias password>   // enter secretDBpassword
Please enter the alias password again>  // enter secretDBpassword
Command create-password-alias executed successfully.

Set the value of the password property to:

${ALIAS=myApp-production-db}

This doesn't have to be used for passwords. Any string can be stored as an alias.

In your case, however, we're talking about the password used for the keystore and truststore. This is the Master Password and can be set with an asadmin command:

asadmin> change-master-password

Documentation for change-master-password

As you noted in your example, the default is changeit, which is well known, so it is a good idea to "change it"!

Using the master password in this way will avoid the need for specifying any password in JVM options or anywhere in the domain.xml.