Git clone fails with unsafe legacy renegotiation disabled in Bitbucket Data Center

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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

Atlassian applications allow the use of SSL with our products, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.

If assistance with configuration is required, please raise a question on Atlassian Answers.

Git clone fails with unsafe legacy renegotiation disabled error from OPENSSL3 environment

1 2 error:0A000152:SSL routines::unsafe legacy renegotiation disabled Closing connection 0

Environment

Bitbucket Data Center - 7.17.x and newer

Git client with OPENSSL3 version

Operating System - Fedora 36, Redhat Linux 9

Diagnosis

Run the below openssl command from one of the client machines (with openssl3)

1 2 3 4 openssl s_client -debug -connect <BITBUCKET_BASEURL>:<HTTPS_PORT> #For example: openssl s_client -debug -connect git.mydomain.com:443

From the command output, you'll see Secure Renegotiation IS NOT supported

Cause

Starting with OpenSSL3, and thus Fedora 36 and RHEL 9, TLS connections expect the server to send the renegotiation_info extension, specified in 2010 in RFC5746 in response to CVE-2009-3555. The server where SSL is offloaded (this can be your load balancer or proxy server in front of Bitbucket DC (if you've load balancer/reverse proxy configured)) does not support TLS Renegotiation Indication Extension RFC 5746.

From TLS Renegotiation Indication Extension (RFC 5746)

Secure Socket Layer (SSL) and Transport Layer Security (TLS)

renegotiation are vulnerable to an attack in which the attacker forms

a TLS connection with the target server, injects content of his

choice, and then splices in a new TLS connection from a client. The

server treats the client's initial TLS handshake as a renegotiation

and thus believes that the initial data transmitted by the attacker

is from the same entity as the subsequent client data. This

specification defines a TLS extension to cryptographically tie

renegotiations to the TLS connections they are being performed over,

thus preventing this attack.

OpenSSL3 contains a change to the default settings which requires support for secure renegotiation in a bid to improve security, as explained in the OpenSSL 3 migration guide. Secure renegotiation is now required by default for SSL/TLS connections to succeed. Since the load balancer/ proxy server in front of the Bitbucket server does not support secure renegotiation, the connection over SSL/TLS fails from the Open SSL3 clients.

Solution

Configure the server (where SSL is offloaded) to support secure renegotiation as per TLS Renegotiation Indication Extension (RFC 5746)

Updated on April 8, 2025

Still need help?

The Atlassian Community is here for you.