App doesn't use cacerts included in the bundled JRE library

[stanleyz]

Bug description 🐞

API and Executor, and likely registry as well don't use the cacerts keystore provided by the bundled JRE located in /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts, which I'd assume should be the default behaviour if no customised keystone is specified.

Steps to reproduce

Create a Redis cache or PostgreSQL with SSL enabled on Azure and configure Terrakube API or Executor to run with them (on SSL)

Expected behavior

The app starts without issues since the Azure root certs is already loaded into layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts

Example repository

No response

Anything else?

No response

[alfespa17]

That is automatically added inside the container using the ca-certificate buildpack from here

Example when building the image:

The CA certificates are added internally as you can see in the following images:

You can add additional CA certificates as we explained here

I am not a go expert but I think the values are taken from here

[stanleyz]

yes, there is no problem adding a customised CA certificate or the ca-certificates provided by paketo-buildpacks, the problems I saw are that:

1. Liquibase doesn't use the ca-certificates provided by paketo-buildpacker and installed to jre/lib/ca-certificates
2. Redis connection still requires TerrakubeSSLTruststorePath and password to be set, however, it doesn't necessarily need to because the connection should default to use the trust store provided by the JRE, and additionally with the above method provided, users can add customised CA certificates to the JRE truststore.

[alfespa17]

I did some progress with this one in this PR #1391 when using REDIS and SSL

[stanleyz]

I did some progress with this one in this PR #1391 when using REDIS and SSL

Nice, thanks @alfespa17

[alfespa17]

I did more progress with this one. I was able to connect successfully to an Azure Redis with SSL enabled using the following with a custom image that I built that included the fix:

api:
  version: "2.23.2+small fix from AzBuilder/terrakube#1391"
  image: "api-server"
  defaultRedis: false
  defaultDatabase: true
  loadSampleData: true
  env:
  - name: TerrakubeRedisSSL
    value: "true"
  - name: TerrakubeRedisTruststorePath
    value: /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts 
  - name: TerrakubeRedisTruststorePassword
    value: changeit
  properties:
    redisHostname: "MY-REDIS-IN-AZURE.redis.cache.windows.net"
    redisPassword: "MY-REDIS-ACCESS-KEY"
    redisPort: "6380"

executor:
  version: "2.23.2"
  env:
  - name: SERVICE_BINDING_ROOT
    value: /mnt/platform/bindings
  - name: TerrakubeRedisSSL
    value: "true"
  - name: TerrakubeRedisTruststorePath
    value: /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts 
  - name: TerrakubeRedisTruststorePassword
    value: changeit

"changeit" is the default password for the java keystore included in the container by default in this path "/layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts"

The only issue that I see is that I had a huge latency from my local machine to the Azure Redis and the logs were not showing in the correct order.

So in theory the above should work to use SSL with REDIS.

[stanleyz]

Thanks @alfespa17, I will give it a try in my next upgrade. Happy for you to close this.

The only issue that I see is that I had a huge latency

I am also wondering about the performance of Azure Redis cache, will see.