java - 使用自定义 X509KeyManager 时，Java 无法为 SSL 握手确定匹配的密码套件

Question

我正在使用 Java7 和 JAX-WS 2.2。

对于 SOAP Web 服务，我需要创建自定义 X509KeyManager，以便在 JKS keystore 中为每个连接的客户端找到正确的证书。

但是，我已经在努力运行我的自定义 key 管理器。到目前为止，我使用的是默认证书(从初始化的 KeyManagerFactory 中检索)并且它基本上可以工作 - 但当然它没有选择正确的证书。所以第一个想法是创建一个自定义的 X509KeyManager 来保存原始 key 管理器，只写出一些日志消息，但通常使用默认行为。

出于某种原因根本不起作用。无法建立 SSL 握手。在 ClientHello 之后，日志显示以下错误:

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Thread-3, READ: TLSv1 Handshake, length = 149
*** ClientHello, TLSv1
RandomCookie:  GMT: 1476877930 bytes = { 207, 226, 8, 128, 40, 207, 47, 180, 146, 211, 157, 64, 239, 13, 201, 92, 158, 111, 108, 44, 223, 136, 193, 251, 33, 202, 7, 90 }
Session ID:  {}
Cipher Suites: [TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
***
%% Initialized:  [Session-3, SSL_NULL_WITH_NULL_NULL]
Thread-3, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
%% Invalidated:  [Session-3, SSL_NULL_WITH_NULL_NULL]
Thread-3, SEND TLSv1 ALERT:  fatal, description = handshake_failure
Thread-3, WRITE: TLSv1 Alert, length = 2
Thread-3, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common

据我所知，我根本没有删除任何密码套件!并且 SSL 握手可以使用相同的证书进行。

这是我的 key 管理器:

public class CustomX509KeyManager extends X509ExtendedKeyManager
{
   private static final Logger LOG = Logger.getLogger( CustomX509KeyManager.class );
   private final X509KeyManager originalKeyManager;

   public CustomX509KeyManager(final X509KeyManager keyManager)
   {
      super();
      this.originalKeyManager = keyManager;
   }

   @Override
   public String chooseServerAlias(final String keyType, final Principal[] issuers,
     final Socket socket)
   {
      final String serverAliases=
            this.originalKeyManager.chooseServerAlias( keyType, issuers, socket );
      CustomX509KeyManager.LOG.info( "chooseServerAlias() " + serverAliases );
      return serverAliases;
   }

   ...
}

其他方法(此处未显示)也只是调用 originalKeyManager 中的相应方法。在测试期间，我从未看到来自 chooseServerAlias() 方法的日志消息。

它是从 getSslContext() 方法中的另一个类初始化的:

private KeyManager[] getKeyManagers(final KeyManagerFactory keyManagerFactory)
{
   final KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();

   // replace any X509KeyManager with our own implementation
   for ( int i = 0; i < keyManagers.length; i++ )
   {
      if ( keyManagers[i] instanceof X509KeyManager )
      {
         keyManagers[i] =
               new CustomX509KeyManager( ( X509KeyManager ) keyManagers[i] );
      }
   }

   return keyManagers;
}

public SSLContext getSslContext()
{
  // create the KeyStore and load the JKS file
  final KeyStore keyStore = createKeyStore();

  // initialize key and trust manager factory
  final KeyManagerFactory keyManagerFactory =
        KeyManagerFactory.getInstance( KeyManagerFactory.getDefaultAlgorithm() );
  keyManagerFactory.init( keyStore, "changeit".toCharArray() );
  final TrustManagerFactory trustManagerFactory =
        TrustManagerFactory.getInstance( TrustManagerFactory.getDefaultAlgorithm() );
  trustManagerFactory.init( keyStore );

  // initialize the SSL context
  final SSLContext sslContext = SSLContext.getInstance( "TLS" );
  // sslContext.init( keyManagerFactory.getKeyManagers(),
  //      trustManagerFactory.getTrustManagers(), new SecureRandom() );
  sslContext.init( getKeyManagers( keyManagerFactory ),
        trustManagerFactory.getTrustManagers(), new SecureRandom() );
  return sslContext;
}

注释行显示默认 key 管理器的原始用法。

知道哪里出了问题吗？为什么使用我的 CustomX509KeyManager 的行为与无法完成握手的默认 key 管理器如此不同？使用默认 key 管理器，为 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 算法协商加密，该算法也可用于自定义 key 管理器，但由于某些原因未选择。

更新 1

我正在尝试在客户端模式下使用 openssl 连接到服务器，但服务器在使用 SSL 时遇到了同样的问题。当我使用 TLS 协议(protocol)时，附加错误消息

Unsupported extension type_35, data:

出现。

更新2

我可以确认上述关于不受支持的扩展的通知也出现在成功的握手时，所以这是一个错误的痕迹。

Answer 1

经过几天的反复试验，我终于找到了我的错误!

在 Java 7 中，自定义 key 管理器应该扩展 X509ExtendedKeyManager这迫使您实现接口(interface) X509KeyManager 的五个方法。但是，X509ExtendedKeyManager 类中还有两个额外的方法，它们未声明为抽象的，但必须被覆盖以正确使用:

• chooseEngineClientAlias(String[], Principal[], SSLEngine)
• chooseEngineServerAlias(String, Principal[], SSLEngine)

通过将调用委托(delegate)给我的 originalKeyManager(也变成了 X509ExtendedKeyManager 类型)覆盖并实现这些方法后，SSL 握手终于成功了。