rsenden
commented
3 years ago At the moment, FortifyVulnerabilityExporter doesn't provide any functionality to configure which certificates are to be trusted. Usually you would just add the certificate to the cacerts file of your JRE, but this is a bit more complicated with a Docker image.
We could potentially add configuration options to FortifyVulnerabilityExporter to handle situations like these, like specifying the path to a certificate to be trusted, or options to disable certificate checks (which would not recommended for a production environment). It may take some time though for us to implement such configuration options, if at all.
Possibly one of the ideas listed below is sufficient to handle self-signed certificates and custom/proprietary root certificates. Please let us know whether any of the options below work for you, we can then add this information to the documentation.
System Properties
Set the following environment variable while running the fortifydocker/fortify-vulnerability-exporter image:
JAVA_OPTS=-Djavax.net.ssl.trustStore=/path/to/alternative/cacerts -Djavax.net.ssl.trustStorePassword=changeitThe trust store at /path/to/alternative/cacerts should of course contain your self-signed certificate or proprietary root certificate. For example, this could point to a cacerts file in your GitLab workspace or a standard cacerts file on your GitLab Runner.
Custom Docker Image
This option is similar to the traditional method of adding a custom certificate to the cacerts file used by the JRE in the Docker image. You will need to build a custom Docker image and reference this custom image in your pipelines rather than the standard fortifydocker/fortify-vulnerability-exporter image.
Following is an example Dockerfile; your mycert.cer needs to be located in the same directory as your Dockerfile when building the image:
FROM fortifydocker/fortify-vulnerability-exporter:latest_rc
COPY mycert.cer /tmp/mycert.cer
RUN keytool -importcert -cacerts -storepass changeit -noprompt -alias mycert -file /tmp/mycert.cerNote that this example only works for latest_rc and future releases; older versions require the full path to keytool to be specified and use the Java 8 keytool syntax.
Volume Mapping
I don't think this is applicable for a GitLab environment (unless you change your workflow to invoke docker manually to run the image), but you could use something like the following to override the cacerts file included with the Docker image:
docker run -v /path/to/host/cacerts:opt/java/openjdk/lib/security/cacerts fortifydocker/fortify-vulnerability-exporter:latest_rcNote that if the System properties option listed above works, I think that would be a much better option for specifying an alternative trust store at runtime. The System properties option can be used when you cannot customize volume mappings, and you don't need to know the location of the cacerts file in the Docker image.
hopenbr
When trying to export SSC SAST to Gitlab, and our SSC is using a self-signed cert you get the below error
to see jobs details look at https://github.com/fortify/FortifyVulnerabilityExporter/issues/18