VertxHttpClientHTTPConduit: keyManagers and certAlias?

[famod]

Hi @ppalaga!

Is it just me or is the new default VertxHttpClientHTTPConduit ignoring TLS config like:

• org.apache.cxf.configuration.jsse.TLSParameterBase.getKeyManagers()
• org.apache.cxf.configuration.jsse.TLSParameterBase.getCertAlias()

?
Both are handled in org.apache.cxf.transport.https.SSLUtils but AFAICS this util is not used by the vert.x conduit?

[ppalaga]

Do you create the TLSClientParameters programmatically?

[ppalaga]

Do you create the TLSClientParameters programmatically?

Yes.

Ouch, I have not thought of that use case much, TBH (and therefore it is not covered by any tests). I wonder what was your motivation for that? Just an old code before we had quarkus.cxf.client."client-name".trust-store, quarkus.cxf.client."client-name".key-store & CO? Those should be mapped to the new TLS config properly.

[famod]

        final var httpConduit = soapApiClient.getConduit();
        final var tlsClientParameters = Optional.ofNullable(httpConduit.getTlsClientParameters()).orElseGet(TLSClientParameters::new);
        tlsClientParameters.setCertAlias(config.clientCert().keyAlias());
        tlsClientParameters.setKeyManagers(securityStoreProvider.getKeyManagers(config.clientCert()));
        httpConduit.setTlsClientParameters(tlsClientParameters);

config ist a custom @ConfigMapping and securityStoreProvider is also custom:

    /**
     * Gets the KeyManager(s) from Keystore using the password of the given reference to retrieve the key.
     * <p/>
     * The manager(s) will effectively operate on a single key that is identified by the given parameter, not on the full original store!
     * <p/>
     * This operation might not be particularly cheap so use it sparingly!
     *
     * @param keyReferenceProperties key config
     * @return the managers
     */
    public KeyManager[] getKeyManagers(final KeystoreKeyReferenceProperties keyReferenceProperties) {
        try {
            final KeyManagerFactory factory = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
            // We don't want to implement our own KeyManagerFactory, but since init() only allows a password for _all_ entries,
            // we are creating a new store with just that single entry. Otherwise init() would fail with BadPaddingException.
            final var entryPassword = keyReferenceProperties.keyPassword();
            factory.init(toSingleEntryKeyStore(keyReferenceProperties, entryPassword), entryPassword.toCharArray());
            return factory.getKeyManagers();
        } catch (final GeneralSecurityException e) {
            throw new IllegalStateException("Failed to get KeyManagers for alias " + keyReferenceProperties.keyAlias(), e);
        }
    }

About 4 years ago, all that was the result trying to cover multiple different external SOAP endpoints that all required different client certs.
We have one keystore that contains all the different private keys, all having different passwords.
Not sure why we needed to create transient single entry keystores and set an alias, but I do remember we needed 2 or 3 attempts for it to work.

[famod]

Btw, I'm fine with dropping our old impl. I just need to find some time to migrate and test.

[ppalaga]

@famod if there is any actionable item, could you please file an issue?

[ppalaga]

Anything to do here @famod ?