JBoss AS 5

Linux e JBoss: Seja Cuidadoso!

Postado em

E ai Galera blz?

Esse post é mais uma dica do que um tutorial.

Em hipótese alguma inicie o JBoss utilizando o usuário root, pois a plataforma Java oferece APIs para execução de códigos nativos do sistema operacional e mecanismos de gerenciamento remoto. No Linux crie um usuário com privilégios adequados para iniciar o serviço do JBoss.

Se quiser ver com isso tudo pode prejudicar o seu ambiente. Pegue a aplicação filebrowser e faça um deploy no JBoss.

Primeiro execute o JBoss utilizando um usuário com privilégios reduzidos e brinque com algumas funcionalidade da aplicação filebrowser.

Agora execute o JBoss com o usuário root e teste novamente o filebrowser. Perceba que com uma aplicação web escrita em Java você pode ser capaz de invadir até uma rede ser as permissões estiverem no nível de root.

Abraços

App: http://www.vonloesch.de/filebrowser.html

 

Slimming descomplicado no AS 5

Postado em

Olá, pessoal!

Hoje vou promover um pouco o projeto rboss apresentando a funcionalidade de slimming no JBoss AS 5 (e EAP 5 também).

Para quem ainda não sabe, o slimming significa retirar recursos que não são utilizados. Isso acelera muito o tempo de startup do JBoss e, de quebra, diminui o consumo de memória.

Pré-requisitos

Obviamente que precisamos do rboss instalado. Você pode conferir aqui como instalá-lo.

Removendo os recursos

A funcionalidade foi baseada na documentação sobre slimming disponível na wiki.

A remoção dos recursos é feita renomeando os arquivos e diretórios para a extensão “.rej”. Basta entrar no diretório do profile e executar o seguinte comando:

$ rboss-profile --this --slim [recursos]

Abaixo segue o que pode ser removido e o respectivo parâmetro.

  • Admin Console – admin-console
  • Web Console – web-console
  • Mail Service – mail
  • BeanShell – bean-shell
  • Hot Deploy – hot-deploy
  • UDDI – uddi
  • UUID Key Generator – key-generator
  • Scheduling – scheduling
  • JMX Console – jmx-console
  • JBoss WS – jboss-ws
  • JMX Remoting – jmx-remoting
  • ROOT Page – root-page
  • Management – management
  • IIOP – iiop
  • JBoss Web – jboss-web
  • SNMP – snmp
  • Profile Service – profile
  • EJB3 – ejb3
  • EJB2 – ejb2
  • JMX Invoker – jmx-invoker
  • HA HTTP Invoker – ha-http-invoker
  • Legacy Invoker – legacy-invoker
  • Transaction – transaction
  • Remoting – remoting
  • Properties Service – properties
  • Database/Datasource – database
  • JSR-88 – jsr87
  • XNIO – xnio

Os parâmetros devem ser separados por vírgulas. Se você desejar remover o JMX Console e o Hot Deploy, por exemplo, basta digitar:

rboss-profile --this --slim jmx-console,hot-deploy

Para ver o que foi “removido” (lembre-se de que se trata de uma remoção lógica), use o comando com o parâmetro “-v”.

Se precisar restaurar os recursos removidos, use –restore no lugar de –slim. O comando acima ficaria, dessa forma, assim:

rboss-profile --this --restore jmx-console,hot-deploy

Um abraço a todos!

Simulando Logs no JBoss usando twiddle

Postado em

Neste post farei um jogo rápido sobre como simular logs no JBoss usando twiddle e como isso pode ser útil apresentando dois exemplos práticos.

Basicamente, podemos criar um aplicativo qualquer que use o componente de log do JBoss e receba um input com a mensagem, a categoria e a severidade. Algo bem simples e que pode muito bem ser feito como um aplicativo web, mas, como eu sou fã de linha de comando, vou mostrar como fazer isso usando o twiddle.

Pra quem não sabe, o twiddle é uma forma de acessarmos o JMX do JBoss via linha de comando (pra quem já usou o jmx-console, é praticamente a versão linha de comando dele). A ideia é criar um serviço no JBoss que possa ser utilizado pelo twiddle (e pelo jmx-console, claro). Para tal, precisamos seguir alguns passos:

  1. Criar uma interface com a anotação @org.jboss.ejb3.annotation.Management
  2. Criar a implementação com a anotação @org.jboss.ejb3.annotation.Service
  3. Empacotar tudo e fazer o deploy na instância do JBoss em questão

Como não é o escopo deste post mostrar como criar o serviço e, sim, como utilizá-lo, você pode baixar os fontes no meu github e compilar o projeto (basta usar o ant pra isso e pegar o jar em out/artifacts/jmx-logger.jar).

Assumindo que o jmx-logger.jar esteja no seu JBoss, você pode mandar qualquer mensagem de log usando as severidades do JBoss (trace, debug, info, warn, error e fatal) como o nome do método e os seguintes parâmetros (todos são Strings):

  • mensagem
  • categoria, mensagem
  • categoria, mensagem, exceção

O grande barato é que você pode usar qualquer classe de exceção, mesmo que ela não exista (nesse caso ela será criada em tempo de execução usando o Javassist). Abaixo seguem alguns exemplos de uso:

# simula um warn com a mensagem "atencao"
$ twiddle.sh invoke jboss.system:service=Logging,type=Logger warn atencao

# simula um OutOfMemoryError com a mensagem "heap space" na categoria "org.minhaclasse"
$ twiddle.sh invoke jboss.system:service=Logging,type=Logger error org.minhaclasse "heap space" java.lang.OutOfMemoryError

Você deve estar se perguntando “Tá, mas e onde eu vou usar isso?”. Mostrarei dois exemplos bem interessantes.

Testar configurações de log

Configurar o log pode parecer simples, mas existem casos onde as saídas precisam ser diferentes para cada aplicativo, sqls devem ser gravados em arquivos diferentes e outros casos onde precisamos da aplicação no ar para testar as configurações. Usando um serviço desses, podemos simular os logs das aplicações facilmente e ver se tudo está ok antes mesmo de subir a aplicação. Também podemos testar outras configurações de log sem termos as aplicações no JBoss. É uma excelente carta na manga!

Simular alertas no RHQ

Podemos trabalhar com alertas no RHQ para que, quando uma determinada mensagem for pega no log, uma ação seja disparada. Um exemplo clássico é o OutOfMemory. Podemos criar os alertas e simulá-los usando o serviço jmx-logger. Outra aplicação legal é usar em demonstrações do JOPR pra equipes ou clientes.

Eu sempre usei esse serviço no JBoss 5, mas acredito que seja compatível com o JBoss 6. Já coloquei um TODO pra tornar compatível com o JBoss 7 usando o jboss-cli. Falta só o tempo pra isso 🙂

Introdução ao PicketLink

Postado em

Sei que já dei uma “introdução” ao PicketLink, mas dessa vez vou fazer um post mais detalhando,  portanto vamos lá :

PicketLink é uma solução de IDM que está sendo construida para antender a plataform JBoss. Identity Management (IDM) descreve o gerenciamento de identidades individuais, sua autenticação, autorização e privilégios/permissões dentro de um contexto de segurança.

Exemplos de IDMs concorrentes do PicketLink:

http://www-01.ibm.com/software/tivoli/products/identity-mgr/
http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.htm

Uma das perguntas mais frequentes e que até eu mesmo me fazia antes de conheçer o PicketLink mais a fundo é: Qual é a referência entre o PicketLink e o PicketBox?

Picketbox (implementa o JAAS) é API que sustenta quaquer implementação de segurança dentro do JBoss Application Server (JBoss AS). O PicketLink está em cima dessa camada e visa fornecer diversas soluções para gerenciamento de identidade.

O PicketLink agrupa vários projetos por exemplo:

  • IDM: Provide an object model for managing Identities (Users/Groups/Roles) and associated behavior using different identity store backends like LDAP and RDBMS.
  • Federated Identity:  Support SAMLv2, WS-Trust and OpenID.
  • AuthZ: Developer friendly authorization framework
  • XACML:  Oasis XACMLv2 implementation.
  • Negotiation: Provide SPNego/Kerberos based Desktop SSO.

Mais informações podem ser encontradas na página do projeto: http://www.jboss.org/picketlink .

PicketLink Federation (PicketLink Federated Identity)

O projeto PicketLink Federation fornece suporte para Federated Identity e Single Sign On.

É oferecido suporte para as seguintes especificações:

Oasis SAML v2.0
Oasis SAML v1.1
Oasis WS-Trust v1.3
OpenID

Planeja-se suporte para:

OAuth

Para utilizarmos o PicketLink Federation devemos entender alguns conceitos de SAML v2.0.

O que é o SAML?

È um padrão para troca de informações de autorização de usuário pela web de uma forma interoperável(xml). O objetivo é que o usuário se autentique em algum lugar e receba um token (identidade), e com esse token ele consiga acessar qualquer recurso que esteja dentro do contexto de segurança onde o token foi emitido.

Nesse contexto podemos destacar as duas entidades: Identity Provider(IDP) e Service Provider(SP).

A especificação SAML possui uma série de profiles, que funcionam como se fossem casos de uso. Por exemplo um dos profiles que vamos abordar nesse post será o Web Browser SSO Profile, que define um caso de uso para SSO utilizando o browser. Para mais informações sobre os profiles do SAML veja o link abaixo:

http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

O próximo conceito a ser entendido é o SAML protocol binding, que são mapeamentos (canais) padrões para trocas de mensagens SAML entre o IDP e o SP.
Por exemplo no profile(caso de uso) Web Browser SSO é utilizado o HTTP Binding, então toda a troca de informações entre IDP e SP será realizada utilizando HTTP Binding. Existem também outros bindings como SAML SOAP Binding ou Reverse SOAP (PAOS) Binding. Para mais informações sobre o SAML protocol binding veja o link abaixo:

http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

Finalmente chegamos ás assertions que são as informações de autenticação e alguns atributos do contexto de segurança.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
http://saml.xml.org/assertions

A parte sobre Authentication Context e Metadata ainda não está totalmente implementada.

 

Ps: Eu vou continuar editando esse post e colocando mais informações (ultimo update  30/06/12)

Encrypt Keystore Password no JBoss AS 6.1 / 5.1

Postado em Atualizado em

Olá a todos 😀

Hoje vamos aprender como encriptar a senha do keystore/certificado que fica configurado no connector HTTPs no server.xml do JBoss. Em configurações normais quando habilitamos o HTTPs configuramos a caminho e password dos certificados em texto puro no connector mas essa não é um boa pŕatica, veja abaixo:

<Connector protocol="HTTP/1.1" SSLEnabled="true"
    port="${jboss.web.https.port}" address="${jboss.bind.address}"
    scheme="https" secure="true" clientAuth="false"
    keystoreFile="${jboss.server.home.dir}/conf/example.keystore"
    keystorePass="changeit" sslProtocol = "TLS" />

Se você quiser encriptar a senha da keystore então a sintaxe acima não é necessária. A sintaxe correta seria:

<Connector port="${jboss.web.https.port}" address="${jboss.bind.address}"
   maxThreads="100" minSpareThreads="5" maxSpareThreads="15"
   scheme="https" secure="true" clientAuth="false"
   sslProtocol="TLS"
   securityDomain="java:/jaas/encrypt-keystore-password"
   SSLImplementation="org.jboss.net.ssl.JBossImplementation" >
</Connector>

O próximo passo é configurar MBean JaasSecurityDomain. Você precisa criar o arquivo JBOSS_HOME/server//deploy/security-service.xml e adicionar o conteúdo abaixo:

<server>
   <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
      name="jboss.security:service=PBESecurityDomain">
      <constructor>
         <arg type="java.lang.String" value="encrypt-keystore-password"></arg>
      </constructor>
      <attribute name="KeyStoreURL">resource:example.keystore</attribute>
      <attribute name="KeyStorePass">{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/keystore.password</attribute>
      <attribute name="Salt">mysaltmagnani</attribute>
      <attribute name="IterationCount">13</attribute>
      <!--
        <attribute name="KeyStoreType">pkcs12</attribute>
       -->
   </mbean>
</server>

Você pode alterar o valor de salt e iterationCount conforme a sua necessidade.

O próximo passo é criar o arquivo de senha. Execute o seguinte comando:

[mmagnani@dhcp-32 conf]$ pwd
/home/mmagnani/WorkSpace/jboss-org/jboss-6.1.0.Final/server/blog/conf
[mmagnani@dhcp-32 conf]$ java -cp ../../../lib/jbosssx.jar org.jboss.security.plugins.FilePassword mysaltmagnani 13 password keystore.password

O arquivo keystore.password foi criado.

Agora para finalizar temos que dizer ao container web para iniciar serviço PBESecurityDomain(security-service.xml) que havíamos criado.

Edite o arquivo JBOSS_HOME/server//deploy/jbossweb.sar/META-INF/jboss-beans.xml e adicione PBESecurityDomain abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">

   <bean name="WebServer"
         class="org.jboss.web.tomcat.service.deployers.TomcatService">

     ....

       <depends>jboss.security:service=PBESecurityDomain</depends>

     ....

  </bean>
</deployment>

Inicie o JBoss e verifique se o HTTPs está funcionando corretamente. Para gerar o certificado eu utilizei o comando abaixo:

keytool -genkeypair -keystore example.keystore -storepass password -keypass password -keyalg RSA -validity 180 -alias example -dname "cn=Mauricio Magnani,o=Home,c=BR"

Espero que tenha ajudado, Abraços.

Como Utilizar o JBoss na porta 80

Postado em Atualizado em

Quando iniciei o meu aprendizado no JBoss tive muitas dúvidas e uma delas foi: Como posso rodar o JBoss na porta 80? Depois de algumas pesquisas observei que normalmente existem duas opções:

1 – Iniciar o JBoss como root

Isso não é recomendado em hipótese alguma.
Em sistemas operacionais Linux/Unix é necessário ser root para que as aplicações escutem em portas TCP / UDP abaixo de 1024.

2 – Utilizar o JBoss com o mod_jk, mod_proxy ou mod_cluster

Pode-se utilizar um proxy e redirecionar as requisições para JBoss. Essas soluções já foram abordadas em artigos anteriores.

Existem também alguns balanceadores como:

Na dúvida consulte uma pessoa experiente que possa indicar as melhores práticas.

Abraços

Blogs sobre JBoss em Português

Postado em Atualizado em

E ai galera blz? Eu sempre acompanho a comunidade JBoss em relação ao artigos, publicações, tutoriais, etc. Vou deixar abaixo a lista de alguns blogs de pessoas que estão fazendo ou fizeram um trabalho bem legal ajudando a comunidade:

Meus parabéns a todos acima. Com a ajuda de vocês a tecnologia JBoss cresce cada vez mais na nossa língua 🙂

Bom existem muitos brasileiros que contribuem com código, até alguns da lista acima mas tentei citar especificamente o pessoal que escreve artigos.

Acho legal também o trabalho do infoblogs que ajuda a divulgar as publicações e o blog da Caelum que sempre divulga as tecnologias JBoss.

Coloquei somente os que conheço… se esqueci de algum por favor me corrijam que eu adiciono nessa lista 🙂

Abraços e Obrigado a toda comunidade JBoss da língua Portuguesa.

Horário de Verão e JBoss

Postado em Atualizado em

Brincadeiras a parte isso é uma das coisas que podem gerar alguns contratempos nos ambientes de produção. Alguns vão dizer que esse post é um pouco atrasado pois já estamos no fim de Abril e o horário já voltou ao normal, mas para futuras consultas vou deixar aqui algumas dicas de como deixar o seu ambiente JBoss preparado para o horário de verão. Por default o JBoss utiliza hora da JVM que por suas vez asssume os valores configurados no timezone do sistema operacional.

Então ai vai a primeira dica: Deixe o seu timezone configurado corretamente, sei que pode parecer uma coisa bem primária mas já observei alguns ambientes em que simplesmente essas configurações não estavam de acordo com os requisitos necessários. Para informações sobre essa configuração no CentOS consulte a documentação.

A segunda dica é uma ferramenta da Sun/Oracle que realiza um teste e verifica se o timezone precisa ser atualizado, essa ferramente se chama Timezone Updater Tool ( tzupdater ), o download pode ser realizado no link abaixo:

http://www.oracle.com/technetwork/java/javase/downloads/tzupdater-download-513681.html

Para utilizar o tzupdater  execute:

 java -jar tzupdater.jar -t

Serão listadas todas as divergências que podem ocasionar problemas.

Para atualizar execute:

 java -jar tzupdater.jar -u

Realize o teste novamente, e verifique se foi corrigido.

A terceira e ultima dica é uma classe que a Sun / Oracle disponibiliza e que testa se o Java fará as mudanças de horário corretamente. Essa classe pode ser visualizada abaixo:


/*
* Timezone test to check that the new US 2007 DST rules have been
* picked up by the JRE. TimeZone used is the default one on OS.
* Sample result :
* $java DSTTest "11/04/2007 0:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 00:00:00 EDT 2007
* TimeZone tested : Eastern Daylight Time
* Your tested time is in daylight-savings time.
* $java DSTTest "11/04/2007 3:00 AM"
* JRE version : 1.4.2_13
* Sun Nov 04 03:00:00 EST 2007
* TimeZone tested : Eastern Standard Time
* Your tested time is not in daylight-savings time.
* $echo $TZ
* America/New_York
*
*/

import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;

public class DSTTest {
 private static final String DATE_FORMAT_PATTERN = "MM/dd/yyyy hh:mm a";

 public static void main(String[] args) {

 try {

   String ver = System.getProperty("java.version");
   String testDate = args[0]; // "11/04/2007 1:00 AM";

   SimpleDateFormat df = new SimpleDateFormat(DATE_FORMAT_PATTERN);
   Date currentDate = df.parse(testDate, new ParsePosition(0));
   System.out.println("JRE version : " + ver);
   System.out.println(currentDate);
   // Default timezone from the system is used.
   TimeZone tz = TimeZone.getDefault();
   // Could manually set the timezone above. e.g :
   //TimeZone tz = TimeZone.getTimeZone("America/New_York");
   System.out.println("TimeZone tested : " + tz.getDisplayName(tz.inDaylightTime(currentDate), TimeZone.LONG));
   boolean indaylight = tz.inDaylightTime(currentDate);
   System.out.println("Your tested time is " + (indaylight ? "in " : "not in ")  + "daylight-savings time.");
  } catch (Exception e) {
   System.out.println("Error encoutered. Please insure you supply a valid date format pattern.");
   System.out.println("Ensure you've quotes placed around the pattern!");
   System.out.println("e.g java DSTTest \"11/04/2007 1:00 AM\"");
  }
 }
}

Para testar compile e execute a classe passando os parâmetros abaixo:

java DSTTest "02/25/2012 10:59 PM"
java DSTTest "02/26/2012 00:01 AM"

Lembrando que o JBoss precisa ser reiniciado na mudança de horário de verão, para assumir as novas configurações.

Espero que ajude alguém 🙂

Abraços

Evitando Erros de Deploy no JBoss AS 5.1

Postado em Atualizado em

Um problema muito comum ao realizar deploy de arquivos no JBoss é que  o deployment scanner  pode tentar implantar a aplicação antes que ela tenha sido totalmente copiada para o diretório de implantação.

A primeira dica é bem simples: Evite realizar deploy de aplicações em máquinas remotas, uma alternativa seria copiar para um diretório local onde o JBoss esteja instalado e em seguida copiar esse arquivo para o diretório de implantação adequado. Eu mesmo por muitas vezes a alguns anos atrás tentava realizar o hot deploy de uma aplicação  WAR de 50 MB  e na época não entendia o por que dos erros. A causa raiz é que por padrão o deployment scanner percorre os diretório de deploy a cada 5 segundos em busca de novas aplicações, caso encontre automaticamente a aplicação é implantada mesmo que não tenha sido totalmente copiada ocasionando erros.

Observando esse cenário podemos escolher entre duas opções: Desabilitar o deployment scanner ou alterar o valor do “Scan Period” dos diretório de deploy.

Para alterar o Scan Period edite o arquivo:


jboss-5.1.0.GA\jboss-5.1.0.GA\server\<profile>\deploy\hdscanner-jboss-beans.xml

E altere o valor da propriedade:


<!-- Frequency in milliseconds to rescan the URLs for changes -->

<property name="scanPeriod">15000</property>

Para desabilitar deployment scanner simplesmente remova o arquivo:

jboss-5.1.0.GA\jboss-5.1.0.GA\server\<profile>\deploy\hdscanner-jboss-beans.xml

Espero que tenha ajudado.

Abraços

Fonte: https://community.jboss.org/wiki/TurnDeploymentScannerDown

Utilizando SSL e JDBC no JBoss AS 5.1

Postado em Atualizado em

Já precisei muitas vezes habilitar o connector HTTPs no JBoss para utilizar conexões seguras ( SSL ). Mas nunca havia utilizado em conexões JDBC e é sobre isso que vamos falar no post de hoje.

A primeira coisa a ser feita é verificar se o banco de dados utilizado fornece suporte a SSL. Para os nossos testes vamos utilizar o MySQL presumo que você já o tenha instalado.

Realize login no MySQL:

mysql -uroot -p123456

Verifique se o suporte ao SSL está habilitado:

mysql> show variables like "%ssl%";
 +---------------+----------+
 | Variable_name | Value    |
 +---------------+----------+
 | have_openssl  | DISABLED |
 | have_ssl      | DISABLED |
 | ssl_ca        |          |
 | ssl_capath    |          |
 | ssl_cert      |          |
 | ssl_cipher    |          |
 | ssl_key       |          |
 +---------------+----------+
 7 rows in set (0.00 sec)

Como podemos visualizar “DISABLED ” significa que o MySQL suporta SSL mas está desabilitado. Para mais informações execute:

mysql> \s
 --------------
 mysql  Ver 14.14 Distrib 5.1.61, for redhat-linux-gnu (x86_64) using readline 5.1

Connection id:          3
 Current database:
 Current user:           root@localhost
 SSL:                    Not in use
 Current pager:          stdout
 Using outfile:          ''
 Using delimiter:        ;
 Server version:         5.1.61 Source distribution
 Protocol version:       10
 Connection:             Localhost via UNIX socket
 Server characterset:    latin1
 Db     characterset:    latin1
 Client characterset:    latin1
 Conn.  characterset:    latin1
 UNIX socket:            /var/lib/mysql/mysql.sock
 Uptime:                 3 min 54 sec

Threads: 1  Questions: 10  Slow queries: 0  Opens: 15  Flush tables: 1  Open tables: 8  Queries per second avg: 0.42
 --------------

Crie o diretório mysql:

mkdir -p /etc/mysql

Entre no diretório /etc/mysql e execute os comandos abaixo para gerar o certificado:

openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Edite o arquivo de configuração do MySQL:

vim /etc/my.cnf

Adicione as informações do certificado:

[client]
 ssl-ca=/etc/mysql/ca-cert.pem
 ssl-cert=/etc/mysql/client-cert.pem
 ssl-key=/etc/mysql/client-key.pem

[mysqld]
 ssl-ca=/etc/mysql/ca-cert.pem
 ssl-cert=/etc/mysql/server-cert.pem
 ssl-key=/etc/mysql/server-key.pem

Restart o MySQL:

service mysqld restart

Realize login novamente no MySQL e verifique se o suporte ao SSL foi habilitado:

mysql> show variables like "%ssl%";
 +---------------+----------------------------+
 | Variable_name | Value                      |
 +---------------+----------------------------+
 | have_openssl  | YES                        |
 | have_ssl      | YES                        |
 | ssl_ca        | /etc/mysql/ca-cert.pem     |
 | ssl_capath    |                            |
 | ssl_cert      | /etc/mysql/server-cert.pem |
 | ssl_cipher    |                            |
 | ssl_key       | /etc/mysql/server-key.pem  |
 +---------------+----------------------------+
 7 rows in set (0.01 sec)

mysql>  \s
 --------------
 mysql  Ver 14.14 Distrib 5.1.61, for redhat-linux-gnu (x86_64) using readline 5.1

Connection id:          2
 Current database:
 Current user:           root@localhost
 SSL:                    Cipher in use is DHE-RSA-AES256-SHA
 Current pager:          stdout
 Using outfile:          ''
 Using delimiter:        ;
 Server version:         5.1.61 Source distribution
 Protocol version:       10
 Connection:             Localhost via UNIX socket
 Server characterset:    latin1
 Db     characterset:    latin1
 Client characterset:    latin1
 Conn.  characterset:    latin1
 UNIX socket:            /var/lib/mysql/mysql.sock
 Uptime:                 8 min 32 sec

Threads: 1  Questions: 7  Slow queries: 0  Opens: 15  Flush tables: 1  Open tables: 8  Queries per second avg: 0.13
 --------------

Agora o SSL está habilitado.

Agora vamos “transformar” os certificados gerado para que eles sejam reconhecidos pelo Java. Execute os comandos abaixo:

PKCS12

openssl pkcs12 -export -out cert-and-key.p12 -in client-cert.pem -inkey client-key.pem

openssl pkcs12 -export -out cert-and-key-with-ca.p12 -in client-cert.pem -inkey client-key.pem -CAfile ca-cert.pem -chain

openssl pkcs12 -export -out cacert.p12 -in ca-cert.pem -nokeys

JKS

keytool -importkeystore -destkeystore cert-and-key-with-ca.jks -srckeystore cert-and-key-with-ca.p12 -srcstoretype PKCS12

keytool -keystore cacert-added-then-cert-nokey.jks -import -file ca-cert.pem -alias cacert

keytool -keystore cacert-added-then-cert-nokey.jks -import -file client-cert.pem -alias cert

keytool -keystore cacert-added-then-cert-withkey.jks -import -file ca-cert.pem -alias cacert

keytool -destkeystore cacert-added-then-cert-withkey.jks -importkeystore -srckeystore cert-and-key.p12 -srcstoretype PKCS12</pre>

Agora no JBoss AS vamos adicionar as propriedades ao data source que permitem utilizar as conexões seguras fornecidas pelo banco de dados.

Em JBOSS_HOME/server/<config>/deploy crie o arquivo mysql-ds e deixe-o como abaixo:

<datasources>
 <local-tx-datasource>
   <jndi-name>MySqlDS</jndi-name>
   <connection-url>jdbc:mysql://localhost:3306/test</connection-url>
   <driver-class>com.mysql.jdbc.Driver</driver-class>
   <user-name>root</user-name>
   <password>123456</password>
   <track-statements>true</track-statements>

   <connection-property name="verifyServerCertificate">false</connection-property>
   <connection-property name="requireSSL">true</connection-property>
   <connection-property name="useSSL">true</connection-property>
   <connection-property name="javax.net.ssl.trustStore">/etc/mysql/cert-and-key-with-ca.jks</connection-property>
   <connection-property name="javax.net.ssl.trustStorePassword">123456</connection-property>
   <connection-property name="javax.net.ssl.trustStoreType">JKS</connection-property>
   <connection-property name="javax.net.ssl.keyStore">/etc/mysql/cacert-added-then-cert-withkey.jks</connection-property>
   <connection-property name="javax.net.ssl.keyStorePassword">123456</connection-property>
   <connection-property name="javax.net.ssl.keyStoreType">JKS</connection-property>

   <metadata>
     <type-mapping>mySQL</type-mapping>
   </metadata>
  </local-tx-datasource>
</datasources>

Finalmente nossas conexões JDBC que utilizam o data source do JBoss estão trafegando em canal seguro.

Espero que tenha ajudado.

Abraços

Fontes: