Spring Boot：单向SSL强制在客户端配置密钥存储
让我以Java安全性不是我精通的领域为开头。
我有许多通过REST调用进行通信的Spring Boot服务。配置为使用SSL / HTTPS时，需要为各种证书文件和相关信息提供访问和配置。目前，我们仅进行单向验证。稍后可能会进行双向验证。
我对单向验证如何工作的理解是，客户端可以访问信任存储，该存储包含有关将与之交互的任何服务器的公钥信息。给定的服务器将具有包含其密钥信息的密钥存储（我假设是公共的也是私有的）。当客户端尝试调用服务器时，两者之间会交换一些密钥信息，并且客户端会验证服务器的密钥信息是否包含在其信任库中。如果是这样，那么一切都很好，并且过程继续进行。如果不是，则呼叫被拒绝。我也觉得客户不需要密钥存储信息，因为它不会被任何东西调用。
在将服务配置为使用SSL时，需要设置许多SSL属性，如下所示：
server:
port: <some port>
ssl:
enabled: true
protocol: TLS
trust-store-type: JKS
trust-store: classpath:server.truststore
trust-store-password: <password>
key-store-type: JKS
key-store: classpath:server.keystore
key-store-password: <password>
key-alias: <alias>
上面是服务器服务的示例。稍微切线，我认为永不调用其他任何内容的“服务器”服务将不需要信任存储库信息。
对于从来没有被任何人调用的客户服务，我认为我应该能够省去与密钥存储有关的信息。类似于以下内容：
server:
port: <some port>
ssl:
enabled: true
protocol: TLS
trust-store-type: JKS
trust-store: classpath:server.truststore
trust-store-password: <password>
显然，它需要信任存储信息，但是我认为应该不需要任何密钥存储信息，因为它不是必需的。
但是，我不允许这样做。如果我尝试遗漏密钥存储库属性，则应用程序将因无法加载密钥库“空”而失败。如果启用了SSL，则无论是否需要，Spring Boot应用程序启动过程似乎都需要指定密钥存储属性。
有办法解决这个问题吗？
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
在Spring Boot应用中配置SSL时，确实需要同时指定信任库（truststore）和密钥库（keystore），即使对于那些不被其他服务调用的客户端服务也是如此。这是因为Spring Boot的SSL配置旨在确保服务既能作为服务器验证客户端（双向认证时），也能作为客户端验证服务器（单向或双向认证）。这种设计提供了灵活性，使得同一套配置可以适应不同的安全需求场景。
为什么需要密钥库？
- 身份验证：虽然你的特定服务可能不会被其他服务直接调用，但密钥库包含了服务自身的身份凭证（包括私钥），这对于证明服务的身份是必要的。在某些情况下，比如与外部系统交互或者未来启用双向认证时，服务需要通过提供自己的证书来证明其身份。
- 完整性：SSL/TLS协议要求通信双方都具备身份验证的能力，即使当前只做单向验证，框架层面仍需完备的配置以备将来扩展或应对网络架构的变化。
解决方案：
-
最小化配置：如果你确定服务仅作为客户端且短期内不会变为双向认证，仍然需要提供一个密钥库配置，但你可以简化这个过程：
- 使用自签名证书创建一个简单的密钥库，仅供内部验证使用。
- 确保所有必要属性如
key-store,key-store-password,key-alias等都被设置，哪怕它们指向的是一个基本的、仅为满足配置要求而存在的密钥库。
-
条件配置：虽然Spring Boot标准配置不直接支持根据角色（服务器/客户端）动态加载不同的SSL配置，但你可以在代码层面进行一些定制逻辑，根据运行时环境或特定条件决定是否加载或如何加载密钥库。这需要编写自定义的Spring Bean或配置类来覆盖默认的SSL配置行为。
-
文档和注释：清晰地记录你的配置决策和任何非标准的处理方式，这样团队中的其他成员或未来的维护者能理解为何做了这样的配置，尤其是在使用了自定义逻辑或简化密钥库的情况下。
-
考虑长远：尽管目前不需要双向认证，但在设计之初就考虑到未来可能的需求变化，预先做好兼容性准备，可以避免将来的大规模重构。
综上所述，即使对于不被调用的服务，也建议遵循完整的SSL配置实践，通过简化或模拟的方式满足框架要求，同时保持对潜在安全需求的适应性。
