haugene / vpn-configs-contrib

A collection of configs for various VPN providers
GNU General Public License v3.0
176 stars 739 forks source link

OpenSSL: Cannot Load inline Certificate file #162

Closed mcgeand closed 1 year ago

mcgeand commented 1 year ago

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

version: '3.3' services: transmission-openvpn: cap_add:

Current Behavior

When the container restarts the logs show a certificate failure related to OpenSSL. Logs show exiting due to fatal error after trying to load the inline Certificate file. OpenSSL: error:0A00018E:SSL routines::ca md too weak

Expected Behavior

No configurations were changed, updated to the most recent image and container would not load.

How have you tried to solve the problem?

  1. removed all config/data files from server and pulled a fresh image.
  2. reviewed logs to confirm source of failure.

Log output

Creating TUN device /dev/net/tun
Using OpenVPN provider: VPNUNLIMITED
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for VPNUNLIMITED. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.VA1qI4XHPn
Extracting configs to /tmp/tmp.MUaOW7yKos
Found configs for VPNUNLIMITED in /tmp/tmp.MUaOW7yKos/vpn-configs-contrib-main/openvpn/vpnunlimited, will replace current content in /etc/openvpn/vpnunlimited
Cleanup: deleting /tmp/tmp.VA1qI4XHPn and /tmp/tmp.MUaOW7yKos
Starting OpenVPN using config ca-tr.ovpn
Modifying /etc/openvpn/vpnunlimited/ca-tr.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Modification: Updating status for config failure detection
Setting OpenVPN credentials...
adding route to local network 192.168.0.0/16 via 172.19.0.1 dev eth0
2022-11-18 22:10:12 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2022-11-18 22:10:12 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
2022-11-18 22:10:12 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-11-18 22:10:12 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-11-18 22:10:12 OpenSSL: error:0A00018E:SSL routines::ca md too weak
2022-11-18 22:10:12 Cannot load inline certificate file
2022-11-18 22:10:12 Exiting due to fatal error

HW/SW Environment

- OS: linux x86_64 Debian GNU/Linux 11 (bullseye) // 5.19.0-0.deb11.2-amd64
- Docker: 5:20.10.21~3-0~debian-bullseye

Anything else?

No response

mptmg commented 1 year ago

Ran into the same issue with update 4.3.

For details regarding the issue look here: https://superuser.com/questions/1737052/openssl-error0a00018essl-routinesca-md-too-weak Link above pretty much gives direction on how to work around the issue/implement a fix.

This is related to the 4.3 update and the updates to OPENSSL/OPENVPN. If you want to be back up and running until there is a workaround implemented in the 4.3.X updates simply specify the previous release as your image:

image: haugene/transmission-openvpn:4.2

mcgeand commented 1 year ago

Ran into the same issue with update 4.3.

For details regarding the issue look here: https://superuser.com/questions/1737052/openssl-error0a00018essl-routinesca-md-too-weak Link above pretty much gives direction on how to work around the issue/implement a fix.

This is related to the 4.3 update and the updates to OPENSSL/OPENVPN. If you want to be back up and running until there is a workaround implemented in the 4.3.X updates simply specify the previous release as your image:

image: haugene/transmission-openvpn:4.2

Thank you so much! I'll just roll back for now.

mptmg commented 1 year ago

You should leave this issue open. I came here to create this exact issue. Leaving it open will allow the developer to be aware that for certain providers the update 4.3 causes openvpn to not be able to establish a connection. I was simply providing information and a temporary workaround.

mcgeand commented 1 year ago

True, Didn't mean to close! opened it again!

pkishino commented 1 year ago

Moving this as this is more provider related (outdated profiles etc) than container

jsloan117 commented 1 year ago

This is a problem with providers not the image itself. The link already shown does a great job of explaining this issue.

IMO I'd see if new configs are available from the providers affected or if whoever uses them contact their support to complain, that they're using insecure algorithms for signing.

If you're wondering how to check/test.

Copy the "CA" cert out of the config file in question and run the below cmd. Or exclude the grep cmd to see the all of the cert contents.

openssl x509 -text -in ca_cert_name.crt | grep -Ei 'md5|sha1'
  Signature Algorithm: sha1WithRSAEncryption
    Signature Algorithm: sha1WithRSAEncryption
maggie44 commented 1 year ago

@pkishino is there a new tracking issue for this, or linked PR if it's fixed?

pkishino commented 1 year ago

The linked issue above discussed this in depth, for a quick fix see here https://github.com/haugene/docker-transmission-openvpn/issues/2453#issuecomment-1334813242

pkishino commented 1 year ago

It’s a provider issue, not anything on our end to fix

maggie44 commented 1 year ago

It’s a provider issue, not anything on our end to fix

It is a provider issue, but this was a helpful tracking issue for the upcoming fix with the provider and then eventual integration here.

The other issue you linked to is closed as well.

mptmg commented 1 year ago

Indeed a provider issue. VPNUNLIMITED provided a few flags that could be used to essentially bypass the issue with weak encryption

tls-cipher=DEFAULT:@SECLEVEL=0

I originally thought perhaps this was something that might get included in the docker image as an optional environmental variable. VPNUNLIMITED is currently working the issue…. See response in this issue over at gluetun.

https://github.com/qdm12/gluetun/issues/1432

That issue is also closed as it also is simply waiting on the fix from VPNUNLIMITED.