我正在尝试实现双向(相互)SSL 身份验证,但我在 Glassfish3/4 和 Tomcat 8 服务器上不断收到以下异常(堆栈跟踪来自 Tomcat 8):
10-Feb-2016 17:13:41.579 SEVERE [http-nio2-18443-exec-2] org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun Error running socket processor
java.lang.RuntimeException: Field length overflow, the field length (7189180) should be less than 65536
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1373)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:529)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:807)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:775)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.apache.tomcat.util.net.SecureNio2Channel.handshakeUnwrap(SecureNio2Channel.java:394)
at org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:267)
at org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204)
at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1064)
at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1046)
at org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:598)
at org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:583)
at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:83)
at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:76)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker$2.run(Invoker.java:218)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
经过长时间的搜索,我只找到了this link。这显示了同样的问题,但在 JBoss 上。这真的与 key /信任库中条目的大小/数量有关吗?我现在存储了约 66.000 个证书,但随着开发的进行,我们预计会方式更多(例如,数十万个)。
在几乎是空的 keystore (只有服务器和其中的一个测试客户端证书)的情况下,使用 curl
测试 SSL 连接成功...
更新
好吧,我想我发现它确实与信任库有关。以下是来自 sun.security.ssl.HandshakeMessage.CertificateRequest
的代码片段:
// put certificate_authorities
int len = 0;
for (int i = 0; i < authorities.length; i++) {
len += authorities[i].length();
}
output.putInt16(len);
异常是在 putInt()
方法中触发的,所以我假设我确实存储了太多证书。我现在正在生成自签名证书,所以我必须让每个生成的证书作为服务器上的 CA 来信任客户端,这一定是问题所在。现在的问题是,有没有办法从 Java 生成非自签名证书(例如,我可以使用 glassfish 的自签名证书作为 CA - 或者我可以吗)?
最佳答案
好的,我通过创建证书并将颁发者设置为服务器自己的证书(在 Glassfish 中,特别是别名 s1as
)并使用服务器的私钥对其进行签名来使其工作。现在我不必在服务器上存储任何东西,因为它可以识别客户端,因为它在其 trustStore(本质上是它自己)中知道它们的颁发者是 CA。
关于java - 使用 Glassfish3/4 或 Tomcat 8 和自签名证书的双向(相互)SSL,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35320731/