When using SSL for Remote Agents in Bamboo they cannot connect with no cipher suites in common error
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
After enabling SSL on Bamboo's JMS broker, some agents are failing to connect with: Received fatal alert: handshake_failure. javax.net.ssl.SSLHandshakeException: no cipher suites in common is present in the Bamboo server side logging.
Diagnosis
Inside the Bamboo Server side logs $BAMBOO_HOME/logs/atlassian-bamboo.log there is a no cipher suites in common error when the agent tries to connect:
2021-01-10 01:54:31,336 WARN [ActiveMQ Transport: ssl:///192.168.1.128:53856] [Transport] Transport Connection to: tcp://192.168.1.128:53856 failed: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: no cipher suites in common
Inside the $BAMBOO_REMOTE_AGENT/atlassian-bamboo-agent.log we can see it failing with a handshake_failure:
INFO | jvm 23 | 2021/01/10 02:03:45 | Caused by: org.springframework.remoting.RemoteAccessException: Could not access JMS invoker queue [queue://com.atlassian.bamboo.registrationQueue]; nested exception is javax.jms.IllegalStateException: javax.jms.JMSException: Received fatal alert: handshake_failure
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.jms.remoting.JmsInvokerClientInterceptor.convertJmsInvokerAccessException(JmsInvokerClientInterceptor.java:432)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.jms.remoting.JmsInvokerClientInterceptor.invoke(JmsInvokerClientInterceptor.java:207)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
INFO | jvm 23 | 2021/01/10 02:03:45 | at com.sun.proxy.$Proxy24.registerAgent(Unknown Source)
INFO | jvm 23 | 2021/01/10 02:03:45 | at com.atlassian.bamboo.v2.build.agent.remote.AgentRegistrationBean.registerAgent(AgentRegistrationBean.java:52)
INFO | jvm 23 | 2021/01/10 02:03:45 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO | jvm 23 | 2021/01/10 02:03:45 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
INFO | jvm 23 | 2021/01/10 02:03:45 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
INFO | jvm 23 | 2021/01/10 02:03:45 | at java.lang.reflect.Method.invoke(Method.java:498)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:363)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:307)
INFO | jvm 23 | 2021/01/10 02:03:45 | at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:136)
INFO | jvm 23 | 2021/01/10 02:03:45 | ... 22 more
You can also enable -Djavax.net.debug=all on both the Bamboo Server and Remote Agent if you wish to get additional information from the SSL Handshake to see which ciphers the agent is advertising in the ClientHello and what the server supports. The argument should be added as follows:
- Bamboo Server: Configuring your system properties
- Remote Agent:
$BAMBOO_AGENT_HOME/conf/wrapper.conf- E.g.
wrapper.java.additional.x=-Djavax.net.debug=all - Where x is the next number in the sequence of additional properties.
- E.g.
Cause
The use of some required ciphers have been restricted in the java security policy and the server and client don't have an overlap of compatible ciphers to complete the handshake.
Solution
Review the java.security policy on the agent and server and ensure that it has not been customized to a set of algorithms that are too restrictive for the server and agent to agree on a cipher in the SSL Handshake.
$JAVA_HOME/jre/lib/security/java.security
For example, this is a working default as of Java 8 272:
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULLPlease note, there is also an additional property that can cause a different file to be sourced and its configuration appended to the java.security settings:
#
# Determines whether this properties file will be appended to
# using the system properties file stored at
# /etc/crypto-policies/back-ends/java.config
#
security.useSystemPropertiesFile=trueBy default, this is set to false however if it is set to true, you should also review /etc/crypto-policies/back-ends/java.config (or equivalent depending on OS)