【问题标题】:Handling multiple certificates in Netty's SSL Handler used in Play Framework 1.2.7在 Play Framework 1.2.7 中使用的 Netty 的 SSL 处理程序中处理多个证书
【发布时间】:2014-01-15 10:36:29
【问题描述】:

我有一个 Java 密钥库,用于存储每个客户子域的证书。我计划按照建议here 使用服务器别名来区分密钥库中的多个客户。 Play framework 1.2.7 使用 Netty 的 SslHandler 来支持服务器端的 SSL。我尝试实现一个自定义 SslHttpServerContextFactory 使用这个solution。

import play.Play;

import javax.net.ssl.*;
import java.io.FileInputStream;
import java.net.InetAddress;
import java.net.Socket;
import java.security.KeyStore;
import java.security.Principal;
import java.security.PrivateKey;
import java.security.Security;
import java.security.cert.X509Certificate;
import java.util.Properties;

public class CustomSslHttpServerContextFactory {

  private static final String PROTOCOL = "SSL";
  private static final SSLContext SERVER_CONTEXT;

  static {

    String algorithm = Security.getProperty("ssl.KeyManagerFactory.algorithm");
    if (algorithm == null) {
      algorithm = "SunX509";
    }

    SSLContext serverContext = null;
    KeyStore ks = null;
    try {
      final Properties p = Play.configuration;

      // Try to load it from the keystore
      ks = KeyStore.getInstance(p.getProperty("keystore.algorithm", "JKS"));
      // Load the file from the conf
      char[] certificatePassword = p.getProperty("keystore.password", "secret").toCharArray();
      ks.load(new FileInputStream(Play.getFile(p.getProperty("keystore.file", "conf/certificate.jks"))),
          certificatePassword);

      // Set up key manager factory to use our key store
      KeyManagerFactory kmf = KeyManagerFactory.getInstance(algorithm);
      kmf.init(ks, certificatePassword);
      TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm);
      tmf.init(ks);

      final X509KeyManager origKm = (X509KeyManager) kmf.getKeyManagers()[0];
      X509KeyManager km = new X509KeyManagerWrapper(origKm);

      // Initialize the SSLContext to work with our key managers.
      serverContext = SSLContext.getInstance(PROTOCOL);
      serverContext.init(new KeyManager[]{km}, tmf.getTrustManagers(), null);
    } catch (Exception e) {
      throw new Error("Failed to initialize the server-side SSLContext", e);
    }

    SERVER_CONTEXT = serverContext;
  }

  public static SSLContext getServerContext() {
    return SERVER_CONTEXT;
  }

  public static class X509KeyManagerWrapper implements X509KeyManager {
    final X509KeyManager origKm;

    public X509KeyManagerWrapper(X509KeyManager origKm) {
      this.origKm = origKm;
    }

    public String chooseServerAlias(String keyType,
                                    Principal[] issuers, Socket socket) {
      InetAddress remoteAddress = socket.getInetAddress();
      //TODO: Implement alias selection based on remoteAddress

      return origKm.chooseServerAlias(keyType, issuers, socket);
    }

    @Override
    public String chooseClientAlias(String[] keyType,
                                    Principal[] issuers, Socket socket) {
      return origKm.chooseClientAlias(keyType, issuers, socket);
    }

    @Override
    public String[] getClientAliases(String s, Principal[] principals) {
      return origKm.getClientAliases(s, principals);
    }

    @Override
    public String[] getServerAliases(String s, Principal[] principals) {
      return origKm.getServerAliases(s, principals);
    }

    @Override
    public X509Certificate[] getCertificateChain(String s) {
      return origKm.getCertificateChain(s);
    }

    @Override
    public PrivateKey getPrivateKey(String s) {
      return origKm.getPrivateKey(s);
    }

  }

}

但是,由于某种原因,这种方法不起作用。我在 SSL 调试日志中收到此消息。

X509KeyManager passed to SSLContext.init():  need an X509ExtendedKeyManager for SSLEngine use

这是 SSL trace,失败并显示“没有共同的密码套件”。现在,我将包装器切换为:

public static class X509KeyManagerWrapper extends X509ExtendedKeyManager

通过此更改,我摆脱了警告,但我仍然看到与以前相同的错误“没有共同的密码套件”,这里是 SSL trace。我不确定为什么密钥管理器的委派不起作用。

在这种情况下可能有用的更多信息。

  • Netty 使用 javax.net.ssl.SSLEngine 在 NIO 服务器中支持 SSL。
  • 根据此错误report 中的建议,X509ExtendedKeyManager 必须与 SSLEngine 一起使用是有意的。因此,包装器必须扩展 X509ExtendedKeyManager。

这阻碍了我进一步使用 X509KeyManagerWrapper 中的自定义别名选择逻辑。关于这里可能发生的事情的任何线索?有没有其他方法可以在 Netty/Play 中实现这一点?感谢任何建议。

【问题讨论】:

    标签: ssl netty keystore playframework-1.x jsse


    【解决方案1】:

    SSLEngine 使用 chooseEngineServerAlias 方法来选择要使用的证书(在服务器模式下) - 而不是 chooseServerAlias 方法。

    默认的chooseEngineServerAlias implementation 实际上返回null,这就是导致“没有共同密码套件”消息的原因 - 您需要证书才能知道可以使用哪些密码套件(例如,只能使用 ECDSA如果证书具有 ECC 公钥等,则用于身份验证。)实际上有一些密码套件可以在没有证书的情况下使用,但是,它们通常被禁用,因为它们容易受到 MITM 攻击。

    因此,您还应该覆盖chooseEngineServerAlias,并实施您的逻辑以根据那里的 IP 地址选择证书。由于 Netty 只使用 SSLEngine,chooseServerAlias 的作用无关紧要 - 它永远不会被调用。

    Java 8 还支持服务器端 SNI,它允许您在具有单个 IP 地址的多个主机名中使用多个证书。大多数网络浏览器都支持 SNI - 值得注意的例外是在 Windows XP 和一些旧版本的 Android 上运行的 IE,然而,这些的使用正在下降。我在GitHub 上创建了一个小示例应用程序,演示如何在 Netty 中使用 SNI。其工作原理的核心部分是覆盖 chooseEngineServerAlias - 这应该会给您足够的提示,即使您想使用每个 IP 地址一个证书技术而不是 SNI。

    (我在 Netty 邮件列表上发布了一个类似的答案,你也问过这个问题 - 但是,我的帖子似乎还没有被批准,所以我想我也会在这里回答,这样你就可以得到一个尽快回答。)

    【讨论】:

    • 谢谢格雷厄姆。你成功了!我知道使用基于 Java 的服务器支持此用例的唯一方法是使用 Java 8 SNI 服务器端支持。最后我最终选择了 Nginx SNI 来实现这个需求,这是一个更简单的选择,而且在 Play 1.2.7/Netty 和 configuration 的前面非常简单。但是,您的解决方案具有高度可扩展性,并且更容易与 Netty 集成。感谢您为编写一个工作示例所做的努力。
    • 这也适用于 Grizzly 2,以防有人像我一样来到这里寻找它。
    • 请注意,Graham 的示例应用程序希望密钥库别名与请求的主机名匹配。我更喜欢与证书属性匹配的解决方案,以支持通配符证书、备用名称等。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-06-08
    • 1970-01-01
    • 2019-09-16
    • 2021-07-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多