Direkt zum Hauptbereich

Atlassian Bitbucket SonarQube new server configuration shows handshake_failure

 

Problem:

Adding a new SonarQube server configuration I got an error complaining about the ssl handshake. This is how it looked in atlassian-bitbucket.log:

2018-09-10 09:03:24,796 ERROR [http-nio-50002-exec-10] bitadmin @HBVN6Wx543x650x0 1lam9n2 10.87.50.248,10.32.10.80,0:0:0:0:0:0:0:1 "POST /rest/sonar4st
ash/1.0/sonar-server-configs HTTP/1.1" c.m.s.s.sonar.DefaultSonarClient SONAR: Could not connect Sonar server at GET http://amdev.somecompany.com/sonarqube//api/server/version HTTP/1.1
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
...

Since we are using a companywide PKI with our own issuer certificates I rechecked if the whole certificate chain was imported into the truststore jdk1.8.0_121/jre/lib/security/cacerts/, but everything seemed ok.


Solution:

The problem was a missing cipher. See https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.htm for the solution.

Short: Download http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html and extract it to jre/lib/security/cacerts. Restart Bitbucket.

Checking the cipher needed:

openssl s_client -connect amdev.somecompany.com:443 | grep -i cipher

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384


New ciphers imported with the hint from Atlassian:

TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     < - - - This one!
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384

Kommentare

Beliebte Posts aus diesem Blog

How to delete WebSEAL servers which have not been configured correctly.

Problem: The WebSEAL server list in the pdadmin: pdadmin> server list shows the server, but it does not exist anymore, i.e. because the host has been disassembled without unconfiguring the WebSEAL instance. Solution: 1.) Delete the instance in the LDAP under: SecAuthority=Default - cn=securitygroup - cn=webseal-servers - cn=secmgrd-servers 2.) Configure the instance again, which will lead to an error, because it seems to be installed already. Configuring WebSEAL instance 'DO-06'...HPDMG0453E A server with the same name already exists.DPWCF0473E The WebSEAL instance 'DO-06' failed to configure. 3.) Unconfigure the instance, which will show errors, but remove the instance totally. # amwebcfg -action unconfig -inst_name DO-06 -admin_id sec_master -admin_pwd ********* Unconfiguring WebSEAL instance 'DO-06'... 2008-10-28-15:30:10.158+01:00I----- 0x389D51F2 amwebcfg ERROR wcf Error WebCfgAdminApi.cpp 84 0x002198d0 DPWCF0498E The user 'DO-06-webseald/srv1252...

Error: HPDMG0764E An internal error has occurred. (status 0x14c012fc)

Error: HPDMG0764E An internal error has occurred. (status 0x14c012fc) pdadmin sec_master> user create dg1234 uid=dg1234,cn=team1,cn=users,o=company lala lala ********** Could not perform the administration request Error: HPDMG0764E An internal error has occurred. (status 0x14c012fc) Description: After the upgrade from Policy Director (policy server) V5.1 to V6.0 the errors above occured when trying to write to the registry. Solution: The task of updating the ldap schema did not work well for some reason. After doing it again the errors did not occur again: # ivrgy_tool -d -h ldap_host -p port -D ldap_admin -w pwd schema