C# proxy certificate issue

[CaringDev]

Using the new .NET NuGet package (in a docker container) I run into problems when behind a company proxy, i.e. proxyUrl is set. The proxy certificate is in the OS (Linux) trusted roots (installed by copying and running update-ca-certificates). The .NET HttpClient is able to connect but when trying to connect to the registry I get

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

If I read https://www.graalvm.org/jdk25/reference-manual/native-image/dynamic-features/CertificateManagement/ correctly, the keystore gets embedded at build time but can be overwritten using javax.net.ssl.trustStore.

Given proxies are a rather common thing, would you mind adding a way to "bring our own certificates"?

[CaringDev]

I tried to build from source but I get the P/Invoke exception.
@swaradgat19 @isaurab007 what did you change for the 1.0.1 version?

[isaurab007]

Hello @CaringDev

Thanks for the detailed issue report. We confirm that the issue stems from GraalVM embedding the certificate trust-store at build-time.

Have you tried following the Runtime Options section of the GraalVM documentation? Do you see any errors with that solution? This will help us review our SSL-specific native-image build arguments.

Also, if you can share the .csproj and a minimal setup with 1.0.0 version where you are running into the P/Invoke exception, that will help us reproduce and fix the issue. 1.0.1 is the same as 1.0.0, with some coverage flags disabled.

A common scenario where we noticed the P/Invoke exception is when the RuntimeIdentifier property is not set in your application.
Ex: <RuntimeIdentifier>linux-x64</RuntimeIdentifier>

[CaringDev]

Hello @isaurab007

Thanks for your reply. If I'm not mistaken, the javax.net.ssl.trustStore* properties should be set either on the command line (java -D...) or in program code using System.setProperty. CLI is not applicable, as we are calling into the native library... so I guess we'd need to have a way to pass the info into the Java code (e.g. via GlueSchemaRegistryConfiguration) which should set those properties accordingly. At least I don't know how I'd do that from C# or via e.g. environment variables.

As for the exception: see #490 respectively failing and succeeding GH actions, with the only difference being 1.0.0 vs. 1.0.1

[isaurab007]

While we are investigating and prioritizing this issue, PRs are welcome. All build instructions are in the respective directories under multilang-schema-registry to help with local testing.