Erro de verificação de certificado ao enviar uma solicitação de serviço do Weblogic

2

Estou tentando fazer uma chamada de serviço para o salesforce.com. Eu adicionei a cadeia de certificados ao meu armazenamento de chaves, mas quando o serviço verifica o certificado de domínio, ele fica suspenso no curinga da parte do sub-domínio do CN, mas esse é o certificado que tirei diretamente do site. Descobri que o WebLogic não suporta curingas no certificado CN. É possível modificar o CN sem invalidar o certificado.

O erro ao testar o serviço a partir do WebLogic OSB é:

The invocation resulted in an error: [Security:090504]Certificate chain received from sensis-proxy-vs.sensis.com.au - 161.117.32.128 --> cs5.salesforce.com failed hostname verification check. Certificate contained *.salesforce.com but check expected cs5.salesforce.com.

    
por Fergal 30.04.2013 / 06:48

4 respostas

5

O problema aqui é que o verificador de nome de host padrão para o WebLogic não suporta certificados SSL em que o CN contém um caractere curinga para o nome do host.

É possível alterar o verificador de nome de host do WebLogic e o WebLogic é fornecido com uma classe que pode verificar os CNs com curingas.

  1. Vá para o console de administração do WebLogic - > Meio Ambiente - > Servidores - > seu servidor - > Configuração - > SSL

  2. Clique em "Bloquear e editar"

  3. Abra a aba "Avançado"

  4. Altere "Verificação do nome do host" de "BEA Hostname Verifier" para "Custom Hostname Verifier"

  5. Defina "Verificador de nome de host personalizado" como weblogic.security.utils.SSLWLSWildcardHostnameVerifier

  6. Clique em "Salvar" e depois em "Ativar alterações"

  7. Reinicie seu servidor.

por 08.07.2013 / 21:16
2

Amigo que você está procurando para depurar problemas de SSL com o servidor weblogic?

Erro:

FINE: ……….. Eating Exception ……….
java.security.NoSuchAlgorithmException: Algorithm ECDH not available
+ at javax.crypto.KeyAgreement.getInstance(DashoA13*..)+

Motivo:

Isso é algo como o cliente eo servidor não é capaz de negociar uma cifra comum (algoritmo) e, portanto, o handshake está falhando.

Só para dar uma breve ideia: a Cipher é inicializada pelo cliente e o Sever tem que escolher qualquer uma das Cifras apresentadas pelo Cliente para se comunicar no SSL. Se o servidor não suportar qualquer algoritmo de codificação que seja comum ao cliente, a comunicação não acontecerá.

Portanto, se forçar o cliente (Weblogic) a usar as cifras mais fracas e o servidor não tiver restrições sobre o uso de cifras limitadas, poderemos fazer a conexão via SSL.

Resolução:

Como por padrão, o Weblogic Server usa a implementação certicom do SSL.

A exceção acima é porque a implementação do SSL não é capaz de obter uma negociação de cifra comum.

Podemos dizer ao servidor Weblogic para usar a implementação de SSL do SUN para resolver o problema.

Para usar a implementação do SUN do SSL, podemos usar as seguintes propriedades no servidor Weblogic:

  • Djavax.net.ssl.keyStore
  • Djavax.net.ssl.keyStoreType
  • Djavax.net.ssl.keyStorePassword
  • Djavax.net.ssl.trustStore
  • Djavax.net.ssl.trustStoreType
  • Djavax.net.ssl.trustStorePassword
  • Djava.protocol.handler.pkgs = com.sun.net.ssl.internal.www.protocol

todas as propriedades acima podem ser usadas como propriedades JAVA para que a JVM WLS use esses valores em vez de usar sua própria implementação.

Também podemos usar as propriedades acima em nosso código, conforme mencionado abaixo:

System.setProperty( “javax.net.ssl.keyStore”, “***” );
System.setProperty( “javax.net.ssl.keyStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.keyStorePassword”, “***” );
System.setProperty( “javax.net.ssl.trustStore”, “***” );
System.setProperty( “javax.net.ssl.trustStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.trustStorePassword”, “***” );
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
System.setProperty( “java.protocol.handler.pkgs”, “com.sun.net.ssl.internal.www.protocol” );

NOTA - Também para o debug de tempo de execução SSL, você pode usar o Admin Console. Para o login do servidor no Console de administração > > > > Servidores > > > MS1 > > > depurar > > > > árvore de weblogic > > > > opção ssl. Marque a opção e clique em ativar.

    
por 30.04.2013 / 08:44
1

Vá para o console de administração do WebLogic - > Meio Ambiente - > Servidores - > seu servidor - > Configuração - > SSL

Abra a aba "Avançado"

Altere "Verificação do nome do host" de "BEA Hostname Verifier" para "None"

Clique em "Salvar"

Reinicie seu servidor.

    
por 16.07.2015 / 20:00
0

Em alternativa, podemos trabalhar como abaixo.

Acima da configuração da Resposta # "Definir" Verificador de nome de host personalizado "para weblogic.security.utils.SSLWLSWildcardHostnameVerifier" não funcionou para mim.

Eu fiz os seguintes passos para mim:

Vá para o

Admin Console do WebLogic - >         Meio Ambiente - >              Servidores - >                  seu servidor - >                      Configuração - > SSL

  • Clique em "Bloquear e editar"

    • Abra a aba "Avançado"

    • Altere "Verificação do nome do host" de "BEA Hostname Verifier" para "None"

    • Clique em "Salvar" e depois em "Ativar alterações"

    • Reinicie seu servidor.

E o aplicativo cliente que se conecta a esse ambiente SSL ativado eu executei o java com a seguinte opção -D:

-Dweblogic.security.SSL.ignoreHostnameVerification=true

Agora consigo conectar-me do aplicativo cliente ao ambiente ativado por SSL Internamente, meu cliente precisa trabalhar com o JMS ativado para t3s (SSL) no servidor Weblogic. Ele resolveu a exceção abaixo que eu estava recebendo no meu aplicativo cliente:

javax.naming.CommunicationException: t3s://slc09kty.MYHost.com:7202: Destination 10.XX.XX.164, 7202 unreachable; nested exception is:
        javax.net.ssl.SSLKeyException: Hostname verification failed:
    
por 21.10.2015 / 06:44