Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Capítulo 15. Proteção da camada de transporte EJB RMI

O Servidor do Aplicativo JBoss usa uma camada do invocador baseado no soquete para a Invocação do Método Remoto - Remote Method Invocation (RMI) do EJB2 e EJB3 Beans. Este tráfego de rede não é criptografado por padrão. Siga as instruções deste capítulo para uso da Camada de Soquetes de Segurança - Secure Sockets Layer (SSL)
Opções de transporte para o EJB3 através do SSL

Este capítulo descreve a configuração de dois planos diferentes para o RMI dos EJB3s sobre um transporte criptografado: RMI + SSL e RMI através dos HTTPS. O HTTPS é uma opção de transporte para o RMI quando a configuração do firewall previne o uso das portas RMI.

Maiores informações referentes a geração de um par chave para o SSL podem ser encontradas na Seção 15.2, “Geração de chaves de criptografia e certificado”.
Informações sobre a configuração do RMI + SSL podem ser encontradas na Seção 15.3, “Configuração EJB3 RMI + SSL”.
Informações referentes ao RMI através do HTTPS para o EJB3 estão descritas na Seção 15.4, “EJB3 RMI através da Configuração HTTPS”.
Informações sobre o RMI + SLL para o EJB2 podem ser encontradas na Seção 15.5, “Configuração EJB2 RMI + SSL”.

15.1. Visão Geral de Criptografia do SSL
Copiar o link

15.1.1. Pares Chaves e Certificados
Copiar o link

O (SSL) encripta o tráfego de rede entre os dois sistemas. O tráfego entre dois sistemas é encriptado usando uma chave bidirecional, gerada durante a fase handshake da conexão e conhecida por estes dois sistemas.
Para a troca de segurança de uma chave de criptografia bidirecional, o SSL usa uma Infra-estrutura de Chave Pública - Public Key Infrastructure (PKI), um método de criptografia que usa um key pair. Um par chave consiste de duas chaves criptografadas separadas, porém coincidentes: a chave pública e a chave privada. A chave pública é compartilhada com outros e é usada para criptografar dados, enquanto que a chave privada é secreta e usada para descriptografar dados que já foram criptografados usando a chave pública.
Quando o cliente solicita a conexão de segurança, uma fase handshake entra em ação antes da comunicação de segurança possa começar. Durante o SSL handshake, o servidor passa a chave pública ao cliente na forma de um certificado. O certificado contém a identidade de um servidor (seu URL), a chave pública e uma assinatura digital que valida o certificado. Em seguida, o cliente valida o certificado e decide se o certificado é confiável ou não. Caso o certificado seja confiável, o cliente gera uma chave de criptografia bidirecional para a conexão SSL, encripta-a usando a chave pública e a envia de volta ao servidor. O servidor decripta a chave de criptografia bidirecional, usando sua própria chave privada e comunicação futura entre as duas máquinas sobre esta conexão é encriptada usando a chave de criptografia bidirecional.
No lado do servidor, os pares de chave privada/pública são armazenados num key store, um arquivo encriptado que armazena os pares de chave e os certificados confiáveis. Cada par de chave com o armazenamento de chave é identificado por um alias - um nome único que é usado no armazenamento ou solicitação de um par chave do armazenamento chave. A chave pública está distribuída aos clientes na forma de um certificate, uma assinatura digital que aplica o bind juntamente com uma chave pública e uma identidade. No lado do cliente, os certificados da validação conhecida são mantidos no armazenamento de chave padrão conhecido como um trust store.
Certificados de auto-assinatura e assinatura CA

A Infra-estrutura da Chave Pública depende de uma corrente de confiança para estabelecer as credenciais de máquinas desconhecidas. O uso de chaves públicas não encripta apenas o tráfego entre máquinas, mas também trabalha para estabelecer a identidade da máquina de outra parte da conexão de rede. Uma "Confiança da Web" é usada para verificar a identidade dos servidores. Você pode desconhecer um servidor, mas caso sua chave pública é assinada por alguém de sua confiança, você estende aquela confiança ao servidor. As Autoridades de Certificado são entidades comerciais que verificam a identidade de clientes e emitem isto como certificados assinados. O JDK inclui um arquivo cacerts com os certificados de diversas Autoridades de Certificado - Certificate Authorities (CAs). Quaisquer chaves assinadas por estes CAs são automaticamente confiáveis. Neste caso, o certificado assinado da Autoridade de Certificado interna é normalmente instalada em clientes como parte da Construção Padrão Empresarial e todos os certificados assinados com aquele certificado serão confiáveis. Os certificados assinados CA são a melhor prática para cenários de produção.

Durante o desenvolvimento e teste, ou para cenários de produção interna apenas ou de escala menor, você pode usar um self-signed certificate. Este é um certificado que não é assinado pela Autoridade de Certificado, mas sim um certificado gerado localmente. Uma vez que o certificado gerado localmente não está no arquivo cacerts dos clientes, você precisa expor um certificado para aquela chave no servidor e importar aquele certificado em qualquer cliente que conecta-se através do SSL.
O JDK inclui keytool, uma ferramenta de linha de comando para geração de pares chaves e certificados. Os certificados gerados pelo keytool podem ser enviados para assinatura do CA ou podem ser distribuídos aos clientes como um certificado de auto-assinatura.
  • Maiores informações sobre a geração de um certificado de auto-assinatura para uso de desenvolvimento e importação do mesmo certificado podem ser encontradas na Seção 15.2.1, “Geração de um certificado auto-assinado com o keytool”.
  • A geração de um certificado e possuir o mesmo assinado por um CA para uso de produção vai além do descrito nesta edição. Por favor refira-se ao manpage em keytool para maiores informações sobre a execução desta tarefa.
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat