Maven SSL and HTTPS Configuration – a Howto

In the world of Java development, working with Maven repositories is essential, as these repositories host the dependencies that our applications rely on. While connecting to public repositories like Maven Central is straightforward, accessing private or secured Maven repositories requires additional configuration. Specifically, when connecting over HTTPS, a Java Keystore may need to be configured to trust the repository’s SSL certificate. Here’s how to set up a Java Keystore for secure HTTPS connections to a Maven repository, ensuring a seamless and secure build process.

Why configure a keystore?

Java applications, including Maven, use the Java Keystore (JKS) to manage certificates for secure communication over SSL/TLS. If your Maven repository uses HTTPS with a self-signed or non-standard certificate, Maven might reject the connection because it cannot verify the certificate’s authenticity. By adding the repository’s certificate to a trusted keystore, you’re explicitly telling Java and Maven to trust this certificate. This setup is particularly relevant for organizations using internal repositories or third-party vendors with their own certificate infrastructure.

Create a test certificate chain

At first we build a custom certificate for test purposes. Please see the following few lines of bash:

Create a Java Keystore (JKS) from certificate and key

Next we build the JKS file from our new certificate and key:

Set up and use Maven’s .mvnrc file

Configuring SSL for Maven using a .mavenrc file may look familiar to you as it involves setting up environment variables for your Java KeyStore (JKS) settings:

Put the file somewhere where your shell is able to consume it or run

$ source /path/to/your/.mavenrc

yourself to have your SSL config up and running.

Configure .mvn/jvm.config file for Maven SSL Authentication

A .mvn/jvm.config keeps your project well-structured with regards to separation of concern and allows for an easy Maven SSL configuration. Therefore this is the way I recommend. To use it properly create a .mvn directory in your Maven project’s root directory, put it on .gitignore (or an equivalent file depending on your VCS) and place a file jvm.config in there. Here we place our Maven SSL config like this:

Use the Maven settings.xml for SSL config

If you prefer to have the whole authentication process at one place there’s always the settings.xml for you:

Benefits of a custom keystore configuration

Setting up a custom keystore for Maven offers flexibility and security. It enables secure connections to internal repositories or those requiring special certificates, without affecting the global Java truststore. Additionally, it simplifies management when dealing with multiple repositories or environments, as each project or CI/CD pipeline can use its own keystore as needed.

Final Thoughts

While configuring a Java Keystore may seem daunting, it’s a powerful way to manage secure connections to Maven repositories. By following these steps, you can ensure that your Java applications are securely retrieving dependencies, protecting your codebase and development environment from potential threats. So next time you encounter an SSL error connecting to a repository, remember—it might just be a keystore configuration away from a quick fix! The full CA and JKS script can be found in this gist, and if you are not fed up with Java, here’s an interesting post covering Browser Test Automation in Java. If you’d rather see something else, don’t worry, here’s the Python version. One more I’d like to share with you: Fresh from the oven comes a post, where I explain the SQLException „before start of resultset“. Give it a click and and see you next time!

Share it with:

Gitlab CI Error – Cannot create local repository at: /.m2/repository

When you are using downstream pipelines in Gitlab CI for complex Maven Projects as I do, you may have stumbled accross this error at least once: Cannot create local repository at: /.m2/repository. The Gitlab runner tries to create a local Maven repository at /.m2/repository – so in the topmost directory – and fails horribly due to an obvious lack of permissions. Let‘ see what happens here.

The Gitlab CI Setup

In my case I had a shell-based Gitlab runner that executes a test suite based on a few artifacts published by a Docker runner. Due to versioning and system test level realism reasons I was not able to use the artifacts directly. Unfortunate, but it shouldn’t pose that kind of a problem, does it?

Now when it comes to cloning the test suite on my shell runner, this cryptic error has been dropped. And naturally I was like „WTF is this runner trying to do!?“

The root cause in Gitlab CI downstream jobs

What I was not aware of is that per default the „child job“ inherits all the custom and Gitlab-provided runner variables from the triggering parent job that is still executed on a Docker runner. Now since the trigger happens from a Docker runner job, the variables my child job receives are poison for a baremetal environment that is my shell runner. Not least because things actually do happen at / in a Docker-based Gitlab execution environment, which is perfectly fine, but not on a shell runner.

The solution: What I had to do to make the CI jobs work

To fix the problem I had to set this on my trigger job definition:

This did not just fix the error for me, but it also made perfect sense. Due to the different execution environments – shell vs. docker and project A vs. project B – I have a different set of requirements for my Gitlab CI test job. Therefore we have another case of an error leading to better software design. In addition I learned another piece of Gitlab’s sometimes quite obscure default settings.

Conclusion

I hope this helps you during your day to day journey through the jungle that are Gitlab CI downstream jobs. As I’m an avid QA engineer, so if you want to read more about writing actual automated tests. Also I take care of deeper coding basics like working with threads in java. If you’d rather want to read up about Gitlab CI’s inherit keyword, here’s the link to the relevant section of the official Gitlab CI documentation. Feel free to have a look!

Have a great weekend everybody!

Share it with: