Expired SSL Certificate


I noticed that one of the builds on gitlab.orekit.org failed due to an expired SSL certificate: Sign in · GitLab

It seems to be when the gitlab runner is attempting to connect back to the gitlab server.

Any ideas on how to fix it?


Hi @evan.ward,

I’m looking at this right now.


The TLS certificate provided by Gitlab is valid, but the Docker image used by the pipeline (maven:3.3.9-jdk-8) is outdated and fails to verify the validity of the certificate.

I tried the following command:

$ docker run --rm -it --name maven --entrypoint /bin/sh maven:3.3.9-jdk-8
# openssl s_client -connect gitlab.orekit.org:443 < /dev/null | grep 'Verify return code:'
    Verify return code: 10 (certificate has expired)

If I launch the same command in a up to date image, the result is different:

$ docker run --rm -it --name maven --entrypoint /bin/sh maven:3.8.3-openjdk-8
# openssl s_client -connect gitlab.orekit.org:443 < /dev/null | grep 'Verify return code:'
    Verify return code: 0 (ok)

So, you have to use a more recent Maven image, maven:3.8.3-openjdk-8 or maven:3.8.3-openjdk-11 at your convenience.

The file to be modified is https://gitlab.orekit.org/orekit/ci-utils/-/blob/master/build-env/Dockerfile

Thanks for debugging that! I guess I should have checked the client was up to date.

Best Regards,

Yes, I checked this point and I noticed that this instance of Gitlab Runner is not up to date, its version is 12.5.0. The current version of Gitlab CE is 14.3.2 and the last version of Gitlab Runner is 14.3.2 too. But it is not an issue, even if we will update this runner when we have some time.

Using a Docker container has the advantage (and sometimes, as in this case, the disadvantage) of isolating the pipeline execution context from the underlying system. Therefore, what is important is the environment provided by the Docker container.

Finally, the Gitlab forge TLS certificate is managed via Let’s Encrypt and automatically regenerated every two months.

Thank you for your vigilance Evan.

See you soon

I can take care of that, but it’s up to you and the other members of the core team to decide which image you want to use. Do you prefer a CI based on Java 8 or 11? Does this Maven version change have an impact? I can’t answer to these questions.

If you prefer to keep the current version of Maven, I can try to regenerate its Docker image with an updated TLS certificate package.

Because Java 8 is the minimum version required to run Orekit (according to the website), I think the best would be to have a CI based on Java 8.

OK. And is the version of Maven also important?

I don’t know if the Maven version is important…

I just tried to build a new image, based on the maven:3.3.9 image, which I updated. This does not solve the problem, because this image is still based on a very old JDK 8 image (5 years old).

In that case, I think maven:3.8.3-openjdk-8 is a good candidate to solve the problem.

Agreed, Orekit compiling and testing works with Maven 3.8.3

I just tried with an intermediate version (maven:3.6.3-openjdk-8-slim). The TLS certificate verification works. So, I generated a new image using this version. Now, you should update the Orekit CI script.

In the line #8, replace maven:3.3.9-jdk-8 by maven:3.6.3-openjdk-8-slim

Thanks for the test @MaximeJ. I chose a older version of Maven because probably not all developers use the latest version.

Thanks for the updates! I’ll also point out that maven 3.6.2 is the latest in RedHat 8 and derivative distributions. (https://pkgs.org/search/?q=maven) It would be nice to test with that version or earlier so that users can build Orekit from one of those distributions.

I used maven 3.6.3 in my merge request. According to its release note, this version just fixes some bugs of version 3.6.2. Do you think it is necessary to adjust the version of Maven, at the risk of facing bugs attributable to this version (and not to the Orekit source code)?

Hi Evan,

I just updated the Docker image built for the CI and my MR to use this version of Maven:


1 Like

Thanks Sébastien!