Tomcat服务器下智能卡连接校验及SSL重协商方案问询

这是个非常贴合实际场景的需求——智能卡认证的核心价值就在于持续验证用户持有合法凭证，而不是只在初始登录时做一次性校验。针对Tomcat环境，我整理了几种可行的解决方案，你可以根据自己的业务场景选择：

这种方案的核心思路是把用户的智能卡唯一标识和会话绑定，每次API调用时重新验证当前请求的智能卡是否和会话绑定的一致：

• 步骤1：获取智能卡的唯一标识：在用户首次认证通过后，从请求的SSL上下文里提取证书的唯一信息，比如证书序列号、主体DN，或者更精准的智能卡硬件ID（如果需要的话，可以通过PKCS#11接口读取卡的属性）。代码示例：

  X509Certificate[] certs = (X509Certificate[]) request.getAttribute("javax.servlet.request.X509Certificate");
  if (certs != null && certs.length > 0) {
      String cardUniqueId = certs[0].getSerialNumber().toString(); // 用证书序列号作为标识
      request.getSession().setAttribute("BOUND_SMART_CARD_ID", cardUniqueId);
  }
  

• 步骤2：API请求时校验：写一个全局Filter，在每个API请求到达时，重新获取当前请求的智能卡标识，和会话中保存的对比：

  String boundCardId = (String) request.getSession().getAttribute("BOUND_SMART_CARD_ID");
  X509Certificate[] currentCerts = (X509Certificate[]) request.getAttribute("javax.servlet.request.X509Certificate");
  
  if (boundCardId == null || currentCerts == null || !boundCardId.equals(currentCerts[0].getSerialNumber().toString())) {
      // 智能卡已移除或更换，强制要求重新认证
      response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
      response.setHeader("WWW-Authenticate", "TLS-Client-Cert");
      return;
  }
  

  这里返回401 Unauthorized并设置WWW-Authenticate头，会触发浏览器重新发起SSL握手，要求用户重新选择证书（插入智能卡并输入PIN）。

如果你的需求是针对特定敏感API强制每次都做SSL重协商（也就是每次调用都验证智能卡），可以通过Tomcat的配置和代码结合实现：

• Tomcat Connector配置：确保你的SSL Connector已经开启了clientAuth="required"，这是基础。
• 在敏感API的Controller/Filter中触发重协商：Tomcat允许通过request.startSSLHandshake()方法（注意这是Tomcat特有的API，需要引入Tomcat的coyote包）主动触发SSL重协商。示例代码：

  // 仅在敏感API中调用
  if (request instanceof org.apache.catalina.connector.Request) {
      org.apache.catalina.connector.Request tomcatRequest = (org.apache.catalina.connector.Request) request;
      try {
          tomcatRequest.startSSLHandshake();
      } catch (IOException e) {
          // 重协商失败，说明智能卡已移除
          response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
          return;
      }
  }
  

  这种方式会强制浏览器重新进行SSL握手，要求用户再次验证智能卡PIN，确保调用API时卡确实在设备上。

如果需要更底层的硬件级检测（比如确认智能卡物理上是否还连接），可以结合Java的PKCS#11 Provider实现：

• 步骤1：配置PKCS#11 Provider：在java.security中添加你的智能卡PKCS#11驱动配置，或者在代码中动态加载。
• 步骤2：会话中保存密钥别名：用户首次认证后，从证书中提取密钥别名，保存在会话中。
• 步骤3：API调用时检测卡状态：每次调用API时，尝试用保存的密钥别名进行一次轻量操作（比如签名一个空字节数组），如果抛出异常（比如NoSuchAlgorithmException、InvalidKeyException），说明智能卡已移除：

  String keyAlias = (String) request.getSession().getAttribute("SMART_CARD_KEY_ALIAS");
  KeyStore ks = KeyStore.getInstance("PKCS11");
  ks.load(null, null); // 加载PKCS#11密钥库
  
  try {
      PrivateKey privateKey = (PrivateKey) ks.getKey(keyAlias, null);
      Signature sig = Signature.getInstance("SHA256withRSA");
      sig.initSign(privateKey);
      sig.update(new byte[0]);
      sig.sign();
  } catch (Exception e) {
      // 操作失败，智能卡已移除
      response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
      return;
  }
  

  这种方式的优点是能直接检测智能卡的物理连接状态，但缺点是需要额外配置PKCS#11驱动，且性能上会有一定开销。

• 浏览器兼容性：部分浏览器在收到WWW-Authenticate: TLS-Client-Cert头时，可能不会自动弹出PIN框，需要前端配合提示用户重新插入智能卡并刷新请求。
• 会话安全性：建议在智能卡验证失败时，立即销毁当前会话（request.getSession().invalidate()），防止会话劫持。
• 性能权衡：如果是高频API，方案1的性能最优；方案3的性能开销较大，适合低频率的敏感操作。

内容的提问来源于stack exchange，提问作者Swati Joshi