Let user to provide own KeyManager and TrustManager for HTTPS server

[tsaarni]

Description

Let user provide their own custom KeyManager and TrustManager, which would be used for the HTTPS server (by Vert.x).

This could allow implementing certificate hot-reload #15926 in the application side.

Implementation ideas

No response

[sberyozkin]

@dmlloyd Hi David, I recall you were looking at some options awhile back, to provide custom factories dealing with SSL ? Sorry if it was not related

[tsaarni]

I found interesting PR #26767 that @cescoffier has kindly contributed quite recently. I'm testing this with Quarkus 2.12.0.CR1. It works very nicely even for setting own keymanager that has hot-certificate-reload capability:

@ApplicationScoped
public class VertxCustomizer implements HttpServerOptionsCustomizer {

    @Override
    public void customizeHttpsServer(HttpServerOptions options) {
        // First do whatever is required to create custom keymanager.
        ...

        // Set it to VertX HttpServerOptions
        KeyCertOptions kco = KeyCertOptions.wrap((X509KeyManager) km);
        options.setKeyCertOptions(kco);
    }
}

As far as I can see, I still have to define server certificate in quarkus.http.ssl.certificate.* config options as well, since that will enable HTTPS in the first place. Otherwise I don't get callback to customizeHttpsServer(). This feels bit clumsy, as the certificate given as config option will not end up being used, due to the customization.

Is there any workaround that I could use to avoid setting the certificates in quarkus.http.ssl.certificate.* but still enable HTTPS?

[dmlloyd]

@dmlloyd Hi David, I recall you were looking at some options awhile back, to provide custom factories dealing with SSL ? Sorry if it was not related

IIRC what I was looking at was providing a single configuration strategy for TLS. Using the Elytron APIs we can plug in handlers for customized authentication and other things, at abstraction points that are more logical than replacing the trust manager and key manager. I'd have to review whether that would in turn allow support for hot-swapping certificates, but it seems feasible at least.

[tsaarni]

Currently the HttpServerOptionsCustomizer.customizeHttpsServer() call happens only if Vert.x SSL config was created

quarkus/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/VertxHttpRecorder.java

Lines 662 to 664 in 36ea30a

	if (sslConfig != null) {
	customizer.customizeHttpsServer(sslConfig);
	}

But if user does not set certificate & key or keystore in quarkus.http.ssl.certificate.* then SSL config is not created. Null is returned here in the last branch:

quarkus/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/VertxHttpRecorder.java

Lines 844 to 857 in 36ea30a

	if (!certificates.isEmpty() && !keys.isEmpty()) {
	createPemKeyCertOptions(certificates, keys, serverOptions);
	} else if (keyStoreFile.isPresent()) {
	KeyStoreOptions options = createKeyStoreOptions(
	keyStoreFile.get(),
	keyStorePassword.orElse("password"),
	sslConfig.certificate.keyStoreFileType,
	sslConfig.certificate.keyStoreProvider,
	sslConfig.certificate.keyStoreKeyAlias,
	keyStoreKeyPassword);
	serverOptions.setKeyCertOptions(options);
	} else {
	return null;
	}

That makes it impossible for the implementer of HttpServerOptionsCustomizer to customize the HTTP server by enabling SSL config :-(. It can only customize existing SSL config.

Would it be acceptable to allow HttpServerOptionsCustomizer to create SSL config? I can work with this, but would appreciate if someone could point me into the right direction with the API change.

[tsaarni]

I have submitted #27682 to allow application to set custom KeyManager without setting dummy placeholder values in quarkus.http.ssl.certificate.*.