Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate EurekaClient via EurekaOneDiscoveryStrategy + Custom SSLContext #47

Open
andrewfinnell opened this issue Feb 28, 2020 · 1 comment

Comments

@andrewfinnell
Copy link

andrewfinnell commented Feb 28, 2020

I'm having a difficult time registering my hazelcast instance when the Eureka Service is using HTTPS / Secure Ports.

I have been able to override the DiscoveryClient.DiscoveryClientOptionalArgs settings with my own SSLContext when the main Spring Boot Service registers with Eureka and that works. However, because I am using the EurekaConfig of Hazelcast to register a different name via an effective different EurekaClient, I cannot seem to get access to the internals to use the same SSLContext.

I'm really hoping the contributors to this project are able to help me.

This is what I used to do the separate registration without TLS:

pom.xml

        <dependency>
            <groupId>com.hazelcast</groupId>
            <artifactId>hazelcast-eureka-one</artifactId>
            <version>1.1.2</version>
            return new NetworkConfig()
                    .setJoin(new JoinConfig()
                            .setMulticastConfig(new MulticastConfig()
                                    .setEnabled(false))
                            .setEurekaConfig(new EurekaConfig()
                                    .setEnabled(true)
                                    .setProperty("self-registration", eurekaEurekaOneSelfRegistration)
                                    .setProperty("namespace", eurekaEurekaOneNamespace)
                                    .setProperty("name", eurekaEurekaOneName)
                                    .setProperty("shouldUseDns", eurekaEurekaOneShouldUseDns)
                                    .setProperty("serviceUrl.default", eurekaClientServiceUrlDefaultZone)
                                    .setProperty("use-metadata-for-host-and-port", "false")
                                    .setProperty("use-classpath-eureka-client-props", eurekaEurekaOneUseClasspathEurekaClientProps)
                            ));

and this works fine when Eureka is accessible via http. However, it cannot find the Self-Signed CA when Eureka is using secure ports and https.

I'm unable to use the system properties -Djavax.net.ssl.trustStore and such. Again, when I define my own DiscoveryClient.DiscoveryClientOptionalArgs and set the SSLContext it only seems to apply to the EurekaClient proper (i.e. the Spring Boot registration, not the hazelcast registration.)

This works for the Sprint Boot Registration itself, but not the hazelcast registration:

@Configuration
@BootstrapConfiguration
public class SslBootstrapConfiguration
{
    @Value("${http.client.ssl.trust-store}")
    private URL trustStore;

    @Value("${http.client.ssl.trust-store-password}")
    private String trustStorePassword;

    @Bean
    public DiscoveryClient.DiscoveryClientOptionalArgs getTrustStoredEurekaClient(SSLContext sslContext) {
        DiscoveryClient.DiscoveryClientOptionalArgs args = new DiscoveryClient.DiscoveryClientOptionalArgs();
        args.setSSLContext(sslContext);
        SSLContext.setDefault(sslContext);
        return args;
    }

    @Bean
    public SSLContext sslContext() throws Exception {
        return new SSLContextBuilder().loadTrustMaterial(trustStore, trustStorePassword.toCharArray()).build();
    }
}
@mesutcelik
Copy link

Hi @andrewfinnell ,
Thanks for raising the issue and AFAIS, DiscoveryClientOptionalArgs is not supported yet...

DiscoveryClient can be created with DiscoveryClientOptionalArgs object as seen here

Contributions will be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants