SupportConsoleDevelopersStart a trialContact

Chapter 15. Securing the EJB RMI transport layer

JBoss Application Server uses a socket-based invoker layer for Remote Method Invocation (RMI) of EJB2 and EJB3 Beans. This network traffic is not encrypted by default. Follow the instructions in this chapter to use Secure Sockets Layer (SSL) to encrypt this network traffic.
Transport options for EJB3 via SSL

This chapter describes configuration of two different arrangements for Remote Method Invocation of EJB3s over an encrypted transport: RMI + SSL and RMI via HTTPS. HTTPS is an option as the transport for RMI when firewall configuration prevents use of the RMI ports.

Generating a key pair for SSL is covered in Section 15.2, “Generate encryption keys and certificate” .
Configuring RMI + SSL for EJB3 is covered in Section 15.3, “EJB3 RMI + SSL Configuration” .
Configuring RMI via HTTPS for EJB3 is covered in Section 15.4, “EJB3 RMI via HTTPS Configuration” .
Configuring RMI + SLL for EJB2 is covered in Section 15.5, “EJB2 RMI + SSL Configuration” .

15.1. SSL Encryption overview

15.1.1. Key pairs and Certificates

Secure Sockets Layer (SSL) encrypts network traffic between two systems. Traffic between the two systems is encrypted using a two-way key, generated during the handshake phase of the connection and known only by those two systems.
For secure exchange of the two-way encryption key, SSL makes use of Public Key Infrastructure (PKI), a method of encryption that utilizes a key pair . A key pair consists of two separate but matching cryptographic keys - a public key and a private key. The public key is shared with others and is used to encrypt data, and the private key is kept secret and is used to decrypt data that has been encrypted using the public key.
When a client requests a secure connection, a handshake phase takes place before secure communication can begin. During the SSL handshake the server passes its public key to the client in the form of a certificate. The certificate contains the identity of the server (its URL), the public key of the server, and a digital signature that validates the certificate. The client then validates the certificate and makes a decision about whether the certificate is trusted or not. If the certificate is trusted, the client generates the two-way encryption key for the SSL connection, encrypts it using the public key of the server, and sends it back to the server. The server decrypts the two-way encryption key, using its private key, and further communication between the two machines over this connection is encrypted using the two-way encryption key.
On the server, public/private key pairs are stored in a key store , an encrypted file that stores key pairs and trusted certificates. Each key pair within the key store is identified by an alias - a unique name that is used when storing or requesting a key pair from the key store. The public key is distributed to clients in the form of a certificate , a digital signature which binds together a public key and an identity. On the client, certificates of known validity are kept in the default key store known as a trust store .
CA-signed and self-signed certificates

Public Key Infrastructure relies on a chain of trust to establish the credentials of unknown machines. The use of public keys not only encrypts traffic between machines, but also functions to establish the identity of the machine at the other end of a network connection. A "Web of Trust" is used to verify the identity of servers. A server may be unknown to you, but if its public key is signed by someone that you trust, you extend that trust to the server. Certificate Authorities are commercial entities who verify the identity of customers and issue them signed certificates. The JDK includes a cacerts file with the certificates of several trusted Certificate Authorities (CAs). Any keys signed by these CAs are automatically trusted. Large organizations may have their own internal Certificate Authority, for example using Red Hat Certificate System. In this case the signing certificate of the internal Certificate Authority is typically installed on clients as part of a Corporate Standard Build, and then all certificates signed with that certificate are trusted. CA-signed certificates are best practice for production scenarios.

During development and testing, or for small-scale or internal-only production scenarios, you may use a self-signed certificate . This is certificate that is not signed by a Certificate Authority, but rather with a locally generated certificate. Since a locally generated certificate is not in the cacerts file of clients, you need to export a certificate for that key on the server, and import that certificate on any client that connects via SSL.
The JDK includes keytool , a command line tool for generating key pairs and certificates. The certificates generated by keytool can be sent for signing by a CA or can be distributed to clients as a self-signed certificate.
  • Generating a self-signed certificate for development use and importing that certificate to a client is described in Section 15.2.1, “Generate a self-signed certificate with keytool” .
  • Generating a certificate and having it signed by a CA for production use is beyond the scope of this edition. Refer to the man page for keytool for further information on performing this task.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.