Java Reference
In-Depth Information
This will create a new certificate request named
certreq.csr
, bearing the following
format:
-----BEGIN NEW CERTIFICATE REQUEST-----
. . . . . .
-----END NEW CERTIFICATE REQUEST-----
The previous certificate needs to be transmitted to the CA. At the end of the enrollment
phase, the CA will return a signed certificate, which needs to be imported into your key-
chain. The following code assumes you saved your CA certificate in a file named
signed_ca.txt
:
keytool -import -keystore jboss.keystore -alias testkey1
-storepass mypassword -keypass mypassword -file
signed_ca.txt
Now, your web browser will recognize your new certificate as being signed by a CA, so it
won't complain about not being able to validate the certificate.
Securing EJB communication
EJB clients interact with the Enterprise EJB tier using the RMI-IIOP protocol. The RMI-
IIOP protocol has been developed by Sun to combine the RMI programming model with
the IIOP underlying transport.
Securing the EJB transport is required for applications that have strict secure policies,
which cannot be carried out using clear text transmission. In order to do this, we need to
be sure to complete the following steps:
1. First, generate the SSL certificates and then store the client's public key in the
server's
keystore
object and the server's public key on the client's
trust-
store;
we've already done this in order to prepare our HTTPS connector.
2. Next, we need to create an SSL-aware security realm, which will be used by the
remoting
transport. We can use the one created for the HTTPS communication.
3. Finally, we need to apply some changes to our EJB application so that it actually
uses the SSL secure channel. We will cover this in the next subsection.
