Add support for the TLS registry to the (reactive) REST client extension

[cescoffier]

Description

With the integrated TLS registry, it should be possible to configure the reactive REST client (Quarkus Rest client) using the TLS registry instead of the specific configuration.

Implementation ideas

This is the code used for the mailer:

 private void configureTLS(String name, MailerRuntimeConfig config, TlsConfigurationRegistry tlsRegistry, MailConfig cfg,
            boolean globalTrustAll) {
        TlsConfiguration configuration = null;

        // Check if we have a named TLS configuration or a default configuration:
        if (config.tlsConfigurationName.isPresent()) {
            Optional<TlsConfiguration> maybeConfiguration = tlsRegistry.get(config.tlsConfigurationName.get());
            if (!maybeConfiguration.isPresent()) {
                throw new IllegalStateException("Unable to find the TLS configuration "
                        + config.tlsConfigurationName.get() + " for the mailer " + name + ".");
            }
            configuration = maybeConfiguration.get();
        } else if (tlsRegistry.getDefault().isPresent() && tlsRegistry.getDefault().get().isTlsEnabled()) {
            configuration = tlsRegistry.getDefault().get();
        }

       // Apply the configuration
        if (configuration != null) {
            // This part is often the same (or close) for every Vert.x client:
            cfg.setSsl(true);

            if (configuration.getTrustStoreOptions() != null) {
                cfg.setTrustOptions(configuration.getTrustStoreOptions());
            }

           // For mTLS:
            if (configuration.getKeyStoreOptions() != null) {
                cfg.setKeyCertOptions(configuration.getKeyStoreOptions());
            }

            if (configuration.isTrustAll()) {
                cfg.setTrustAll(true);
            }
            if (configuration.getHostnameVerificationAlgorithm().isPresent()) {
               // ACHTUNG HERE - this is protocol specific. The HTTP-based protocols should use HTTPS by default. 
                cfg.setHostnameVerificationAlgorithm(configuration.getHostnameVerificationAlgorithm().get());
            }

            SSLOptions sslOptions = configuration.getSSLOptions();
            if (sslOptions != null) {
                cfg.setSslHandshakeTimeout(sslOptions.getSslHandshakeTimeout());
                cfg.setSslHandshakeTimeoutUnit(sslOptions.getSslHandshakeTimeoutUnit());
                for (String suite : sslOptions.getEnabledCipherSuites()) {
                    cfg.addEnabledCipherSuite(suite);
                }
                for (Buffer buffer : sslOptions.getCrlValues()) {
                    cfg.addCrlValue(buffer);
                }
                cfg.setEnabledSecureTransportProtocols(sslOptions.getEnabledSecureTransportProtocols());

            }

        } else {
           // Mailer specific configuration (very incomplete as you can see:
            boolean trustAll = config.trustAll.isPresent() ? config.trustAll.get() : globalTrustAll;
            cfg.setSsl(config.ssl);
            cfg.setTrustAll(trustAll);
            applyTruststore(config, cfg);
        }
    }

[quarkus-bot]

/cc @geoand (rest-client)

[geoand]

@cescoffier if you are not already working on this, I'll take it

[cescoffier]

Go ahead @geoand !

[geoand]

👍🏼

[geoand]

I think I need to wait for #40990 to be merged

[geoand]

Furthermore, I don't see how I can access the configured keystore and trustore password. I need those due to how the programmatic API works

[cescoffier]

That's a good point. Can't you pass the Keystore objects directly? The problem passing password is about work duplication.

The registry already opened the keystore, check the passwords (plural), validity, aliases... If we pass the password, there is a good chance you will redo part of that expensive work.

[geoand]

I'll have to take another look.

[cescoffier]

BTW, what did you need from the mailer PR? I removed all the "additions" I made to the TLS registry from that PR as they were not required.

We can imagine keeping the config objects around. I'm only worried about the cost of maintaining references to these objects.

[geoand]

I don't remember what I needed really, I'll have to get back to this and see

[geoand]

I don't remember what I needed really, I'll have to get back to this and see

Looks like since we decided to not use the default configuration, I don't need anything else.

Can't you pass the Keystore objects directly? The problem passing password is about work duplication

It seems that I'll have to add a few things, but it should be doable.

[geoand]

#41153 add the necessary support