18

Commands like curl and wget give the following error:curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled. I am using WSL2 Ubuntu and on a corporate firewall. I did export my trusted root ca cert to WSL and updated certificates. However, still facing the issue when downloading tools like Jenkins, Terraform, etc. For example when trying to get Jenkins.

curl -fsSL http://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee   /usr/share/keyrings/jen
kins-keyring.asc > /dev/null
curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled

I am on a corporate VPN. without VPN commands work fine however with VPN on the corporate network I get these errors. If I do SSL bypass with the fw team it works. Not sure if anything else is wrong here.

sudo vim /etc/ssl/openssl.cnf

`#
# OpenSSL example configuration file.
# See doc/man5/config.pod for more info.
#
# This is mostly being used for generation of certificate requests,
# but may be used for auto loading of providers

# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename

# This definition stops the following lines choking if HOME isn't
# defined.
HOME                    = .

 # Use this in order to automatically load providers.
openssl_conf = openssl_init

# Comment out the next line to ignore configuration errors
config_diagnostics = 1

# Extra OBJECT IDENTIFIER info:
# oid_file       = $ENV::HOME/.oid
oid_section = new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions            =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
"/etc/ssl/openssl.cnf" 397L, 12419B            `
user21387093
  • 193
  • 1
  • 1
  • 5
  • 1
    I'm having a similar error when using _OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)_. And I'm not behind any corporate proxy. A friend is using _OpenSSL 1.1.1f 31 Mar 2020_ and things work just fine. Could be an issue with openSSL version? – Daniel Mar 23 '23 at 11:55
  • I faced the same error message when tried to run the command `curl https://publicinfobanjir.water.gov.my/hujan/data-hujan/?state=PLS&lang=en`, I resolved it by replacing `https` with `http`, and the issue was resolved. This solution might be helpful for some people. – Ahwar Apr 05 '23 at 06:54

2 Answers2

20

This error is caused by the remote server not supporting RFC5746 secure renegotiation (or your corporate firewall not supporting it). In OpenSSL 1.1.1 the flag SSL_OP_LEGACY_SERVER_CONNECT was set, but this is not the case in OpenSSL 3, from the migration guide:

Secure renegotiation is now required by default for TLS connections Support for RFC 5746 secure renegotiation is now required by default for SSL or TLS connections to succeed. Applications that require the ability to connect to legacy peers will need to explicitly set SSL_OP_LEGACY_SERVER_CONNECT. Accordingly, SSL_OP_LEGACY_SERVER_CONNECT is no longer set as part of SSL_OP_ALL.

It is possible to turn this flag on again by setting it in your OpenSSL conf, it is an option called UnsafeLegacyServerConnect:

UnsafeLegacyServerConnect: permits the use of unsafe legacy renegotiation for OpenSSL clients only. Equivalent to SSL_OP_LEGACY_SERVER_CONNECT.

Source: https://www.openssl.org/docs/man3.0/man3/SSL_CONF_cmd.html

A minimal OpenSSL config with this setting:

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = UnsafeLegacyServerConnect

You could also just add Options = UnsafeLegacyServerConnect to the existing /etc/ssl/openssl.cnf under [system_default_sect].

NB. In OpenSSL < 3.0.4 there was a bug that ignored the UnsafeLegacyServerConnect option. If you are stuck with <= 3.0.3, you could use (the more unsafe) UnsafeLegacyRenegotiation instead.

Michael Johansen
  • 964
  • 6
  • 18
  • 2
    Thanks a lot! I encountered this while trying to download from a server probably with some certificate problem (no VPN involved). Running wget with the option "--no-check-certificate" was OK but running curl with options "-k" or "--insecure" didn't work until adding the above block to "/etc/ssl/openssl.cnf". But does this make my system less secure? Isn't it possible to achieve this only for a specific domain? – Sadi Jul 04 '23 at 12:06
  • And with a recent update to openssl 3.0.10-1 (debian testing), adding this option makes no difference now. Perhaps they decided to prohibit such insecure connections totally? – Sadi Aug 15 '23 at 08:52
  • 1
    Check your `openssl` version with this command: `openssl version` :-) – NeilG Aug 16 '23 at 00:58
3

If you don't want to make permanent changes to your system you can try running the configuration in memory like this:

OPENSSL_CONF=<(cat /etc/ssl/openssl.cnf ; echo Options = UnsafeLegacyRenegotiation) curl https://something.com/

In an expanded form:

OPENSSL_CONF=<(
   cat /etc/ssl/openssl.cnf
   echo Options = UnsafeLegacyRenegotiation
) curl https://something.com/

Let me explain what it does.

This part will temporarily set an environment variable for the following command. Most programs linked with SSL libraries will recognize this variable and use the configuration file indicated:

OPENSSL_CONF="value" command

By the way, I tried with OPENSSL_CONF_INCLUDE variable, but that one didn't work.

But instead of using a real file, I use this bash construct <( ... ), that creates a temporary virtual file, whose contents are the output of the inner command:

OPENSSL_CONF=<( ... )

The inner part just prints current openssl.cnf file, followed by the configuration line required:

cat /etc/ssl/openssl.cnf ; echo Options = UnsafeLegacyRenegotiation

So to sum up, we run curl with a configuration that adds the line that we required.

It works for me in WSL's Ubuntu.

LatinSuD
  • 1,779
  • 12
  • 19
  • 1
    I think this is a better solution to use only when necessary, but unfortunately, after a recent update to openssl 3.0.10-1 (debian testing), this option makes no difference now. It seems they've decided to prohibit such insecure connections totally? – Sadi Aug 15 '23 at 08:56