Load Public Key Certificates into default Trust Store

[mbaxr]

I need to have the public certificates of my function app loaded into default Trust store used by the Java Function App.

Some details of my Java Function App:

• Dedicate Premium App Service plan
• Linux platform
• Java 21
• Spring Boot 3.5.x
• Logback
• Splunk HEC plugin

Exception:

• javax.net.ssl.SSLHandshakeException
• java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130)
• PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The exception happen when Splunk try to push log messages against Splunk instance with SSL certificate signed with internal Public key certificate.

I already have the certificate configured under the Function App -> Settings -> Certificates -> Public key certificates (.cer) configurations

While under Function App -> Settings -> Environments variables page I have the following App settings:

KEY	VALUE
WEBSITE_LOAD_CERTIFICATES	*
WEBSITE_VNET_ROUTE_ALL	1

[ahmedmuhsin]

Hey @mbaxr, thanks for the details.

First, can you confirm:

1. OS (Windows vs Linux) and whether you’re running built-in App Service runtime vs a custom container, and
2. your hosting plan (Dedicated/App Service plan vs Premium vs Consumption/Flex)?
   These affect where the cert shows up and how JVM args are applied.

Setting WEBSITE_LOAD_CERTIFICATES makes uploaded certs available to your app (Windows: loaded into the CurrentUser\My certificate store; containers: materialized under well-known file paths), but it does not automatically modify the JDK’s default trust store (cacerts). So Java TLS validation will still fail with PKIX unless you explicitly configure a trust store that contains your internal CA.

App Service doc for the OS-specific locations + “available to code” behavior:
https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code?tabs=linux#load-certificates-in-linuxwindows-containers

Workarounds:

• Point the JVM at a trust store that includes your CA (via JAVA_OPTS).
• On Windows, Java can also read the native Windows keystores (Windows-MY/Windows-ROOT), but it still needs explicit configuration to use them for trust.

[mbaxr]

Yes these are the details you have requested:

• Dedicate Premium App Service plan
• Linux platform

Setting WEBSITE_LOAD_CERTIFICATES makes uploaded certs available to your app (Windows: loaded into the CurrentUser\My certificate store; containers: materialized under well-known file paths), but it does not automatically modify the JDK’s default trust store (cacerts). So Java TLS validation will still fail with PKIX unless you explicitly configure a trust store that contains your internal CA.

I have listed the certificates under the expected folder (/var/ssl/certs) successfully. The problem are:

1. Certs are placed as one .der file per entry
2. No jks is provided with all of them
3. I have built some code to create a new JKS trust store with the folder certificates, but this is code will always run after Logback configuration because Java Worker start Spring application without using the main method.

The execution I expected:

Java worker start -> Main class start + cert configure -> Spring start -> Logback star -> My App configuration run

Execution plan in function app:

Java worker start -> Spring start -> Logback star -> My App configuration run

Main method is ignored and thus any attempt to do some configuration before Spring start fail.

The linked page provide an example only for C# and for Java it seems that there is no way. See Issue 732

[ahmedmuhsin]

Hey @mbaxr, thanks for the extra context.

Given your ordering problem (Spring/Logback + Splunk appender doing TLS before your app code runs), here are three options you can choose from. I have not personally tested these end-to-end in your exact setup, but they’re the main patterns that should work:

• Mount an Azure Files share that contains a prebuilt truststore
  Put a truststore.jks / truststore.p12 in an Azure Files share, mount it to a known path (Linux only), then point JSSE at it via JAVA_OPTS so it’s in place at JVM start. This avoids the “too late” problem entirely. Mounting file shares to Linux Function Apps is supported, with some constraints (mount path format, up to 5 shares, cold start impact).
  Microsoft Learn

• Logback custom Configurator (run code before appenders are created)
  Implement ch.qos.logback.classic.spi.Configurator and register it via META-INF/services/.... Logback discovers these via ServiceLoader and runs them early, before the normal logback.xml processing. That gives you a hook to generate a truststore from /var/ssl/certs/.der and set javax.net.ssl.trustStore before the Splunk appender initializes. https://logback.qos.ch/manual/configuration.html

• FunctionInstanceInjector (run code before DI container creates the function instance)
  Implement the Functions Java SPI FunctionInstanceInjector and do your one-time truststore bootstrap inside the injector before returning the function instance (or before creating your Spring context, if you’re using Spring-based DI). This is the officially supported DI hook in the Java programming model.
  https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-java#function-instance-injector-for-dependency-injection

[mbaxr]

In the end after reading about your three solutions, I choose the Logback configurator (2nd).

I made a quick proof of concept code to understand if can work and effectively I executed some code before Logback configuration.

Thanks you very much @ahmedmuhsin 🥇

I'll leave here a code example as trace for other users:

File META-INF/services/ch.qos.logback.classic.spi.Configurator

com.example.MyLogbackConfiguration

File MyLogbackConfiguration

package com.example;

import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.classic.spi.Configurator;
import ch.qos.logback.classic.util.DefaultJoranConfigurator;

public class MyLogbackConfiguration extends DefaultJoranConfigurator {

    @Override
    public ExecutionStatus configure(LoggerContext context) {
        // You code here...
        System.out.println("Running before logback start")
        
        // Resume default logback configuration
        return super.configure(context);
    }
}

[mbaxr]

After some more test into how the code is getting deployed and run into the azure function it's not working.

The configurator is not getting correctly read.

During local test phase I have seen the logback debug output list of found configurators, bot nothing was printed into logstream when the application is ran under Function App.

[mbaxr]

In the end I used FunctionInstanceInjector, had to basically reimplement AzureFunctionInstanceInjector, remove that package dependency to make it work.