Hello in anticipation of https://fedoraproject.org/wiki/Changes/dropingOfCertPemFile fedora change proposal, which is taking effect during the fedora rawhide mass rebuild (starting 23th of July), we would like you to validate this and if applicable, use `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem` instead of the `/etc/ssl/certs/cert.pem` certificate bundle which was found in the source-code https://src.fedoraproject.org/rpms/NetworkManager/blob/rawhide/f/NetworkManager.spec#_685
Probably shouldn't ignore this.
I have tried to patch my self but it seems you need permissions even to fork the repo..
Frantisek, does this look correct? https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2257 The upstream spec file is the reference for Fedora and RHEL. At the next rebase, the package will be aligned to the upstream spec file.
Replied in MR
I just upgraded from NetworkManager-1:1.54.3-2.fc43.x86_64 to NetworkManager-1:1.56.0-1.fc44.x86_64 and the VPN configurations stopped working, I entered the password and I've got an instant "failed to connect" system notification. The journalctl was slightly more helpful: NetworkManager[6417]: <info> [1777358059.0417] vpn[0x55d631f14620,e69b124b-50a8-4458-8859-5e68c3f19460,"XXXX"]: starting openvpn NetworkManager[6417]: <info> [1777358059.0421] audit: op="connection-activate" uuid="e69b124b-50a8-4458-8859-5e68c3f19460" name="XXXX" pid=3011 uid=1000 result="success" NetworkManager[6417]: <warn> [1777358060.2113] vpn[0x55d631f14620,e69b124b-50a8-4458-8859-5e68c3f19460,"XXXX"]: dbus: failure: connect-failed (1) NetworkManager[6417]: <warn> [1777358060.2113] vpn[0x55d631f14620,e69b124b-50a8-4458-8859-5e68c3f19460,"XXXX"]: dbus: failure: connect-failed (1) but as someone whom has no idea about it, the "dbus: failure: connect-failed" looks more like a D-Bus problem, than "a service on the other side of the D-Bus connection rejected to connect", especially when you filter only for the NetworkManager journalctl messages. Searching for this error message results in a hint to restart the service, that a race condition in premature service starting could be a problem, but all of that is misleading, because when seeing the journal messages also with the surrounding context you get the real problem: NetworkManager[6417]: <info> [1777358059.0421] audit: op="connection-activate" uuid="e69b124b-50a8-4458-8859-5e68c3f19460" name="XXXX" pid=3011 uid=1000 result="success" nm-openvpn[7776]: DEPRECATED OPTION: --persist-key option ignored. Keys are now always persisted across restarts. nm-openvpn[7776]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (DEFAULT). OpenVPN ignores --cipher for cipher negotiations. NetworkManager[6417]: <warn> [1777358060.2113] vpn[0x55d631f14620,e69b124b-50a8-4458-8859-5e68c3f19460,"XXXX"]: dbus: failure: connect-failed (1) nm-openvpn[7776]: Options error: --ca fails with '/etc/pki/tls/certs/ca-bundle.crt': No such file or directory (errno=2) NetworkManager[6417]: <warn> [1777358060.2113] vpn[0x55d631f14620,e69b124b-50a8-4458-8859-5e68c3f19460,"XXXX"]: dbus: failure: connect-failed (1) nm-openvpn[7776]: Options error: Please correct these errors. nm-openvpn[7776]: Use --help for more information. My fix was to open each VPN configuration file and change `ca=/etc/pki/tls/certs/ca-bundle.crt` to `ca=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem` and to comment `cipher=AES-256-CBC` line (the later might not be probably needed, I did not try with it, but it would spam the journal, thus I removed it anyway). I first tried to use `capath=/etc/pki/tls/certs/`, naively, but that did yell to me that "capath option does not exist". Understandable, I just tried it. This was very confusing, I only upgraded from f43 to f44, then I spent half an hour to fix the VPN settings, which was not great. Could the NetworkManager somehow automatically use the other file, when the old one does not exist? That would help a lot, something like an automatic migration, without touching the configuration file. What do you think?
This was a nice little scare, having VPN fail trying to start off the workday. Luckily I had run into the ca-bundle.crt issues with my home server and chasing it down just yesterday so seeing that in the log was just a "oh okay it's that again" moment. Thanks Milan for pointing the out the places that need updating.
This is visible only in fedora because path of CA certs changed. In Fedora, upgrade is done by dnf meaning rpm itself would have to bundle some script changing all saved connections. However, changing "user configured" values in connections is not desired during upgrade. If this is configured in the shipped VPN connections, it is a bug there and those need to be updated for Fedora44. Also note, NetworkManager cert path updates are relevant only for 8021.X ethernet and Wi-Fi connections, VPN plugins have their own cert path handling, not sure if this bug is cloned for NetworkManager-openvpn.