No error message when server.ssl.keyAlias doesn't match an entry

[numsu]

Hello!

This is a feature request to handle an error.

I ran into an issue when updating my project from version 1.x.x to 2.x.x. Seems like the property server.ssl.keyAlias was turned case sensitive and the application couldn't load the key from the keystore on startup. The application is still able to startup with no error or warn log about it but clients cannot complete a handshake.

Example:
Keystore keystore.jks contains a private key entry with an alias myprivatekey
Set the properties

server:
  ssl:
    enabled: true
    key-store: keystore.jks
    key-store-password: changeit
    keyAlias: MyPrivateKey

The symptoms:
Chrome gives the following error: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
openssl printout:

CONNECTED(00000003)
140162214049696:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:744:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 247 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

The resolution:
The application shouldn't be able to start with SSL turned on if the alias specified doesn't match anything in the keystore provided.

Used Spring Boot version: 2.1.2.RELEASE

[philwebb]

We currently apply the server.ssl.key-alias property to the underlying servlet container (see org.springframework.boot.web.embedded.tomcat.SslConnectorCustomizer for one example) and let it deal with the alias. I'm not sure why things have changed between Boot 1.x and 2.x, but I imagine it's likely to be because of a dependency upgrade.

@numsu What servlet container are you using?

[numsu]

I believe that the application uses the netty container

[wilkinsona]

All supported containers appear to behave consistency across versions. Tomcat is the only container that fails to start when the key alias points to a non-existent key:

_	Jetty	Netty	Tomcat	Undertow
1.5.22	Starts	N/A	Fails	Starts
2.1.7	Starts	Starts	Fails	Starts

Our configuration of Netty appears to ignore the key alias entirely. I've opened #17944 to address that.

[wilkinsona]

When a request is made to a misconfigured Jetty instance it fails, but nothing is output on the server-side. The JDK's ServerHandshaker.setupPrivateKeyAndChain calls Jetty's AliasedX509ExtendedKeyManager.chooseEngineServerAlias(String, Principal[], SSLEngine) which returns null. The JDK's SSL support then fails silently.

Similarly, nothing is output on the server-side when a request is made into Undertow. This time the JDK's ServerHandshaker.setupPrivateKeyAndChain calls Boot's SslBuilderCustomizer.ConfigurableAliasKeyManager.chooseEngineServerAlias(String, Principal[], SSLEngine) which returns the configured, non-existent alias. The JDK's SSL support then fails silently.

Even with -Djavax.net.debug=all, it's not clear (to me at least) that the failure with Jetty or Undertow is due to a misconfigured key alias. With Undertow I think we have an opportunity to catch and report that problem in ConfigurableAliasKeyManager. I'm not sure what we can do with Jetty.

[onobc]

@wilkinsona

One approach is to create a utility (that can be shared by all flavors of servers) that can inspect a keystore and see if the alias exists. That can then be called by each server/customizer, before diving down into the bowels of the server, and short circuit the startup.

class SslUtils {
	boolean storeContainsAlias(KeyStore keyStore, String alias) {
		...
	}
}

I am currently working on #17944 and would love to grab this one next. Thoughts on the above approach?

Also, on your thought of doing this in ConfigurableAliasKeyManager - those methods are called during request, not during startup so I don't think they will be a good spot to do that.

[wilkinsona]

Thanks for taking a look at this, @Bono007.

As long as we don't have to get involved with loading the KeyStore and can instead retrieve the KeyStore that the container has loaded, checking it for the presence of the alias sounds like a good idea to me. Jetty, for example, makes the KeyStore it has loaded available via org.eclipse.jetty.util.ssl.SslContextFactory.getKeyStore() once the factory has been started.

When using Undertow, ConfigurableAliasKeyManager is constructed during startup. It is at this point that I had anticipated we'd check that the alias exists.