Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSSL: Cannot Load inline Certificate file #162

Closed
8 tasks done
mcgeand opened this issue Nov 18, 2022 · 11 comments
Closed
8 tasks done

OpenSSL: Cannot Load inline Certificate file #162

mcgeand opened this issue Nov 18, 2022 · 11 comments

Comments

@mcgeand
Copy link

mcgeand commented Nov 18, 2022

Is there a pinned issue for this?

  • I have read the pinned issues and could not find my issue

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

  • I have searched the existing issues
  • I have searched the existing discussions

Is there any comment in the documentation for this?

  • I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

  • I have checked the provider repo for issues
  • My issue is NOT related to a provider

Are you using the latest release?

  • I am using the latest release

Have you tried using the dev branch latest?

  • I have tried using dev branch

Docker run config used

version: '3.3'
services:
transmission-openvpn:
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun
volumes:
- /srv/dev-disk-by-uuid-bf1ea84a-83c8-4d47-bb79-4be63bd8b9a7/appdata/transmission:/data
- /srv/dev-disk-by-uuid-bf1ea84a-83c8-4d47-bb79-4be63bd8b9a7/download:/downloads
environment:
- OPENVPN_PROVIDER=VPNUNLIMITED
- OPENVPN_CONFIG=ro
- OPENVPN_USERNAME=XXXXXX
- OPENVPN_PASSWORD=XXXXXXX
- LOCAL_NETWORK=192.168.0.0/16
- PUID=1000
- GUID=100
- download-queue-size=12
- download-queue-enabled=true
logging:
driver: json-file
options:
max-size: 10m
ports:
- 9091:9091
dns:
- 8.8.8.8
image: haugene/transmission-openvpn:dev
restart: unless-stopped

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
Copy link

mptmg commented Nov 18, 2022

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
Copy link
Author

mcgeand commented Nov 18, 2022

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.

@mcgeand mcgeand closed this as completed Nov 18, 2022
@mptmg
Copy link

mptmg commented Nov 18, 2022

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 mcgeand reopened this Nov 18, 2022
@mcgeand
Copy link
Author

mcgeand commented Nov 18, 2022

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

@pkishino
Copy link
Collaborator

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

@pkishino pkishino transferred this issue from haugene/docker-transmission-openvpn Nov 19, 2022
@jsloan117
Copy link
Contributor

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
Copy link

maggie44 commented Mar 6, 2023

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

@pkishino
Copy link
Collaborator

pkishino commented Mar 6, 2023

The linked issue above discussed this in depth, for a quick fix see here haugene/docker-transmission-openvpn#2453 (comment)

@pkishino
Copy link
Collaborator

pkishino commented Mar 6, 2023

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

@maggie44
Copy link

maggie44 commented Mar 7, 2023

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.

@pkishino pkishino pinned this issue Mar 7, 2023
@mptmg
Copy link

mptmg commented Mar 7, 2023

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.

qdm12/gluetun#1432

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants