Skip to content

Instantly share code, notes, and snippets.

@emacdona
Last active May 7, 2021 20:59
Show Gist options
  • Save emacdona/f1c7a92793512933da84f9657da8254a to your computer and use it in GitHub Desktop.
Save emacdona/f1c7a92793512933da84f9657da8254a to your computer and use it in GitHub Desktop.
I’ve got a really strange problem that I’ve been trying to get to the bottom of for three days and I’m really stuck. Posting here hoping someone has an idea of where I could look.
I’ve got a Vagrantfile that provisions a minimal ubuntu VM to use as a local Sandbox to test what follows (the production target is EC2 instance in AWS).
I’ve got some Ansible code that I run against that VM to configure it.
I’ve got a script that runs Ansible via a docker container (so that I — and my coworkers — don’t need to install/mange Ansible on our machines.)
Ansible installs (among other things) Jenkins onto the VM. It is preconfigured with all the credentials it needs (to pull from git, to connect to VPNS) and a few default pipelines.
One of those pipelines is for running Integration Tests. It checks out the repo and runs a Gradle script. Without going into too much detail, the Gradle script’s primary job is to orchestrate containers that lock in “official” versions of software required to build our software.
One of those orchestrated containers is for running maven + adoptOpen JDK
That container is used to build a project whose integration tests require an https connection to a legacy service that runs TLSv1.
That project’s pom uses the “argLine” configuration option for the maven-failsafe-plugin to set the “java.security.properties” file to one that has the following two lines:
jdk.certpath.disabledAlgorithms=
jdk.tls.disabledAlgorithms=
To use this “system”, one installs virtual box, vagrant, and docker. They use vagrant to bring up the sandbox, and then run the script that wraps Ansible in docker. When it completes, they’ve got a VM running Jenkins that they can browse to and click build.
This works fine on a Mac.
The production target (Linux) also works fine, but that’s not an exact replica (the production VMs aren’t provisioned with Vagrant, of course).
However, if run on Windows, the java.security.properties override seems not to be honored, and when the SSL connection is attempted, I get this exception:
“javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.”
Stranger yet, if I remove the java.security.properties override inside the vm running on a Mac, I get a similar, but no the same exception:
“javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints”
I know this process is a bit convoluted, and there are lots of reasons for that. However, one HUGE goal of this was to create a complete “clean room” to run tests. Remember, all of these tests are being run inside of a Linux VM. Can anyone think of a place where the “clean rooms” would vary because of the host OS the VM is running on?
I’m losing my mind! :-)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment