如何在两个Scala/Akka Web服务间配置合规SSL？

一、核心问题解决：自动实现实例间证书信任 #

你的核心需求是在去中心化节点注册流程中自动完成SSL证书的信任建立，无需用户手动操作keytool。结合你现有的注册流程，可以这样优化：

1. 嵌入证书交换的注册流程扩展 #

在现有握手流程中加入证书交换逻辑，无需切换端口或重绑定套接字：

• 步骤1扩展：用户A发送RegistrationRequest时，附加自己服务器的DER格式SSL证书公钥（可通过Akka-http的SSLContext提取，如sslContext.getServerCertificates()(0).getEncoded()）
• 步骤2扩展：用户B收到请求后，验证请求合法性（比如匹配预分享的serverID/alias），将A的证书公钥添加到本地TrustStore（用Java的KeyStoreAPI动态加载，无需重启服务）
• 步骤4扩展：用户B发送RegistrationAccept时，附加自己的证书公钥，用户A接收后同步添加到本地TrustStore
• 后续HTTPS通信会自动信任对方证书，解决PKIX路径构建失败的问题

2. 动态TrustStore实现示例 #

在Scala/Akka-http中，可创建支持动态更新的SSLContext：

import java.security.{KeyStore, Security}
import javax.net.ssl.{KeyManagerFactory, SSLContext, TrustManagerFactory}
import java.io.FileInputStream

// 初始化加载本地密钥库与信任库
val keyStore = KeyStore.getInstance("JKS")
keyStore.load(new FileInputStream("keystore.jks"), "your-keystore-pass".toCharArray())

val trustStore = KeyStore.getInstance("JKS")
trustStore.load(new FileInputStream("truststore.jks"), "your-truststore-pass".toCharArray())

// 初始化信任管理器工厂
val tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm)
tmf.init(trustStore)

// 当收到对方证书时动态更新信任库
def addRemoteCertToTrustStore(remoteServerId: String, cert: java.security.cert.Certificate): Unit = {
  trustStore.setCertificateEntry(remoteServerId, cert)
  tmf.init(trustStore)
  // 重建SSLContext并更新Akka-http配置（Akka-http支持动态替换，无需重启服务）
  val kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm)
  kmf.init(keyStore, "your-keystore-pass".toCharArray())
  val newSslContext = SSLContext.getInstance("TLS")
  newSslContext.init(kmf.getKeyManagers, tmf.getTrustManagers, null)
  // 更新你的Akka-http服务器SSL上下文
  // 例如：server.setSslContext(newSslContext)
}

二、两种方案的安全性评估 #

方案1：分发共用RootCA #

• 风险极高：一旦RootCA私钥泄露，攻击者可伪造任意节点的证书接入网络，完全破坏系统安全性，绝对不推荐。
• 即便改为用户本地生成RootCA，也会回到节点间信任链建立的初始问题，与你的需求矛盾。

方案2：双端口（HTTP+HTTPS） #

• 安全性优于方案1，但需严格控制风险点：
  • HTTP端口仅开放注册凭证认证、证书添加接口，禁止任何业务逻辑通过HTTP传输
  • 凭证认证需强校验：使用绑定serverID的一次性令牌，或基于预分享信息做双向验证，避免注入恶意证书
  • 证书添加后需校验：验证证书主题/颁发者与对方serverID匹配，防止伪造
  • 建议限制HTTP端口的访问范围（如仅局域网、白名单IP），进一步降低暴露风险

三、关于Websocket的替代方案 #

如果不想重写现有后端，无需切换到Websocket：Akka-http原生支持HTTPS长连接，你的chatter服务可基于HTTPS Server-Sent Events或HTTP/2双向流实现，与现有架构完全兼容。
若未来考虑重写，Websocket确实适合去中心化实时通信，但核心的SSL证书信任问题与当前方案一致，仍需通过注册流程自动交换证书建立信任链。

内容的提问来源于stack exchange，提问作者Kris Rice