Client HTTPS configuration

[cristianonicolai]

I'm following the configuration to setup HTTPS port on the Docker server with server.cert_file and server.cert_key, but I was wondering if the Java and React clients require any special configuration to connect via HTTPS? Thanks

[dosubot[bot]]

Hi @cristianonicolai! I'm Dosu and I’m helping the flipt team.

No special configuration is needed for Java or React clients to connect via HTTPS as long as the server presents a certificate trusted by the client environment. The Java client uses the standard Java runtime for HTTPS, so if you're using a certificate from a public CA, it should work out of the box. If you're using a self-signed certificate, you'll need to add your CA to the JVM's trust store. The React client relies on the browser's HTTPS handling—if the certificate is trusted by the browser, everything will work; if not (e.g., self-signed), the browser will show a warning. There are no Flipt-specific SSL/TLS settings required in either client—just set the URL to use https:// and ensure the certificate is trusted by the client environment.
Java client reference
React client reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[cristianonicolai]

Im using a self-signed certificate to connect from the Java client to a Flipt server. On the server I've setup both FLIPT_SERVER_CERT_FILE and FLIPT_SERVER_CERT_KEY accordingly. Also, FLIPT_SERVER_PROTOCOL=https and FLIPT_SERVER_HTTPS_PORT=8443 since running as non-root. On the Java side. tried using the default JVM truststore with the custom certificate as well as adding SSL_CERT_FILE env var from Rust, but none worked. On the Flipt server, I keep getting: http: TLS handshake error from 192.168.228.178:37898: remote error: tls: unknown certificate.
@markphelps, anything else I could be missing to make it work?

[cristianonicolai]

Some extra info. I'm running from an alpine based container. Since adding the self-signed certificate to /etc/ssl/certs/ca-certificates.crt, I can wget into Flipt's https port without issues. If there was an env var like SSL_CERT_FILE we could rely on, that would be ideal.

[markphelps]

@cristianonicolai I think you are correct that we might need to add support for self-signed certs in the Rust layer as it uses the reqwest crate to do the HTTP(S) calls.

Heres a blog post where someone does something similar with self-signed certs and reqwest: https://maisyt.hashnode.dev/importing-a-self-signed-cert-for-a-rust-reqwest-http-client

Question: how are you generating the self-signed cert? This way I can generate my own following your same process and try to get it working with reqwest.

[cristianonicolai]

@markphelps we use Letsecrypt to generate the certificates and these are usually rotated in a Kubernets envrionment. Thats why having a way to point to the file would be best, otherwise we need to keep importing the cert into the OS every time it changes.

[markphelps]

@cristianonicolai It will take a while to get self-signed TLS support in all the SDKs but I got it working in Python flipt-io/flipt-client-sdks#1134 and will now prioritize Java and JS/React next.

You can track the progress in flipt-io/flipt-client-sdks#1132

[cristianonicolai]

No problem, I'm happy to test and provide feedback once it's available.

[markphelps]

ive got a PR for the Java one here, would you mind taking a look if you have a chance and let me know if it looks good / idiomatic modern Java? flipt-io/flipt-client-sdks#1135

[cristianonicolai]

Looks good, thanks @markphelps !

[markphelps]

@cristianonicolai v 1.1.0 of the Java SDK now supports custom TLS config (https://github.com/flipt-io/flipt-client-sdks/tree/main/flipt-client-java#tls-configuration)

The React/JS sdks may take a big longer as I have no idea how this works with the fetch API

[cristianonicolai]

Thanks @markphelps ! Unfortunately ,that still not working. From what I can see, all we should need to do is to set TlsConfig.withCaCertFile. On the client I continue to get the following error:

Caused by: io.flipt.client.FliptException$EvaluationException: server error: failed to make request: Request failed after 3 retries
        at io.flipt.client.FliptClient.evaluateBoolean(FliptClient.java:230)

And on the server:
http: TLS handshake error from 192.168.157.64:41000: remote error: tls: unknown certificate

Apart from wget, I could also validate that the certificate I'm using should work with the following:
openssl s_client -connect flipt.test.svc:443 -CAfile /certs/ca.crt
Returning: Verify return code: 0 (ok)

Is there anything I could try to provide more details to help replicate? I think it would be helpful if the Java layer exception could expose more details about the error.

Just to mention, using TlsConfig.insecure() works as expected. Also tried both methods withCaCertData and withCaCertFile.

[markphelps]

@cristianonicolai can you try setting FLIPT_ENGINE_LOG=debug env var where you run the Java code? this should provide some more logging as to what the engine is doing under the hood

[markphelps]

Actually that doesnt work currently, i need to fix our logging in the Rust code. For now you can use RUST_LOG=debug, however it probably wont be of much use until I improve what it logs

[cristianonicolai]

Yep, tried both and only shows the following:

[2025-07-02T01:36:16Z DEBUG reqwest::connect] starting new connection: 
[2025-07-02T01:36:16Z DEBUG reqwest::connect] starting new connection: 
[2025-07-02T01:36:20Z DEBUG reqwest::connect] starting new connection: 
[2025-07-02T01:36:20Z WARN  fliptengine] [FFI] fetch failed: 

[markphelps]

im working on publishing a new release that should have better internal logging to help us figure out whats going on with the certs

[markphelps]

@cristianonicolai ok.. i think I finally figured it out. after many tries I finally found a combination that works at least with my testing.

Can you update your dependency to version 1.1.1-rc.7 to get these fixes? If its successful I'll create 1.1.1 and drop the RC

The issue was in the flipt-engine-ffi crate's TLS configuration code. The engine was using a complex custom rustls configuration that wasn't properly handling self-signed certificates, even when users provided custom CA certificates through TlsConfig.withCaCertFile() or TlsConfig.withCaCertData().

What was fixed?

Version 1.1.1-rc.7 includes two major fixes:

1. Simplified TLS implementation : The engine now uses reqwest's built-in TLS handling instead of complex custom rustls configuration, which resolves the self-signed certificate issues.

2. Added hostname verification skip option : Added the insecureSkipHostnameVerify option to handle cases where the certificate is valid but the hostname doesn't match (common with self-signed certificates).

How to update your code

Replace the deprecated static methods with the new builder pattern:

TlsConfig tlsConfig = TlsConfig.builder()
    .caCertFile("/path/to/your/ca.pem")
    .insecureSkipHostnameVerify(true)  // This is likely what you need
    .build();

FliptClient client = FliptClient.builder()
    .url("https://your-flipt-server:8443")
    .tlsConfig(tlsConfig)
    .authentication(new ClientTokenAuthentication("your-token"))
    .build();

[markphelps]

Ok, are you able to send me an example reproduction of the issue on your side? like perhaps a private example repo with how you're setting up the client and also how you're generating the self-signed cert? like the actual commands used to generate the cert? I think this would really help me figure out whats causing the issue

[markphelps]

you should also be seeing these logs for each request as its added as middleware in the newer version:

https://github.com/flipt-io/flipt-client-sdks/blob/5908c446731ebc097a9696e6b9cb90478b0c5855/flipt-engine-ffi/src/http.rs#L158

[cristianonicolai]

@markphelps sorry about the delay. Getting back into this, I'm trying to create a reproducer for you in here: https://github.com/cristianonicolai/quarkus-flipt, and following a few strategies to create the certificates following: https://quarkus.io/guides/tls-registry-reference#quarkus-cli-commands-and-development-certificate-authority
Interestingly, newly created certificates following these guides work just fine in the reproducer. Therefore, I need to find out why using certificates from our Kubernetes environment fails. Would it be possible to add some extra logs to help debug the issue?

This is what Im getting at the moment in the logs:

2025-08-05 13:35:10,346 INFO  [org.acm.fli.FliptTestResource] (pool-3-thread-1) Flipt container started at: https://localhost:60441
2025-08-05 13:35:10,529 INFO  [org.acm.fli.FliptService] (main) Connecting to Flipt service using url: https://localhost:60441
2025-08-05 13:35:10,529 INFO  [org.acm.fli.FliptService] (main) Using HTTPS certificate to connect with Flipt
[2025-08-05T03:35:11Z TRACE fliptengine] initialize_engine called: opts ptr=0x13883aa70
[2025-08-05T03:35:11Z DEBUG fliptengine::http] making HTTP request to: https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default
[2025-08-05T03:35:11Z DEBUG reqwest::connect] starting new connection: 
[2025-08-05T03:35:11Z WARN  fliptengine::http] error GET https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default -> error sending request for url (https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default) (source: client error ())
[2025-08-05T03:35:11Z DEBUG reqwest::connect] starting new connection: 
[2025-08-05T03:35:11Z WARN  fliptengine::http] error GET https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default -> error sending request for url (https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default) (source: client error ())
[2025-08-05T03:35:13Z DEBUG reqwest::connect] starting new connection: 
[2025-08-05T03:35:13Z WARN  fliptengine::http] error GET https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default -> error sending request for url (https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default) (source: client error ())
[2025-08-05T03:35:15Z DEBUG reqwest::connect] starting new connection: 
[2025-08-05T03:35:15Z WARN  fliptengine::http] error GET https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default -> error sending request for url (https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default) (source: client error ())
[2025-08-05T03:35:15Z WARN  fliptengine] initial fetch failed: 
[2025-08-05T03:35:15Z TRACE fliptengine] initialize_engine returning engine ptr=0x600001321020
[2025-08-05T03:35:15Z DEBUG fliptengine::http] making HTTP request to: https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default
[2025-08-05T03:35:15Z DEBUG reqwest::connect] starting new connection: 
[2025-08-05T03:35:15Z WARN  fliptengine::http] error GET https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default -> error sending request for url (https://localhost:60441/internal/v1/evaluation/snapshot/namespace/default) (source: client error ())

The (source: client error ()) part doesnt give out much information. If you could add the raw error details on a debug at least, so we can check what is happening in the Rust layer, I think that could help.

[cristianonicolai]

@markphelps good news here, I was able to pin point the issue on the certificate that was causing the connection error. Our tls.crt did contain the following:

 X509v3 Basic Constraints: critical
                CA:TRUE

That's definitely not necessary since it won't issue any certificate. Strangely enough, other Java based systems did not complain about that. Again, having extra details in the logs could have helped to find the exact issue.
If you could generate a new, final version of the Java client, that way we can move forward with our deployment. Again, thanks for all your help on this issue.

[markphelps]

Thank you @cristianonicolai for the follow up and glad you were able to figure it out! I'll release a new java client version today. I just want to take one more look at why the rust logs were not giving more info on the actual issue first

[markphelps]

@cristianonicolai i just released v1.1.1 of the Java client with hopefully improved logging that will hopefully help us narrow down these kinds of issues sooner in the future. Please give it a try and let me know if it works for you all!

Thank you again for your continued patience and diligence in helping us get this resolved!!