The Securing Spring Boot Applications With SSL is a great addition to the Spring platform. It is going to simplify dealing with SSL Configuration a great deal. As a stepping stone and to help with gradual migration support a mechanism to adapt classic org.springframework.boot.autoconfigure.web.ServerProperties object as a org.springframework.boot.ssl.SslBundles. Something like this:

package serverpropertiessslbundleadapter;

import org.springframework.boot.autoconfigure.ssl.SslBundleRegistrar;
import org.springframework.boot.autoconfigure.web.ServerProperties;
import org.springframework.boot.ssl.SslBundle;
import org.springframework.boot.ssl.SslBundleKey;
import org.springframework.boot.ssl.SslBundleRegistry;
import org.springframework.boot.ssl.SslBundles;
import org.springframework.boot.ssl.jks.JksSslStoreBundle;
import org.springframework.boot.ssl.jks.JksSslStoreDetails;
import org.springframework.boot.web.server.Ssl;

/**
 * Registers the SSL bundle from the legacy {@link ServerProperties} with the optionally specified name. If the name is not specified,
 * {@link #SERVER_PROPERTIES_SSL_BUNDLE_NAME} will be used as the bundle name.
 *
 * You can use this class as a bean in your application to register the SSL bundle with the name based on {@link ServerProperties}.
 *
 * @Bean
 * public ServerPropertiesSslBundleRegistrar serverPropertiesSslBundleRegistrar(ServerProperties serverProperties) {
 *   return new ServerPropertiesSslBundleRegistrar("tomcat", serverProperties);
 * }
 *
 * Later you can retrieve the sslBundle with name "tomcat" from {@link SslBundles} as follows:
 *
 * SslBundle sslBundle = SslBundles.get("tomcat");
 *
 */
public class ServerPropertiesSslBundleRegistrar implements SslBundleRegistrar {
    public static final String SERVER_PROPERTIES_SSL_BUNDLE_NAME = "SERVER_PROPERTIES_SSL_BUNDLE";

    private final String serverSslBundleName;
    private final ServerProperties serverProperties;
    private final SslBundle sslBundle;

    public ServerPropertiesSslBundleRegistrar(ServerProperties serverProperties) {
        this(SERVER_PROPERTIES_SSL_BUNDLE_NAME, serverProperties);
    }

    public ServerPropertiesSslBundleRegistrar(String serverSslBundleName, ServerProperties serverProperties) {
        this.serverSslBundleName = serverSslBundleName;
        this.serverProperties = serverProperties;
        this.sslBundle = createSslBundle(serverProperties);
    }

    public static SslBundle createSslBundle(ServerProperties serverProperties) {
        // May be look at serverProperties.getSsl().getClientAuth() == Ssl.ClientAuth.NEED 
        JksSslStoreDetails keyStoreDetails = new JksSslStoreDetails(
                    serverProperties.getSsl().getKeyStoreType(),
                    serverProperties.getSsl().getKeyStoreProvider(),
                    serverProperties.getSsl().getKeyStore(),
                    serverProperties.getSsl().getKeyStorePassword()
        );
        // May be look at serverProperties.getSsl().getClientAuth() == Ssl.ClientAuth.NEED 
        JksSslStoreDetails trustStoreDetails = new JksSslStoreDetails(
                    serverProperties.getSsl().getTrustStoreType(),
                    serverProperties.getSsl().getTrustStoreProvider(),
                    serverProperties.getSsl().getTrustStore(),
                    serverProperties.getSsl().getTrustStorePassword()
        );
        return SslBundle.of(
                new JksSslStoreBundle(keyStoreDetails, trustStoreDetails),
                SslBundleKey.of(serverProperties.getSsl().getKeyPassword(), serverProperties.getSsl().getKeyAlias())
        );
    }

    public String getServerSslBundleName() {
        return serverSslBundleName;
    }

    public ServerProperties getServerProperties() {
        return serverProperties;
    }

    public SslBundle getSslBundle() {
        return sslBundle;
    }

    @Override
    public void registerBundles(SslBundleRegistry registry) {
        registry.registerBundle(serverSslBundleName, sslBundle);

    }
}

Comment From: scottfrederick

Thanks for the suggestion. It's an interesting idea, but I don't think we should add this to Spring Boot.

We considered deprecating the server.ssl properties when adding SSL bundles, but decided not to. Even though the server.ssl properties are not deprecated, the spring.ssl bundle properties should be preferred because they are easier to understand and harder to make mistakes with due to the structure introduced there. I would not want to encourage anyone to use the server.ssl properties to add SSL to connection types other than the embedded web servers. The property server.ssl.client-auth only applies to server connections, which makes adapting the server.ssl properties look a little more strange.

The code suggested above is not complete, as it does not consider the PEM file properties under server.ssl. If Spring Boot were to adopt this, we would need to add that support. That's code that Spring Boot would need to maintain over time for limited user value.

In the context of migration, I'm not sure that adding code that creates a new bean from support code is substantially easier than migrating properties in an application.properties or appliation.yaml file.

I'll tag the issue for team attention to see if other team members have thoughts on this.

Comment From: sandipchitale

Thanks for considering the suggestion. I understand the desire to discourage configs that will eventually be deprecated and removed. I am thinking of products with configs that are out there, which can internally start switching to use of SslBundles yet leaving the external config for little longer. I also understand the missing support for .pem side of things in the code above. If there is further interest I could submit a pull request. Just wanted to see if there is any interest in this at all.

As an aside, as you may know, the fact that server.ssl is only applicable to embedded containers like tomcat, yet many people mistakenly think that this config will deal with all the keystore and truststore use cases in the Spring application as whole.

I think the new SslBundles mechanism (especially reuse/sharing) is going to be a great improvement and UX. Thanks a lot for finally solving this problem comprehensively and cohesively. This will allow users to achieve on reuse of one Ssl for all needs (if they want to).

Comment From: wilkinsona

I agree with @scottfrederick. I think we should decline this one.

Comment From: scottfrederick

server.ssl is only applicable to embedded containers like tomcat, yet many people mistakenly think that this config will deal with all the keystore and truststore use cases in the Spring application as whole.

That's unfortunate if that's the case. I would hope the server prefix would be a strong signal that the configuration will only apply to embedded web servers, like all the rest of the properties under that prefix. Hopefully the SSL bundle support can help make this more clear also. If there's anything we can do in documentation to improve this, we'd be happy to look at that as a separate issue.