Specifying a PEM-encoded self-signed root CA certificate via -cert does not work

[mickaelstrg]

Jenkins and plugins versions report

Environment

Jenkins 2.462.2 running in Kubernetes
Using jenkins/inbound-agent:latest@sha256:7df39b03883b9741dacbaac976f054d584c21aeeb54474cf315c5b8dd03db7ef

What Operating System are you using (both controller, and any agents involved in the problem)?

Agent: Debian 12
Controller: Debian 12

both are running in kubernetes

Reproduction steps

1. Create self-signed root ca certificate and jenkins certificate
2. Configure jenkins to use the endpoint certificate in the truststore
3. Mount the root ca certificate in inbound agent's container e.g. under /etc/ssl/certs/ca-certificates.crt
4. Run job using agent by using -cert @/etc/ssl/certs/ca-certificates.crt argument (or -cert $ROOT_CA by dumping the root CA cert into the ROOT_CA environment variable)

Expected Results

Connection via HTTPS to jenkins controller works

Actual Results

Connection via HTTPS to jenkins controller does not work

When using the inbound agent to connect to Jenkins which is setup with a self-signed certificate, I'm using the -cert parameter from the agent.jar to specify the path to the root CA certificate that is used to sign the jenkins certificate:

/opt/java/openjdk/bin/java -jar /usr/share/jenkins/agent.jar -cert @/etc/ssl/certs/ca-certificates.crt -tunnel jenkins-agent.jenkins.svc.cluster.local:30001 -url https://jenkins.jenkins.svc.cluster.local:8080/ -workDir /home/jenkins/agent -noReconnectAfter 1d blablabla hostname 
"-----END CERTIFICATE-----" is not a valid option

Work-around by storing the root CA cert in an environment variable:

export ROOT_CA=$(cat /etc/ssl/certs/ca-certificates.crt)
/opt/java/openjdk/bin/java -jar /usr/share/jenkins/agent.jar -cert $ROOT_CA -tunnel jenkins-agent.jenkins.svc.cluster.local:30001 -url https://jenkins.jenkins.svc.cluster.local:8080/ -workDir /home/jenkins/agent -noReconnectAfter 1d blablabla hostname 
"-----END" is not a valid option

Cert is valid:

openssl x509 -in /etc/ssl/certs/ca-certificates.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            bf:c0:2a:84:f5:63:50:65:2d:9f:44:1a:8f:d2:e6:21
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = jenkins-ca.example.com
        Validity
            Not Before: Nov 26 07:38:52 2024 GMT
            Not After : Nov 24 07:38:52 2034 GMT
        Subject: CN = jenkins-ca.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:eb:73:51:64:a7:02:9f:a0:3b:2b:a9:2f:9f:6b:
                    9f:3e:ec:bf:f9:61:1b:95:10:2a:79:81:4b:72:6d:
                    73:49:f2:5f:60:a4:f8:28:4f:3d:95:34:58:b1:72:
                    c3:30:2f:1e:17:69:1e:4e:4f:58:8a:b2:27:d6:05:
                    f7:dc:93:79:f3:15:d2:48:c3:22:1b:7a:11:c3:4c:
                    b8:06:f8:b9:68:42:78:6e:33:f1:4c:cb:d8:9c:5b:
                    51:a6:8f:b8:3b:ad:bf:9b:50:81:c4:09:3c:50:c3:
                    67:c2:49:6a:d0:f9:44:94:5a:ae:fb:a8:c2:89:6c:
                    32:08:5f:86:5a:6d:f8:b9:a8:d7:f7:34:9e:0d:24:
[...]

This looks to me like something makes it that part of the certificate is considered an argument so the parsing does not work as expected.

Anything else?

No response

Are you interested in contributing a fix?

No response

[biru-codeastromer]

@mickaelstrg Hello Sir can i work on this issue ?

[mickaelstrg]

hi @biru-codeastromer, yes, nobody prevents you from working on this I think :)

[biru-codeastromer]

@mickaelstrg Okay Sir will work on it. Thanks !

[biru-codeastromer]

Hi @dduportal Sir,

I’d like to write the solution to fix the -cert parameter issue.

Here’s the plan what I will be doing:

1.Modify the jenkins-agent Script:

-Add logic to read the certificate file content when the -cert parameter is provided.

-Ensure the certificate content is properly passed to the Java command.

2.Modify the jenkins-agent.ps1 Script:

-Add similar logic for the Windows PowerShell script.

3.Update Dockerfiles:

-Ensure the certificate file is copied to the container.

-Update the ENTRYPOINT to include the -cert parameter if provided.

4.Testing:

-Set up a Jenkins controller with a self-signed certificate.

-Verify that the agent can connect successfully using the -cert parameter.

Let me know if this approach makes sense, and I’ll proceed with the implementation.

[biru-codeastromer]

Also I want to express that I will be coming with a follow-up PR for that instead of cluttering in the previous If you give me the green signal . Thanks !

[dduportal]

Hi @dduportal Sir,

I’d like to write the solution to fix the -cert parameter issue.

Here’s the plan what I will be doing:

1.Modify the jenkins-agent Script:

-Add logic to read the certificate file content when the -cert parameter is provided.

-Ensure the certificate content is properly passed to the Java command.

2.Modify the jenkins-agent.ps1 Script:

-Add similar logic for the Windows PowerShell script.

3.Update Dockerfiles:

-Ensure the certificate file is copied to the container.

-Update the ENTRYPOINT to include the -cert parameter if provided.

4.Testing:

-Set up a Jenkins controller with a self-signed certificate.

-Verify that the agent can connect successfully using the -cert parameter.

Let me know if this approach makes sense, and I’ll proceed with the implementation.

Thanks for the plan proposal! It makes sense but I see a few fundamental problems in your proposal:

• Users are consuming the image directly from the DockerHub (either by running a container or building their custom image on top of this one). It means that updating the Dockerfile is not a viable solution: you have to change the script to only have "runtime" parameters added (through environment variable usually).

• Adding sensitive data such as certificate, credentials, etc. inside a Dockerfile is dangerous. Copying the certificate during the docker build <...> should be avoided.

It might make you change a few things, but your plan looks good for the other steps (at first sight)

[biru-codeastromer]

Thanks for the plan proposal! It makes sense but I see a few fundamental problems in your proposal:

• Users are consuming the image directly from the DockerHub (either by running a container or building their custom image on top of this one). It means that updating the Dockerfile is not a viable solution: you have to change the script to only have "runtime" parameters added (through environment variable usually).
• Adding sensitive data such as certificate, credentials, etc. inside a Dockerfile is dangerous. Copying the certificate during the docker build <...> should be avoided.

It might make you change a few things, but your plan looks good for the other steps (at first sight)

Welcome Sir . Should I implement your improvements and raise the PR !