tion services, using digital signatures. It also allows users to cache the public keys (in the
form of certificates) of their communicating peers.
The keytool stores the keys and certificates in a file termed keystore, a repository of certi-
ficates used to identify a client or server. Typically, a keystore contains a client or server's
identity, which is protected by a password. Let's see an example of the keystore genera-
keytool -genkey -keystore wildfly.keystore -storepass
mypassword -keypass mypassword -keyalg RSA -validity 180
-alias wflyalias -dname "cn=John Smith,o=PackPub,c=GB"
This command creates the keystore named wildfly.keystore in the working direct-
ory, and assigns it the password mypassword . It generates a public/private key pair for
the entity whose unique name has the common name John Smith , organization Pack-
tPub , and two-letter country code GB .
The result of this action will be a self-signed certificate (using the RSA signature al-
gorithm), which includes the public key and the unique name. This certificate will be val-
id for 180 days, and is associated with the private key in a keystore entry referred to by
the alias wflyalias .
A self-signed certificate is a certificate that has not been verified by a CA and thus, leaves
you vulnerable to the classic man-in-the-middle attack. A self-signed certificate is only
suitable for in-house use or for testing while you wait for your real certificate to arrive.
Securing the HTTP communication with a self-signed certificate
Now let's see how you can use this keystore file to secure your WildFly web channel.
Open your server configuration file and locate the web subsystem.
Within the web subsystem, you have to first change the default http-listener and
socket-binding to https-listener and "https" , and add the security-
realm element to it. Next, you have to insert an ssl stanza within it, which contains
the details of your keystore object (in our example, we dropped the file
jboss.keystore into the server configuration directory):