Provide centralized configuration of SSL properties

[scottfrederick]

There are several auto-configurations in Spring Boot that support SSL configuration using properties, including server.ssl, management.server.ssl, spring.rsocket.server.ssl, and some data services connections as mentioned in #17589. We'd like to make the SSL properties used throughout the system more consistent and easier to understand, and also provide a way to configure SSL properties once and re-use them on multiple connections.

Configuring named sets of SSL configuration could be done with a properties structure similar to this:

spring:
  ssl:
    bundle:
      pem:
        corp-ca:
          keystore:
            certificate:
            private-key:
            type:
          truststore:
            certificate:
            private-key:
            type:
          key:
            alias:
            password:
        other-ca:
          keystore:
            certificate:
            private-key:
      jks:
        my-jks:
          keystore:
            location:
            password:
            type:
          truststore:
            location:
            password:
            type:
          key:
            alias:
            password:

These named sets of configuration could then be applied similar to this:

server.ssl:
  bundle: corp-ca
management.server.ssl:
  bundle: corp-ca
spring.rsocket.ssl:
  bundle: my-jks

and to other connections that don't currently support SSL configuration.

[jgrandja]

@scottfrederick I like the idea of modelling name sets of certificates and associated trust chains. However, we should also account for self-signed certificates, in which case the trustCertificate property would not apply.

Also, certificates can be used outside of an SSL context to provide identity in other flows so we should consider moving certificate outside of spring.ssl to allow for other usages.

[scottfrederick]

Thanks for taking a look @jgrandja.

we should also account for self-signed certificates, in which case the trustCertificate property would not apply.

All of the listed properties are optional, in order to provide flexibility in the way the configured trust material is used (self-signed or CA signed certificates, configuring a server or client connection, one-way or two-way/mutual authentication).

Also, certificates can be used outside of an SSL context to provide identity in other flows so we should consider moving certificate outside of spring.ssl to allow for other usages.

The properties shown here will be used to auto-configure beans that can be used to provide java.net.ssl.SSLContext and related objects so that they can be applied to connections that are auto-configured by Spring Boot (for example, embedded web servers and client connections). There are a few fields like ciphers and enabledProtocols in the current SSL properties that we'll carry over to this new structure but I did not list here. As such, I think it makes sense to have a node like ssl in the tree to support the application of these properties to this auto-configuration.

If and when we identify other uses for certificates in auto-configuration, we can create the necessary property structures for that.