How to tell application containers running Java apps to trust self-signed certifications or a private or internal CA

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

This article explains how to tell application containers running Java apps to trust self-signed certs or a private or internal Certificate Authority (CA).

For applications running on TAS that need to access external SSL/TLS endpoints whose certs are not signed by public CA, it is required to tell applications to trust self-signed certs or a private/internal CA. As the approach is different for Java and non-Java applications, this article discusses how to implement Java applications only.

Environment

OS: Linux

Resolution

Option 1

Add trusted certs to the platform. If you are using Java buildpack version 3.12+ or 4+, then the Java buildpack will automatically load these trusted certs. Injecting certs into the platform using this option will also help non-Java applications deployed on the foundation. This option requires TAS operator privilege to run "Apply Change" on Ops Manager.

Option 2

Import the cert to the Java truststore file, pack the file into the Java application and specify its path via the JAVA_OPTS environment variable. The truststore file can be placed under the resource directory. This option is useful for individual applications.

• By using the 'cf set-env' command:

  cf set-env <app> JAVA_OPTS ' -Djavax.net.ssl.trustStore=/home/vcap/app/BOOT-INF/classes/jssecacerts'
  

• By using manifest.yml:

---
applications:
- name: java-app
  ...
  env:
    JAVA_OPTS: '-Djavax.net.ssl.trustStore=/home/vcap/app/BOOT-INF/classes/jssecacerts'

Note: Overriding the default truststore can have unintended consequences. The default truststore comes populated with a lot of well-known CA certs. If one is supplying a keystore with just their trusted certs, then that would wipe out all the pre-populated stuff. Please make sure that your application is not referencing any sites that are included in the default truststore. It could result in trust validation failures for well known, usually trusted sites.

Alternative Solutions

There exist other alternatives besides the recommended solutions, these alternatives are detailed below:

1. Create a script file under application root directory named .profile. In it, run keytool and import all the certs that are packaged with your application. This is useful for individual applications.

Find the script example as shown below:

#!/bin/bash 
$HOME/.java-buildpack/open_jdk_jre/bin/keytool \
    -keystore $HOME/.java-buildpack/open_jdk_jre/lib/security/cacerts \
    -storepass changeit \
    -importcert \
    -noprompt \
    -alias MyCert \
    -file $HOME/WEB-INF/ssl/MyCert.crt

Then run `jar uf target/your-app.jar .profile` to add the script to the root of your application JAR (you can do the same for a WAR file). The script must exist in the root of your JAR/WAR file to be picked up by Cloud Foundry and executed. You can run `jar tf target/your-app.jar | grep profile` to confirm this. The output should indicate `.profile` with no leading path. If there is a leading path, the file was added in the wrong place.

2. Fork Java buildpack from github, put your cacerts file into resources/open_jdk_jre/lib/security/cacerts. This file will be overlayed onto the OpenJDK distribution. Please refer to Java Buildpack - Custom CA Certificates for more details.

For applications deployed to Pivotal Web Services (PWS), please refer to option 2 and to the Alternative Solutions section. Option 1 is only for on-premise TAS installation.

Additional Information

For applications deployed to Pivotal Web Services (PWS), please refer to option 2 and to the Alternative Solutions section. Option 1 is only for on-premise PCF installation.