New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GoCD 23.2/23.3 breaks agent mTLS connectivity when private key is encrypted/passphrase protected #11866
Comments
Sorry, can you please describe the problem and your environment more clearly? You haven't described what actually happened, what you expected to happen, how you install the server, what the previous version you were using (which presumably worked?) was - or any of the rest of the basic details requested by the issue template. |
Hello Chad, Note when updating to v23.1 instead it worked normally.
|
Thanks for the additional details. Ugh, I think I might have an idea why this is. To clarify, do things work fine if the server is on 23.2 or 23.3 but the agents are left on 23.1? |
Just to clarify, there is no major harm (or loss of functionality) with continuing to use the 'installed' agent 23.1.0 with a later GoCD Server so if this works fine for you, that's an acceptable workaround. The agent you 'install' is actually just a bootstrapper which connects to the server and downloads the 'real' agent binaries. Of course it needs to be able to connect first, so if using mtls 9n your reverse proxy, API GW or load balancer this issue might be a blocker. If this was caused by a change (which seems likely) I'll still need to fix it though so would appreciate help narrowing it down. |
Thanks a lot for your feedback, Chad :) 1- GoCD server on v22.1 and agents upgraded to v23.1 (Working). Hope this would help narrowing the issue. |
Thanks for this. Are you sure about this as "not working":
If it's definitely not working in that combination, can you please share the agent-side log and stack trace? (appropriately redacted) That combination should work, or at least any problem is likely to have a different root cause (off top of my head, I can't think of any other major incompatibility between agent bootstrappers and server between As a general rule, it's not wise to have agent bootstrappers and server differ by more than ~12 months due to the somewhat unwritten compatibility guarantees we try to adhere to ( |
Hello Chad, Apologies , a correction in this scenario versions were (GoCD server on v23.2 and agents on v21.4) and it was not working with the same error message. Actually, I got all agents updated o v23.2. I will try to check if I can rollback any and provide you wiht the logs. |
Its very unlikely to me that the error message (a BouncyCastle PEM parsing error) was the same on earlier agents such as 22.4 or 22.1, however as I said above its possible there is a separate compatibility issue that prevents agents from starting or talking to the server. What did you do to get 23.2 agents to work? From what I can see that would not be possible unless you disable mTLS (I e stop using a client cert and key to authenticate with your reverse proxy/API GW/load balancer) or perform much deeper hacks to the JVM configuration used by the agent bootstrapper. If the mTLS configuration is not actually being used or validated by your reverse proxy (perhaps it is old configuration) in front of your server removing that config would be fine, but if you are relying on mTLS for security/policy reasons I think you're best to stay with 23.1 agents. The problem indicated by the specific BouncyCastle error here was introduced in 23.2.0 and I can replicate locally (I also have a fix, but I am trying to add regression tests to avoid such a problem accidentally being introduced again in future). |
Hi @Mai-Khattab - ive closed this now as I've addressed the root problem for 23.4, regardless of mix-and-matched agent/server versions. After thinking further, you might be right that the GoCD server version of 23.2 or 23.3 would also have had issues, since the mTLS capability is not just required to initially bootstrap, but also to continue talking to the server. It may not be acceptable to you, but you may find that another workaround to make mTLS possible with 23.2 and 23.3 is if the private key is not encrypted (i.e not protected with a passphrase). |
Hello Chad, Thank you so much for the updates. I have a workaround currently in place. I will check once GoCD 23.4 released. Kind Regards, |
In the spirit of open source, it would perhaps be useful to know what that workaround is, for the benefit of the wider community - rather than keeping it to yourself? |
Hello Chad, Really apologies, I have just seen this comment right now. Regards, |
Ok thanks. Anyway, this issue should be resolved with 23.4.0 or 23.5.0 in any case. |
Issue Type
Summary
<After updating GoCD server/agents to v23.2. Agents having passphrase configurations in their wrapper-properties lost connections>
Environment
Basic environment details
23.2.0
17.0.8
Linux 3.10.0-1160.83.1.el7.x86_64
Edge
Additional Environment Details
Steps to Reproduce
Update GoCD server/agents to v23.2
Ensure that wrapper-properties have client certificate along with passphrase configurations as below:
wrapper.app.parameter.104=-sslCertificateFile
wrapper.app.parameter.105= /var/go/.vfclientcert/client.pem
wrapper.app.parameter.106=-sslPrivateKeyFile
wrapper.app.parameter.107=/var/go/.vfclientcert/client.key
wrapper.app.parameter.108=-sslPrivateKeyPassphraseFile
wrapper.app.parameter.109=/usr/share/go-agent/wrapper-config/test
wrapper.app.parameter.110=-sslVerificationMode
wrapper.app.parameter.111=FULL
Expected Results
Actual Results
Log snippets
The text was updated successfully, but these errors were encountered: